Changing the license to a more permissive one such as MIT

jdb78 commented 3 years ago

GPL licenses are pretty difficult to use and are often not allowed. What about switching to a MIT version?

Technologicat commented 3 years ago

I'm fine with the idea, but if we want to do this, there is a degree of practical hassle. To change a license, copyright law (in various jurisdictions) requires permission from all copyright holders (i.e. in this case, contributors). If someone doesn't agree, the only thing we can legally do is to re-implement their contribution independently.

Note that while GitHub requires anyone making a pull request to license their contributions under the same license the target project uses, that only applies to the license to project had at the time each particular contribution was made.

If you don't mind contacting everyone and obtaining their permission to change the license, please go ahead!

I've maintained a full list of contributors in AUTHORS.md. Beside us, the most important contributors are the original author Edmund Horner (ejrh), and previous long-time maintainer David Fraser (davidfraser). The further contributions at the end of AUTHORS.md refer to merged pull requests - you should be able to get at least the contributors' GitHub usernames by looking at closed pull requests (in this repo).

We could ask each contributor to post their decision here - and if we get permission from everyone, then print this page as PDF and archive a copy in the repo itself.

For the record, I'm fine re-licensing my contributions under the MIT license. I usually use the BSD license for new projects of my own, but for me it doesn't matter which of these two the new license is.

Technologicat commented 3 years ago

P.S. Even though the politics of the open source movement (in a wide sense) has in the last decade shifted toward a more pragmatic attitude, with BSD and MIT licenses nowadays favored over GPL, I'm puzzled why a separate GPL-licensed program wouldn't be allowed; it's not like the GPL is affecting anyone's in-house code. Linking is a different matter, and then LGPL would be more appropriate.

Even if someone at a closed-source software company develops some new features for pyan, GPL's open-sourcing requirement, for code in pyan only, applies only if they distribute the modified pyan outside their organization. The GPL is not an EULA.

But I'm sure you know all that already - I suppose organizations can be organizations?

jdb78 commented 3 years ago

Some legal departments take a rather risk-averse approach and completely forbid LGPL and GPL licensed code :(. With BSD or MIT licenses you are on the safe side.

jdb78 commented 3 years ago

Also for the record: I approve of relicensing my contributions under a BSD or MIT licence.

jdb78 commented 3 years ago

Could the following people post the following text in this threat "I approve re-licensing my contributions to pyan under the BSD or MIT license." This would allow us to make pyan a more widely distributed package.

[x] jdb78
[x] Technologicat
[x] @ejrh
[ ] @samjbasak
[x] @davidfraser
[x] @RakanAlanazi
[ ] @edumco
[x] @sirex
[ ] @johnyf
[x] @scrdest
[x] @kuuurt
[x] @maciejczyzewski

sirex commented 3 years ago

I approve re-licensing my contributions to pyan under the BSD or MIT license.

Technologicat commented 3 years ago

@jdb78 Thanks for the clarification. So, yeah, a case of organizations being organizations. I can understand the preference of erring on the safe side, though.

Related reading; I'll just archive the link here before I forget: Nathaniel Smith: The unreasonable effectiveness of investment in open-source infrastructure.

Thanks for taking this on!