GPL and virality

Community
, , ,
1

It’s often stated that the GPL is “viral” – i.e. that using GPL code “infects” other code. There is a viral effect for code that is not licensed under a GPL-compatible license, but not for code that is licensed under a GPL-compatible license like MIT or BSD.

First, a bit on how software licenses work: a software license is a legal document in which the copyright holder – typically the author of the code – gives someone the right to use or redistribute the software under certain conditions. If you violate those conditions, you don’t have a right to use or redistribute the code anymore and are therefore breaking the law if you do so.

The reason the GPL is “viral” for proprietary code is because one of the conditions of the GPL is that the source code of the entire “derived work” – i.e. the combination of GPL code and proprietary code – must be made available under the terms of the GPL. Otherwise, you lose the right to use the GPL code at all. Since you can’t, by definition, make proprietary code available as required by the GPL, you can’t comply with the terms of the GPL, so you don’t have a legal right to use the GPL part of the code (you still have as much right to use the proprietary part). You’re stuck: you can’t make the source of proprietary code public, but you’re not allowed to use the GPL code unless you do exactly that.

If we try to apply the same logic to a combination of MIT-licensed code and GPL code, the “viral” behavior vanishes: the license of the GPL requires that all the source of the combination be made available under the terms of the GPL – which is fine for the MIT part since it’s already open source under terms that are completely satisfactory according to the GPL. So there’s no problem: you can use and distribute the combined product under the terms of both the GPL and the MIT licenses – which is effectively the same as just the terms of the GPL.

In short, the GPL is only viral for code that is not already licensed in a GPL-compatible manner. There’s no problem with combining MIT (or BSD) code with GPL code and the license of that code does not need to change. Using or redistributing the combined product requires you to comply with both the GPL and the MIT licenses, but the MIT part of the code can remain MIT-licensed. Only if you start actually copying GPL code into an MIT project does is the license required to change since you’re actually deriving that source from GPL code.

Disclaimer: I am not a lawyer and this is not legal advice, just a hopefully helpful explanation of how software licenses work since many questions seem to come up around this.

16 Likes
2

It looks like you are responding to something… would you mind sharing that, too?

3

It’s a frequently asked question. Someone did just ask about combining GPL and MIT code on Slack, but this comes up a lot. I was also just thinking about the virality thing the other day.

4

Maybe I’ve understood the ‘virality’ concept wrong - I had the impression that the fact that any code that uses any element that is GPL needs to itself be GPL, no more, no less, is exactly what is meant by viral. So, e.g. proprietary code needs to stop being proprietary and become GPL (which it cannot become as you say); and a project whose other code components are otherwise MIT needs to become GPL too - so the condition of the total result coming under GPL is the same for both. So I thought “viral” referred to the fact that it was “contagious”, e.g. affected the total product not just the GPL lines themselves (which is true for both cases). Could you comment on this?

It also reads from your description as if MIT requires the total product including the MIT code to comply with MIT, but is that really true?

2 Likes
5

No, it doesn’t go that far. I do believe that GPL 2.0 or something like that had something about binding to GPL, but I am not sure that’s an issue anymore? The main issue with GPL is that the copyleft part extends to any “derivative work”. Derivative works are hard to define, but for example if you use their source code as starter code and then work from that to make your own algorithm, then that can probably (who knows, depends on the cases) count as derivative work and thus needs to be GPL licensed. This is where the “if it’s GPL, avoid the source code since I write MIT libraries” comes from. But, you can still depend on and call functions from a GPL-licensed library, just don’t go digging through the source if you want to be safe.

1 Like
6

What I’m clarifying is that this is not the case (AFAIU). The virality effect comes from the fact that if you use or distribute a “derived work” that includes both proprietary and GPL code, then in order to not be in violation of the copyright of the GPL part, you need to make the proprietary code available under terms that satisfy the GPL. It doesn’t, as far as I understand it, need to be made GPL-licensed: it would be sufficient to make the proprietary code MIT-licensed or public domain.

