> There’s a lot of GPL software that operates in the grey (and many OSS devs who don’t understand their license choices),
Do you have examples? What kinds of misunderstanding are there? And what gets clarified by this case that wasn’t clear before?
Do you have examples? What kinds of misunderstanding are there? And what gets clarified by this case that wasn’t clear before?
But usually it’s a misunderstanding of what derivative works are. E.g building an extension to a GPL app. Many don’t believe that simply importing a GPL Python module is enough to make your extension have to comply to GPL.
Or things like what constitutes distribution. E.g employees vs contractors vs third party collaborators etc…
But when I have to deal with said project owners, they bring up that the GPL is about the spirit of the license, not the exact words. They often say not to worry about litigation.
This case doesn’t specifically clarify those terms but it does highlight that GPL violation is a serious issue that can’t just be treated as a suggestion.
That any lawsuit has taken place and won means that
1. I can point to cases where the license choice is impactful when working with existing projects or when setting up new OSS projects in my industry
2. It also means that the license proponents may feel more empowered (as they should) to take action against infringement.
Basically, very few people take software licenses as seriously as they should. Cases like these help make them a more serious matter.
The more seriously people take it, the easier my job gets for multiple reasons.
And since someone might ask, the license I advocate for the most is Apache 2.0. It covers the most ground, with the most clarity and the most protections for all parties involved.
The GPL doesn't explicitly define the concept of derivative work. The FSF's interpretation is that linking creates a derivative work, but there's no universal consensus among lawyers on this issue.
LWN has an article that presents a few different views on this topic: https://lwn.net/Articles/548216/
I can almost hear the chairs squeaking under the many SaaS devs reading this. IANAL, but as far I know the debate is not settled on whether this clause applies to SaaS, that is when you do not distribute the software per se, and the general consensus so far is that it does not. This is the "raison d'etre" for the AGPL license, which covers the SaaS use case.
> the GPL is about the spirit of the license, not the exact words. They often say not to worry about litigation.
Even weirder. Especially since then, why pick the GPL at all? The only reasons I can see is that you care about free software, and want virality for that reason, and/or you want companies to pick a commercial license.
From the point of view of the owner of the software, I can see how you can think that your intention matters more than the word of the license. It's wrong in a legal sense, of course, but it makes some kind of sense of you say "nah, we'd never sue for that".
But many projects are years and years old, with many many contributors. Getting them to relicense is a burden that they don’t see the worth in if they cannot first agree on the pessimistic interpretation of the license
first to say, the interpretation will be different in different legal regimes, but.. here in the USA, I believe that the copyright holder is the title that determines who gets the say about changes to the license.
1. If you’re not touching the core code, it’s not under the GPL. I try and get them to LGPL license the extension points but they don’t see the benefit in trying to relicense it with all their contributors.
2. For your second point, the issue is that the GPL is intentionally vague as a deterrent for corporate abuse. The issue becomes that, as a corporate user: I have to take the most pessimistic view to protect myself. If I switch my hat to someone non corporate, then I take the most optimistic view. In those cases, they often say to not take the pessimistic view because that’s not the spirit as they understand it.
no the GPL was intentionally set the way it was.. vague is not the word for that IMHO.. thirty+ years of computer markets has brought every possible challenge plus a few more. So the original LICENSE has been deeply scrutinized and the markets have changes... the parts that needed clarification have had changes as a result.
"vague" is mildly insulting, and there is plenty of that going on as part of this discussion.
> 1. If you’re not touching the core code, it’s not under the GPL. I try and get them to LGPL license the extension points but they don’t see the benefit in trying to relicense it with all their contributors.
I sense this comes down to a really poor definition of "linking" (is that the word in the text? Can't remember and don't have it to hand).
It's not at all obvious for each software/language ecosystem which specific act constitutes "linking".
> 2. For your second point, the issue is that the GPL is intentionally vague as a deterrent for corporate abuse. The issue becomes that, as a corporate user: I have to take the most pessimistic view to protect myself. If I switch my hat to someone non corporate, then I take the most optimistic view. In those cases, they often say to not take the pessimistic view because that’s not the spirit as they understand it.
100%, and this is my gripe against things like the BSL too. It's disingenuous because the aim of the license is to create risk and uncertainty through poor definitions and vagueness.
It’s really not, the aim of the GPL is to preserve freedom to tinker and reuse for all users.
If that’s not something you’re wanting to do, then it’s best not to use GPL components.
I'm just not convinced that the lack of clarity which tends to steer large companies away from such software is just a bug, not a feature.
this is literally FALSE
It doesn’t practically change much for most developers, but imo it underlines a bit of the challenge of misunderstandings and the complexity around the sharp corners of open source, in particular outside of the US as most licenses were designed in the US by Americans.
2. USSC claims Google's copying Java headers is fair use.
3. Many jurisdictions does not have a fair use doctrine.
So the question is, do you think Google is infringing the GPL by copying headers into Android, according to the most restrictive interpretation or the most restrictive copyright regime?
I think the unfortunate truth is that, for some reason, only US copyright law seems to matter.
We (corporate contributors) are simultaneously big contributors to OSS and seen as an enemy.
I can’t blame them, especially with cases like this French one. But it does mire a lot of discussion.
While it seems technically permissible, to me it also muddies the original code’s licensing as well, especially if not well known.
It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license.
I happily call out a surprisingly under-appreciated case of this…
We only have KVM virtualization on x86 today because Citrix meticulously developed an x86 instruction emulator (many thousand lines of dense code).
The Linux kernel took that BSD code and relicensed it as GPL. Sure, at some point one might argue that later modifications by the Linux developers are significant contribution that makes are unique… If I observe a good change Linux made, it is perhaps now questionable that as a 3rd party I create a PR to push the same change upstream… This is an accidentally evil side of GPL that isn’t talked about.
But at least in the early days, it also means one cannot freely use Linux’s copy but can do so from Xen —- even though it is the exact same code!!
Licensing also invites a trap where careless developers relicense GPL as BSD, and then a conscientious party unknowingly uses the BSD implementation in a closed source product.
The only saving grace is most code is horrible for reuse purposes and it is often easier to either reimplement it (from scratch) or use a well known BSD-licensed gem.
No it is not bizarre. That is precisely how the BSD license is intended to work. If you want to ensure that changes fall under the original license, then you want GPL.
> ...Linux’s copy but can do so from Xen —- even though it is the exact same code!!
Do you have any references for this? I went looking, but couldn't find anything to support your assertions. Neither code re-use/re-licensing nor origin at Citrix.
Origin at Citrix appears especially dubious, as KVM was present in linux kernel version 2.6.20, released almost a year before Citrix acquired Xensource. Also, Xen was originally developed at Cambridge University.
The only thing I thought both projects shared was their use of Fabrice Bellard's GPLv2 licensed qemu (some parts of qemu are under other licenses, but the main project is GPLv2).
> It is also bizarre that someone could take BSD code, make trivial modifications, and now such cannot be sent upstream or used under the original license.
That's the case for anyone taking BSD sources and turning it into a closed product, isn't it? Even if you get the BSD-licensed sources, the trivial modification will not be upstreamable.
That's kind of the entire point of permissive licenses, as opposed to copyleft, isn't it?
Wasn't this the, "if the source is in your tree everything is GPL" and otherwise "if it's downloaded module as a package it is not"? Or was that LGPL? Asking to show clarification for everyone.
edit: the question was stated as ignorant to get a few decent explanations. Thank you for the effort!
1. You give your user a non-GPL python package with requirements.txt file (no bundled dependencies)
2. Your user pip-installs the dependencies (including some GPL-licensed ones)
3. Your user runs the application
As long as your country doesn't consider use of an API prohibited under the copyright of the implementing code, I think steps 1-3 would be fine (though not very practical for a product).
I'd be curious for others input, though, as this has bugged be for a while in the R community where several core libraries (like the Matrix package) are GPL licensed but many packages that depend on GPL packages claim to be licensed under MIT or some other license.
And then it becomes a problem of proving your users violating the GPL. So you'd have to go after each one of them, which will be incredibly difficult, and proving damages would be even more difficult.
It's an asshole way of exploiting "Wo kein Kläger, da kein Richter" (where's no plaintiff, there's no judge) since actually proving that the developers violated the GPL will be difficult, unless they have a CI system that readily documents this.
However, distribution also happens in places you might not expect. As a business, I'd stray far away from such constructs even if I only use this construct internally.
However, this is purely based on the wording of the GPL. For example, the EUPL explicitly covers the creation of derivative works - and I'd argue that the proposed circumvention would create a derivative work.
Though I can certainly imagine that a multinational company might not be confident of the copyright status of API usage in all countries they operate in.
What you described only okay with LGPL
Pretty sure the prevalent opinion was that it was going to be the end of the world if the US Supreme Court ruled that APIs were copyrightable in the Oracle v Google case.
Just say'n.
1.) Hire a bonafide poet (e.g., someone with an MFA degree in Creative Writing).
2.) Have them write Haikus on salary for your company ("work made for hire" under copyright law).
3.) Use the Haikus in your API names.
e.g. for a sqrt() function in Java:
public double sqrt___an_ancient_pond_$_a_frog_jumps_in_$_the_splash_of_water(double number);
Within this discussion if you take a GPL'd piece of software, a "program", and interface to it via pipe/exec you're just using an external program, you're not linking to it and are 'immune' from GPL 'contamination'. If not it would effectively not be possible, or very difficult, to run commercial license programs on Linux, for instance.
If you are (for example) shipping a product which is effectively a thin wrapper around a GPL 'd component, but instead of linking to a GPL'd library you've written and dutifully GPL'd a small shim program that turns the library into an executable and reads function arguments over a pipe, then you call that from your 'non-GPL' code... I don't think you'll find the process boundary is some sort of absolute defence in law.
In fact you may be looked upon unkindly in court for having knowingly attempted a license circumvention mechanism.
The law is not necessarily sensitive to the exact inner workings of a turing machine, and the definition of a derivative work may or may not be affected by such shenanigans.
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.
I use the pipe/exec loophole to include a GPL program in a proprietary one. I personally decided that the proprietary code can be considered an independent and separate work because it's still does something useful without the GPL component. Also, you could swap the GPL component for a 3rd party proprietary one, which actually exists and uses the same interface for communicating via files. So to me, it's just a generic interface and I'm distributing the GPL program together as "aggregation" of separate works. For the sake of human relations, I also got approval from the GPL program's author to do this but he admitted he wasn't sure, and neither am I.
An example of what I have in mind: Let's say that you write a program and for some functionality it needs to grep files. Now, instead of programming this from scratch you just exec/pipe grep and grab its output. That's does not make your program GPL'd although grep is.
Packaging grep with your program to make distribution easier (if needed) does not, either.
The ambiguity is in whether the two programs (proprietary and GPL) together count as a "work based on the program". Your grep example seems to support the idea that they don't, and it wouldn't fall under the operating system components exemption because it "accompanies the executable". But then where is the boundary? Others have said you can't make a GPL shim to convert a library to an executable then use it in this way.
A GPL library is a trickier case because it's all about linking to it and potentially how that is done.
My guess is that if the shim converts the library into an executable that is usable in itself generically then you're fine (e.g. you turn some 'libgrep' into grep then uses grep). But if it only implements something like RPC through pipes specifically for use with your own program then someone might decide that this is just convoluted 'linking' and falls within the licence.
"But when you distribute the same sections as part of a whole which is a work based on the Program..."
No matter how you distribute them, they never formed a "work based on the Program" anyway so the GPL doesn't spread.
If all that's correct, it seems to leave a loophole that I mentioned where you can fork the original program to make it specially compatible with your proprietary program and redistribute it under the GPL. Now when you combine them you're not modifying it because you (or your friend if need be) did that before you obtained it and the modification is none of your business.
"GPL-2.0, with an explicit syscall exception"
That's for the kernel, right?
My comment was general and about all the interactions betweem programs.
Edit:
yes! And it in the general case it get really twisty and interesting. The classic example is a GPL cloning the functionality of a closed source program, down to arguments and options. Now, if you made some sort of closed source plugin for the GPL program, that's OK, if the plugin API was part of the originally cloned program.
However, if the plugin API was an innovation in the GPL program, then a proprietary plugin the can easily be infringing. (And as always with GPL, only on distribution.)
LGPL allows dynamic linkage without open sourcing your components.
GPL requires any linkage to open source your parts, but allows for process boundary to not be viral.
AGPL is the nuclear don’t touch because it is vital to all possible usage types.
Again, that’s trivializing because there’s many subtle details that in many cases are intentionally not clarified in the licenses themselves
The only difference between the AGPL and the GPL relates to software you don't distribute, but that you make available over a network, such as hosting an AGPL web server. The AGPL says that as long as public users interact with this web server, they have the right to get the code and deployment instructions and AGPL rights to be able to run the exact same service themselves, just as if they had downloaded the software.
The FSF's (very reasonable) position is that linking to a piece of software makes your software a derivative work, but that launching it as a separate process or accessing it over a network generally doesn't. However, if you exchange very complex internal data structures with this GPL software running in a separate process, whether you do it over a network or through pipes or command line arguments or whatever, then your program is still a derivative work, in their opinion.
That is, if you run gcc in a separate process but then mmap() it's memory and search for its entry points and jump to the memory locations of GCC functions in order to generate optimized code for a piece of GCC AST you provide, then your program is a derivative of GCC (according to the FSF, at least) even though GCC is running in a separate process.
If you instead, modify/customize the source of the AGPL-covered service, then you are required to make available your changes to AGPL-covered product under a AGPL license.
Is this a correct understanding of the situation? If the product implements a publicly documented protocol to communicate over the network (ie, not "complex internal structures", and/or replaceable with another product), is that permitted?
Also static linkage provided you provide users with the object files so that they can re-link with a modified library.
> GPL requires any linkage to open source your parts
With the exception of system components. Maybe that is what is causing the confusion because it's not intuitive why you can ship proprietary software that uses glibc but can't ship proprietary plugins for a GPL program.
> AGPL is the nuclear don’t touch because it is vital to all possible usage types.
That is an absurd viewpoint bordering on FUD. Affero licenses are only a problem if you are trying to work around the license terms. The license does fix loopholes for networked use that allowes SAAS providers to skirt the GPL but it is NOT any more viral than the GPL. Commercial use of AGPL software is absolutely possible - see e.g. cloud providers. Most GPL software probably should be AGPL.
One person’s skirting is another person’s complying. Most of what AGPL proponents argue is skirting GPL by SaaS companies seems like straightforward compliance/conformance to me.
And I’m not saying that AGPL can’t be used, in the same way I’m not saying other GPL can’t be used. You’re misunderstanding the context of the comment.
The comment was in regards to: what are you allowed to do without having to fall under the purview of the license.
In that sense, the AGPL specifically exists to close off many areas that the GPL didn’t touch.
AIUI that's a far from settled question in copyright law (with e.g. Oracle vs Google being mostly reversed on appeal, and different courts applying different standards). For someone who's not in the business of copyright minutiae, it's not a completely unreasonable belief to have.
The equivalent of Oracle vs Google here would be if you rewrote the exact same python module with exact same API names, but all your implementation was clean-room implementation. Here the question is, if the APIs themselves are copyrightable.
Well, not quite - shipping code with your code would be, because that is direct distributing. But if I ship a script to download your GPL library from PYPI and just use it as it comes, the argument on whether my application is a "derivative" of yours, is not an easy one.
Importing a module doesn't generally mean you include that module in your code. It only means you made use of that module's API. So whether that API was copyrightable is very much relevant.
At some point Google just took the headers of OpenJDK (GPL licensed) and used it in Android, without relicensing Android to GPL. ( https://arstechnica.com/tech-policy/2016/01/android-n-switch... )
Apparently this is fair use according to the US Supreme Court. Technically speaking the case that went to the USSC concerned some prior closed source version of Java, but Oracle doesn't to think there's a material difference since they're not suing Google again for that, and neither do I.
The FSF's argument that linking to GPL libraries require you to relicense the code to GPL rests on the legal argument that APIs, headers, etc. are copyrightable. USSC decided that, well, for only for Google's case, sure, fair use, whatever.
IMHO the GPL was drafted and marketed specifically to make its legal position seem uncertain, and the outcome of the Oracle v Google case doesn't make things clear. I'm not sure whether you'd actually see a court make a decision on the "GPL" given that the case would almost certainly be a matter of copyright infringement, not a matter of license interpretation, so the license text does not matter. If I were a lawyer I'd advice corporate clients to steer waaay clear of anything GPL.
Most importantly, the only reason the courts decided Google wasn't in violation was that Google's purpose, providing a compatible re-implementation of Java for Android, constituted fair use of the interface definition, so Google didn't need a license to use the OpenJDK headers. If Google had copied the OpenJDK headers in order to implement an entirely different system that used the OpenJDK code in a different way, the case would have gone in a fundamentally different direction.
Secondly, the legal reasoning for the GPL goes like this: by default, you don't have any right to re-distribute anyone's code (unless some fair use exception applies). The copyright holder can give you certain limited rights through a license - in our case, the GPL. The GPL can essentially impose any conditions, and if you think they are too onerous, then you just don't redistribute the code, period. If the GPL says "you can't re-distribute my code if you link your program with it unless you also distribute the sources of your program, including all precise compilation and installation instructions, and give your users the same rights and obligations", then there is nothing to dispute. The GPL could have also said "you can't redistribute my code unless you throw a penny in a prominent wishing well and light a candle in 3 different churches", and that would have been binding as well, if you wanted to re-distribute their code.
The subtleties come when you don't actually want to re-distribute GPL code, but would like to interface with it. Say you want to distribute a program that only works if dynamically linked with GCC. If you publish a bundle on your site with your proprietary program + gcc, you are clearly under the incidence of the GPL, since you are distributing GCC and are dynamically linking with it. However, what if you don't distribute GCC at all, and just tell your users "download my program, and then install GCC under /opt/propritary/utils/gcc"? In this case, is your program bound by the GPL or not?
This is a much more complex question, and it is here where you get in the nitty-gritty of what constitutes a derivative work in software. If your program is considered a derivative work of GCC, then you are distributing a derivative of GCC and so you need to respect the terms of the GPL. However, if your program is not a derivative of GCC, then you can entirely ignore the GPL, since you are not stepping on anyone's copyright and so don't need a license. I believe this question is entirely unsettled, and there are plausible arguments (to a layman like myself, at least) both for and against it.
The idea of derivative work is clear, the confusion is how the FSF kept pushing their interpretations of it.
Programmers are usually not lawyers, and taking legal "advice" (or rather trying to learn legal concepts) from the FSF is not exactly the wisest thing to do.
There's been a lot of confusion why linking GPL libraries would be a "derivative work", and apparently the FSF's stance is... well unless it doesn't use inline functions and macros ( https://lkml.indiana.edu/hypermail/linux/kernel/0301.1/0362.... )... but let's just tell everyone you can't use GPL libraries in proprietary code.
So we have a bunch of rumors about linking mechanisms, speculations that the GPL cares about static vs dynamic linking, kernel interface calls, classpath exceptions, etc.... which shouldn't be a part of the conversation at all, at least not without considering the broader context of how the proprietary software relates to the GPL software.
Isnt the fact that it has taken this long and required a straight up violation of the direct terms of the licence proof that people were probably justified in not caring until now?
There is nothing fundamentally dangerous with the LGPLv2.1.
It is mainly annoying in case of static linking due to the obligation of providing object files but will not contaminate your codebase like the GPL does.
The important part is that you should be able to modify the LGPL library that the application uses. In the case of a python module or plugins, it is possible, so that's ok for LGPL. You can even statically link LGPL libraries with your proprietary application as long as you provide a way to relink your application with a modified version of these libraries.
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
> It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.
> If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.
No company should ever do business under terms that are this unclear. It's just asking for trouble. Use another licence that is not this ambiguous.
That scenario is not a good fit for LGPL.
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
> If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins.
The L/GPL would widely consider Python imports as dynamic linking.
Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result.
This too is somewhat of a grey area though that the GPL is vague on.
My reading of the GPL is that if you are the rights holder of some software, and there is a xGPL licensed plugin to said software, you can only distribute changes to the plugin if you also distribute your software as xGPL. In other words it is impractical for you to make changes to xGPL licensed plugins to your software.
> Many companies will instead do shim/bridges that aren’t GPL themselves but something like MIT. The bridge talks to proprietary code and the GPL but doesn’t bridge the license over as a result.
I'm fairly sure this is not legal, see https://www.gnu.org/licenses/gpl-faq.en.html#GPLWrapper
The point is there is too much in the GPL that is open ended and can only be known for sure after litigation.
Unless the GPL was enshrined in some law I'm not aware of, it's likely to be a a breach of contract, not necessarily "illegal". If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing.
The GPL licenses give you specific permission regarding copyrighted work, provided you comply with the terms. If you do not comply with the terms, you do not get the permissions. If you then do something like distribute the work you are not in breach of contract, as you had no contract to breach. You are in breach of copyright, which is not legal as there are laws prohibiting copyright infirngement.
> If a court rules against you, in most cases the worst that can happen is having to pay some redress to the developer and stopping what you were doing.
Why do you want to leave this possibility open? Why not just avoid GPL and use a licence which is clearer, where you don't have to first go through litigation to understand the terms of the licence?
To be supremely pernickety one might argue that copyright is a tort, so it is tortuous infringement, which is unlawful (not allowed by laws) but not illegal (criminal).
But then one might also argue about how many copies of the GPL fit on the head of a pin.
However, in some jurisdictions some copyright infringing acts are deemed criminal; so not only is such argument futile but it can also be wrong according to the facts of the case.*
https://github.com/websocket-client/websocket-client/issues/...
It looks like that did get rectified a few years later:
https://github.com/websocket-client/websocket-client/issues/...