License clarifications

[stephanlachnit]

Hi again, so symfit got rejected from Debian due to some license unclarities. So the first thing is that https://github.com/tBuLi/symfit/blob/ed20d296a818f6e8ce89efae4e9f3dce635ff4db/setup.cfg#L8 states an MIT license which seems like a copy-and-paste mistake.

The second thing is GPL2 clarification. The license file is GPLv2, but I would like to know if the or-later stuff applies.

My recommendation is to just put GPL-2.0-only or GPL-2.0-or-later (which one doesn't really matter to me) in setup.cfg. Those are SPDX identifiers (https://spdx.org/licenses/), the difference becomes clear when you compare the Standard License Headers.

[tBuLi]

To be honest I've never really cared much about licences, as long as the code is "open" according to my own fussy definitions ;). So I'm not surprised since in the early days I treated licencing with disdain.

I think GPLv2 is a fine choice going forward, although I do not know what they changed with v3? And what does the or-later do in Debian?

[stephanlachnit]

To be honest I've never really cared much about licences, as long as the code is "open" according to my own fussy definitions ;). So I'm not surprised since in the early days I treated licencing with disdain.

It's all open and fine, but imagine Debian being legally responsible for the code it ships, so legal accuracy is quite important. I'm not even sure if that's actually the case, since not every distro is that strict.

I think GPLv2 is a fine choice going forward, although I do not know what they changed with v3? And what does the or-later do in Debian?

The -or-later suffix simply means that a fork can change the license to GPLv3-or-later (as far as I understand it). It doesn't make a difference for Debian, the only thing that is important to Debian is that the license is clearly specified.

Here are some links: https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.de.html#VersionTwoOrLater, https://www.ifross.org/en/what-difference-between-gplv2-and-gplv3, https://www.gnu.org/licenses/rms-why-gplv3.html Basically as far as I understand it, GPLv3 has some patent protection stuff going on, is written more towards a "global" legal system instead of being based on the US legal system, and is a bit more compatible with other licenses. GPLv2-only is incompatible with GPLv3, but since that only applies to linking that doesn't really matter here.

I personally prefer GPL-2.0-or-later, but again, it doesn't really make a difference for a Python library.

[pckroon]

My personal preference would be MIT (or even Apache2.0) instead of GPL, but beyond that I'll leave this up to @tBuLi.

[stephanlachnit]

My personal preference would be MIT (or even Apache2.0) instead of GPL, but beyond that I'll leave this up to @tBuLi.

Hm, changing a license completely requires confirmations of all contributors afaik, right now that would be 8 people.

[pckroon]

I looked that up once, but I don't remember the outcome :\ I do seem to recall there was a way out of requiring the confirmation from all past contributors, since that would make license changes for FOSS projects (almost) impossible. Not sure how or what though. And I don't really care enough to dig through all the legalese again -.-

[tBuLi]

Why would you prefer MIT @pckroon?

[pckroon]

Because I would like symfit to be as easy to use as possible, and GPL (and any other copyleft license) can pose a hurdle for companies (since it forces any derivatives to be GPL as well). And while I think that all software in science should be open, I don't think that holds for company software.

[stephanlachnit]

Because I would like symfit to be as easy to use as possible, and GPL (and any other copyleft license) can pose a hurdle for companies (since it forces any derivatives to be GPL as well). And while I think that all software in science should be open, I don't think that holds for company software.

Isn't company software the entire point of copyleft? They use your free (as in freedem) code for free (as in free beer), so the least they can do is publish modifications / improvements. Open source software doesn't mean it that there is no work / cost behind it.

And since the whole linking restriction from the GPL doesn't apply to a Python library, there is no real world difference anyway.

[pckroon]

Isn't company software the entire point of copyleft? They use your free (as in freedem) code for free (as in free beer), so the least they can do is publish modifications / improvements. Open source software doesn't mean it that there is no work / cost behind it.

Maybe I'm too optimistic in this. I know FOSS doesn't come at no price (I write some myself). And contributing back to the open source community is good/important. But is copyleft software truly free? Since you can't use and adapt it to your needs without having to publish the modified version, which may contain/reveal IP. This is more of a personal opinion than based on fact. It's good that copyleft and GLP exist, but they're not really for me ;)

And since the whole linking restriction from the GPL doesn't apply to a Python library, there is no real world difference anyway.

Are you sure? (: Can I import a GPL python library and not publish my own code GPL, or at least as FOSS?

[Jhsmit]

I've looked into these issues at some point as well and then decided to change the license for my project from GPL to MIT.

This might be only/mostly applicable to academic software, but what frequently happens is that a new project is set up that supersedes or party overlaps with a previously published academic software. If the previous work is GPL, (parts) of this software can't be reused without either also using GPL for the new project, or contacting all authors of the previous work and try to convince them to re-release their code under MIT.

I've now run into this issue myself twice. First where we're trying to set up a collection of python code as a scikit package for a specific field of science. Here we want to incorporate previous work but we can't since its licensed under GPL. The authors of the work usually moved onto other projects, and, like @tBuLi, don't really care about the license but logistically its impossible to get the license changed.

Second is in a new project which analysis a specific type of data. In the analysis, I've incorporated a part of code from previous work. This work was licensed under GPL, so I cannot release my project under MIT with this code included. Technically, but this is a grey area, I cannot write this code myself and release it under MIT since I've already 'seen' this implementation. Also, since the project is not on pip, I cannot add this project as a requirement.

Of course, indeed the disadvantage of MIT is that companies can take your code, incorporate it in their software and sell it closed-source for a lot of money without any acknowledgements whatsoever for the authors of the work. But at least your FOSS contributions are being used as widely as possible.

As far as I understand, the GPL copyleft clause only applies if you are distributing the code. If your MIT project imports GPL code this is not problem because you don't distribute the code. But, IANAL.

[stephanlachnit]

Can I import a GPL python library and not publish my own code GPL, or at least as FOSS?

Open Source software (as defined from the OSI/DFSG) is not allowed to restrict the use of the software, i. e. you can't restrict simply accessing files as it is in the case with a Python library. Imagine you would be only able to run a GPL application on a terminal that is GPL as well, that would be ridicilous.

Since the GPL is approved from the OSI, I think this is the case for the GPL as well, but I'm not a laywer.

However, what you can restrict is static linking, since that goes beyond just accessing a file, and creates a combined binary. To be on the safe side, LGPL would also be an option, that's GPL without the linking restriction.

[tBuLi]

From reading these and other discussions I have the impression that MIT is closest to what I have in mind, especially since as @Jhsmit indicates, the target audience is probably scientific software. So unless there is a very strong argument against this I think MIT would be best?

[stephanlachnit]

One argument against it is that the MIT license is incompatible to the current license, so you would need to ask every contributor if he/she is fine with a license change (I am for my part).

[pckroon]

MIT sounds good to me.

[Jhsmit]

I agree with changing to MIT

[tBuLi]

@DuckNrOne , @jbarnoud @elgalu @brocksam, would all of you also be okay with switching to an MIT licence?

Now that the contributor list is still small we might still be able to do this ;).

[brocksam]

MIT License is actually preferred in my opinion! So yes!

[jbarnoud]

Going for MIT is fine by me.

[elgalu]

fine with me

[stephanlachnit]

@DuckNrOne ping, asking since this issue is still a blocker for the Debian package.

[antonykamp]

I gave my thumbs up :)

[stephanlachnit]

Alright, then the license can be switched.

Btw @tBuLi I recommend following the REUSE / SPDX specification for license annotations (https://reuse.software/spec/), basically it boils down to adding

# SPDX-FileCopyrightText: 2014-2020 Martin Roelfs
#
# SPDX-License-Identifier: MIT

at the start of each (code) file. Technically you could do also that entire LICENSES/ thing and symlink the toplevel LICENSE to LICENSES/MIT, but since there is only one license it's not that important.

[pckroon]

Excellent! I'll open a PR later today