EUPL as an authorized license
jacquesbh opened this issue · comments
Hi!
Could we authorize the EUPL as a license for bundles?
I don't think this license in incompatible with symfony.
What do you think?
Do you have some examples of packages that might benefit from that?
I don't have right now, out of the box, a list of bundles with that license.
We are planning to use it for our own bundles (Sylius plugins) at Monsieur Biz, by changing from MIT to EUPL, probably, because we want to keep these bundles code Open Source, and we think it's a good way of doing it.
This license is really close to the AGPL and it respects the European laws with a translation in all European languages.
Adding the AGPL could be great too (actually blocking a PR from @dunglas: #893).
I strongly support this change! Actually it would be nice to accept any license approved by the FSF or/and by the OSI.
Another benefit could be to increase the use of Symfony in the Dweb/Fediverse/Mastodon/ActivityPub community.
I recently published a bundle allowing to add support for ActivityPub in any Symfony application. While this bundle is MIT-licensed, most of the Fediverse is using AGPL-licensed software. Not allowing recipes having this license could hurt the adoption of Symfony in this community.
Big +1 for this change!
I use EUPL v1.2 (for bundle/lib/...) and AGPL (for application).
FYI EUPL is the European version of (A|L)GPL, created and approved by the European commission. License is available in 23 languages and a matrix compatibility is also available.
See #515 for a previous similar request and reasons why it has been rejected in the past. If the preconditions are the same, the outcome is likely going to be similar.
EUPL is copyleft (like AGPL) but not viral (like LGPL). That's why I'm using it for lib/bundle and not for application. I don't want to create any legal risk/extra care for something in vendor so EUPL sounds perfect to me.
We should either allow bundles to embed their own recipes, or allow FSF/OSI-approved licences in the recipes-contrib repo (not in the official one). As demonstrated by #893, the current situation hurts users: for some free packages, they cannot benefit of the simplicity unlocked by flex.
Also, if using free but non-permissive licenses is an issue for a company, this company should use a licensing verification tool such as Tidelift. It’s way more safe (because a MIT-licensed software can depend on a EUPL or LGPL-licensed library or of an AGPL service for instance), and it raises money to maintain Symfony
The comparison matrix given by @pocky clearly shows that there is nothing against this change.
It's perfectly compatible with the MIT license.
It's for the better of Symfony, and the Open Source in general. In different ways, but still.
hear, hear :)
Let me think about the "best way" to do that. I think that adding "just" one more license is indeed not very practical as we won't be reviewing each license to see if we want to accept it or not.
So, I'm leaning towards accepting all licenses. Give me some time to make it happen.
Closing as this stalled. Also because this can be easily relaxed by reverting symfony/recipes@ce4b08d
If we allow all licenses, it'd be great if flex could display a warning when installing something risky (eg copyleft in a non-copyleft project). PR welcome on symfony/flex.