[META] Get phpList 4 up to speed about core HOT 15 OPEN

Wow, thanks Oli for getting things into action here. Cheers.

from core.

It is fine to mix GPL and AGPL. Basically both require providing the source, and AGPL is more restrictive (eg you have to provide it, even if you use it to run as a service). You particularly have to provide the source, if you make changes to it.

Just the nature of having it here on Github means it's provided. Moreover, the AGPL will ensure that hosted versions have to use the same code. Some people think that phpList Hosted is a different version of the code. It is not, and the AGPL makes sure of that.

http://softwareengineering.stackexchange.com/questions/107883/agpl-what-you-can-do-and-what-you-cant

from core.

A few comments on this:

• Swiftmailer vs Phpmailer: maybe judge first, which one is more suitable
• TurboLinks is nice, but a big nice-to-have I would say
• inline CSS: take a look at Zurb's email framework
• If we could use Fluid here for templating this would be super-huge-awesome

from core.

Ah one thing you have to check first: Most of those libs are GPL AFAIK. phpList is not GPL so you have to check compatibility of licenses.

from core.

@liayn If I include the libraries via composer, but don't copy them into the project, does the license matter then?

from core.

@liayn Thanks for the comments! I've included them in the list.

from core.

Well, I'm not a lawyer, but I see it the other way around: You still want to provide a downloadable full package of phplist in the future, hence the composer install has to be done during packaging. At this point the license matters for sure.

from core.

Oh, actually I'd prefer it to be composer-deliverable only as this will allow easier updates. (Updates with the old all-in-one package are a real pain.)

from core.

I have experience with this with other products... you will lose 90% of your user base.
Consider all those small usecases where people don't send thousands of mails, but run a tiny instance on their FTP-only hosting.

from core.

SwiftMailer vs phpMailer, I think we should try being mailer independent. A bit like this, https://github.com/phpList/phplist3/blob/master/public_html/lists/admin/EmailSender.php

from core.

I'll start a discussion about the all-in-one package issue on the developer list. Maybe we can offer an option that people without SSH access can download the package, run a composer install, and then copy the whole thing (including the vendor folder) to the web server?

from core.

@michield What would we (ro the user) gain from being mailer-independent? (The user will never use the mailer directly.)

from core.

Well, yes, good idea basically, but composer requires a local PHP, which is a bit out of scope I would say. (for non-devs)

from core.

@oliverklee mailer independence will allow adapting to new mailers quicker.

The packaging issue is something to think about. We will want to be able to package the lot for easy download and install. Even though the future may be delivering it in a Docker container instead. Maybe we should discuss this on the mailinglist.

from core.

I've moved the TurboLinks to-do to the new performance meta-ticket #30.

from core.