It also reads from your description as if MIT requires the total product including the MIT code to comply with MIT, but is that really true?

Yes, that’s a good point – the MIT requirements only apply to the MIT code itself, not the whole “derived work”. MIT doesn’t make any reference to the concept of a “derived work” at all.

2 Likes
7

I would have said, GPL is viral. In the sense that if I look at GPL’ed code I cannot use such code in a package that I want to publish under MIT. If I arbitrarily look into a GPL’ed package just to study how it’s being done there is the question: is this code commonplace enough to use? If not I couldn’t use it in my MIT copyrighted package.

Thus by default I avoid. It would be different in the R ecosystem where basically everything is GPL. And I also don’t criticize GPL, the author must decide and maybe he/she wants more protection. That’s fine (I just don’t look at it (without absolute need)).

8

This whole “viral” terminology is pejorative and misleading, in my opinion. If anything, copyright law is what is “viral”, not the license. If you make a derived work D from parts A, B, and C, then you need to obey the license terms of A, B, and C when you distribute D (i.e. when you do something with D that is otherwise forbidden by copyright law). The more restrictive these licenses are, the more restrictive the license on D is. If the A, B, and C have mutually contradictory requirements, then you cannot legally distribute D.

(But the “viral” metaphor is kind of broken, because a virus infects you without your permission. No one forces you to use someone else’s code.)

“Permissive” free/open-source licenses like MIT and BSD impose virtually no restrictions. “Copyleft” licenses like GPL or LGPL or MPL impose more restrictions (and hence can easily be incompatible), typically to limit permission to combine the code with non-free/open-source code. Non-free licenses, e.g. licenses that only allow “non-commercial use”, impose even more restrictions. The Intel MKL license (ISSL) forbids modification, decompilation, or reverse-engineering. The more restrictions a license imposes, the more careful you have to be when distributing derived works, and the more likely you are to run into conflicting requirements.

19 Likes
9

Licenses are legal documents, and I recognize that I lack the expertise to think deeply about them. I can try to find answers from experts, but most of this will be in the context of US law, which is not the whole picture, and in any case, that would still require a significant time investment. I could ask for legal opinion from a lawyer, but that is very costly too.

The mental cost of thinking about these issues is a strong argument in favor of the MIT and similar licenses for me, as opposed to GPL, especially GPL3. I am sorry if this sounds lazy; in an ideal world one would carefully judge these licenses on their merits and pick the “best” one for each particular situation.

10

This is very well described by @StefanKarpinski and @stevengj.

There is one additional point: While it is fine to in-general recommend MIT style licenses to package authors, it is important that anybody is free to chose a license that she/he is comfortable with. I have seen some posts in the past where it was recommended to authors not to use the GPL because this is not what is usually done in Julia. I think this goes too far.

4 Likes
11

I think it’s fine to warn someone of the implications and advise against it. GPL-licensed packages are a bigger problem when code around it is not GPL-licensed. It’s not uncommon to take a look at someone’s source code for a Julia package and derive some alternative algorithm from it. An example where this happened before was with NLsolve.jl which was GPL where I among others got inspiration for rootfinding algorithms from how they are done there. Optim.jl and all of JuliaNLSolvers is now taking a mix of approaches from the previous NLsolve.jl and Optim.jl, and so a lot of the stuff that has moved repos or is now in NLSolversBase.jl is definitely some form of derived work. @pkofod got all of the authors to agree to a license change to MIT for this to all be possible. If it had stayed GPL, this would definitely have been a license violation without changing the license of Optim.jl to GPL (among others).

From what I have seen, many people just choose GPL since they are used to it because of R. I think giving a “hey, around here we don’t tend to use GPL because ________, but you should still feel free to make the final choice on your own” is a perfectly fine thing to inform new package authors about the implications of this choice.

To me, anything that would need a lawyer to answer the question (or be answered on a case by case basis) is something to avoid. GPL invites tough questions when surrounded by similar libraries with similar contributors but with non-GPL compatible licensed code.

7 Likes
12

