Possibility of dual licensing: GPL-3.0 & MIT

[CapeHobbit]

Feature Request

Hi Satpy team,

I was wondering about the possibility of releasing the package under a dual license; both as GPL-3.0 and MIT. As both of these are open source, I do not think this would violate the community driven nature of the project. However, the copyleft nature of GPL-3.0 makes it hard to deploy Satpy as a dependency in, for example, another GitHub project that also includes software that is not compatible with this.

My specific situation; I develop ocean training code for EUMETSAT and, to date, I have had to steer clear of Satpy and all GPL-3.0 software as it mandates that I must release the entire repository under GPL-3.0, which I can't easily do, especially if any proprietary software is involved. I limit myself to MIT/Apache-2.0/BSD packages for this reason.

If you feel that my interpretation of the GPL-3.0 license is incorrect, or have an alternative suggestion, I would be happy to discuss it.

[gerritholl]

I think that changing the licence would require the consent of everybody who ever contributed to Satpy, which would be difficult to get.

[mraspaud]

as @gerritholl mentions, just on the practical side of things it will be very complicated to have the agreement of all who ever contributed to satpy.

However, all hope might not be lost :) Here are a few ideas:

• If the proprietary part of the program you write is a library that is freely available to download, then in my opinion (IANAL) it falls under the category of system library, which the GPL allows linking to.
• If that's not the case, a solution is to use satpy in a separate process than the proprietary software and make them communicate through data files. A bit bulky, but something that we use in the NWCSAF PPS software.

Would either work for you?

[CapeHobbit]

Thanks @gerritholl and @mraspaud for the replies. I appreciate, given that this is a large project with a strong legacy, contacting all authors is pretty much a practical impossibility.

Regarding the suggested alternatives;

• Option 1: Nothing I personally write is proprietary. My code is all for training, so I happily give it away freely under MIT. However, I obviously import a lot of Python modules to do this. I think the general consensus on this is that even dynamically linking libraries, GPL-3.0 applies to the whole package (IA-also-NAL!) . So, if I import a single GPL package, the whole thing inherits GPL-3.0. This may not be a total deal-breaker for me, but I would have to release everything under GPL-3.0 and it would possibly limit the downstream use of my training code (e.g. in the case that one of my course attendees wants to use some of my code to spin up an application with commercial applicability they would not go near this << this is admittedly a vast overestimation of the value of my code!).
• Option 2: this seems possible, though I would have to have separate Jupyter Notebooks for different parts of some naturally sequential processes. Cumbersome, but maybe the only option left to me.

I appreciate your time on this. I would very much like to contribute to the continued development of Satpy (especially for Copernicus ocean missions), but it's hard for me to justify the time if I can't use the package day-to-day in my work. Maybe I am stuck with my "sideline" of bespoke tools.

[mraspaud]

One more thing: if you release your software/notebooks as gpl, you can add an exception for the non-free library you are using: https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

Some more item in this document can be relevant:
https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException

Regarding the use of GPL by private companies, I have to say that it seems to be less and less problematic nowadays, especially more and more companies do not sell software but services. But I understand your point here of course.

[mraspaud]

I'm closing this issue for now, feel free to reopen if you want do discuss more.