Isn’t the main upside of the MIT license that you can use it in a proprietary closed source environment without having to publish your code additions/changes in any way or form? I was under the impression that practically speaking having any GPL code in your code base ruins that possibility if the GPL code is not separate of the shipped product (so probably only if its a separate program thats used through the command line, since even dynamical linking seems to be infecting: licensing - How does the GPL static vs. dynamic linking rule apply to interpreted languages? - Software Engineering Stack Exchange) . Which in a way makes the fact that some components are MIT licensed meaningless in such a scenario.

Am I wrong in this?

13

When I read your post its like that one has to excuse oneself when one chooses GPL. In my opinion this is a pretty selfish view.

I have nothing against discussions on licensing in particular if several contributors are involved. But the statement that GPL packages are “a problem” is not ok for me. MIT packages and GPL packages can co-exist and this is not problem at all. This is what @StefanKarpinski wanted to make clear by this post. Copying code around without thinking about who wrote it is of course not possible with packages of different licenses.

2 Likes
14

The point is that the GPL code and MIT code can coexist. Infecting does not mean that the code around has to be GPL itself. Just take Julia as an example. It had various GPL components for a long time but 95% of the code were MIT. By removing the remaining parts (which I actually think has happened with the removal of FFTW) it has kind of “recovered” from the GPL infection.

1 Like
15

That’s a fair point, but I am arguing that the kind of “viral” that Stefan is talking about isn’t the “scary” part of the license. It’s that it dominates the combined work

2 Likes
16

Why is that scary? It just prevents shipping some closed source binary blob that uses GPL software.

17

Yes, MIT and GPL packages can coexist. An example of this is NLopt which is perfectly fine as GPL while NLopt.jl is MIT, and this is all fine and legal.

But again, that’s not the issue with GPL licensed packages. An isolated dependency where most people aren’t looking at the code is not the same thing as a Julia package co-existing with others in the ecosystem.

The issue is how pervasive code sharing is in the community. We talk all the time about not wanting to over-proliferate packages, and that similar packages should try to work together or combine (recent example: ANN: HigherPrecision where it’s easy to inspect both packages and see opportunities since they are both MIT). How are we supposed to talk about this stuff if one of the parties chooses GPL, which is incompatible with the license most people are using for their code? How are we supposed to open up and discuss the differences in people’s algorithms but avoid any legal issues? In that case, if we want to avoid “derived work” issues and are working on something similar (a lot of people in Julia focus on data science or scientific computing, so a lot of similar algorithms and techniques are used), it’s somewhat of a legal trap to start looking at the details of how they implemented something.

I don’t think there’s anything wrong with basically saying “look, this choice can cause legal issues for most others who could be contributors. Let’s make sure this is a conscious and informed choice”.

3 Likes
18

Which is exactly what I want to allow by making my code MIT. So, in that aspect GPL is viral by taking that option away.

Please don’t misunderstand me. I am not arguing against GPL. If restricting this kind of usage is intended then that is of course perfectly fine. After all one doesn’t have to use that component, etc.

I am just saying that under a certain light the outlined compatibility of the two licenses is just not that practically meaningful. For example I as an open source developer am very conscious about my dependencies because I would like my complete library to remain as MIT. This of course depends on the grace of others to share the fondness of the license. The Julia community seems to embrace modular packages and this license, which I tend to think is good for progress and user adaption.

3 Likes
19

:slight_smile: This is pretty funny. Then the first thing you should stop depending on is … Julia (at least if you are on Julia 0.6). Julia 0.6 ships with GPL components.

(But I get your message and personally also prefer MIT. I just want to make people sensitive that GPL is not bad.)

20

I did actually think about this a little (given that I am easily worried and know little about legal matters). but as I understand Julia is a compiled program, so I don’t think using that program to produce data (i.e. code) influences libraries one writes. Just like using a GPL editor doesn’t influence the license of code you write. Similarly for executing the code, which I figure is somewhat relatable to gcc compiling programs. The issue (as I understand it) would arise if one were to compile or link julia itself into something.