I’m glad there’s finally some cases setting precedent for the GPL.
I am personally not a fan of GPL family licenses BUT I am sick of fellow OSS developers who keep telling me not to worry about the minutiae of the license. (Usually some form of “Oh don’t worry because we aren’t litigious right now, as long as you stick with our incorrect interpretation of the license”)
My team is responsible for a lot of corporate contributions to open source (some GPL) and I have to pay extra attention to the license terms as a result.
There’s a lot of GPL software that operates in the grey (and many OSS devs who don’t understand their license choices), and I very much like my licenses to be as black and white as possible so I can avoid any risk.
Having legal precedence to point to will help make concerns concrete.
Do you have examples? What kinds of misunderstanding are there? And what gets clarified by this case that wasn’t clear before?
I can’t give specific examples without calling out some projects.
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.
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!
Pipe/exec into GPL generally considered okay (not a derivative work)
What you described only okay with LGPL
And pipe/exec not because it's a magic boundary, but because that kind of interface is often so generic and simple it's not constituting a derivate work to use that boundary. But one could easily come up with an example where it is.
It is a "magic" boundary in that it is an interface to another process, i.e. effectively another program altogether.
Another process is not necessarily "another program altogether". What presents as "a program" to the user may be a collection of several processes using a variety of IPC methods to interface with each other. "Process" has a fairly concrete technical meaning but "program" is more loosely goosey. A shell script could be called "a program" even though it's executed by a shell process and invokes dozens of other processes, without which it is nothing.
That's a nitpick.
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.
It would not, however, Linux has:
"GPL-2.0, with an explicit syscall exception"
Deleted/Edited (sorry...):
That's for the kernel, right?
My comment was general and about all the interactions betweem programs.
How else do you run programs on Linux?
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.)
I think that's probably an interesting case, and whether it's a valid defence is going to depend on what you're doing.
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.
It's extremely entertaining to see people here arguing that programming and software interfaces should be copyrightable and therefore protected by the GPL.
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.
Looking closer at the GPL, it seems like most requirements only kick in once you "convey" GPL-covered code. If you make your users get the GPL component themselves from a 3rd party (e.g. PyPI or other package repository), then you might be okay. I'd be curious for input from others, but it seems like the following flow avoids GPL virality by avoiding "conveying" the GPL-covered code to the end-user:
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.
The end result will most probably violate the GPL. However, this is only realized by each user; you could probably argue that you never test your software and only look at API documentation.
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.
As a pure copyright license the GPL concerns itself with distribution only. You cannot violate the GPL as an end user without distributing something.
Yes, all of the above is on the condition that some distribution happened (and you can prove that).
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.
Yeah, the crux of the issue would definitely be whether use of an API is prohibited by default under copyright law for a country (i.e. does using a library make something a derivative work of the library). In the US, at least, the Google v Oracle case makes me think this is worst case fair use (for many contexts) and best case too functional to be covered by copyright in the first place.
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.
I'd further argue that it would be important if your program does anything useful without the GPL parts; if so, you can probably argue that it is not a derivative work. If you however only build an extension to some GPL'ed software that fundamentally needs the GPL'ed code to properly function and cannot (easily) be used by any other software, then you probably will create a derivative work.
To be pedantic, you can't actually violate the GPL. You infringe on the owner's copyrights if your actions don't fall in the GPL's allowed actions.
Yeah for interpreted languages this may be OK. For compiled languages it becomes harder to not "convey" anything derived from GPL code you linked against. The GPL even explicitly exempts system components for this reason.
Even for compiled languages, you can get around this with a properly architected plugin architecture. Your core project (non-GPL) exposes a runtime plugin interface. It has no clue what plugins will be used, but provides all the operations needed for the plugin to do what it needs. Create a plugin which links to the GPL code. GPL the plugin itself. The user can then be directed to install the GPL plugin. I can’t see how this would be a violation (by the core developer) of the GPL, as the core doesn’t have the first clue what license its plugins are using, and indeed, multiple plugins could be used that have contradictory licenses.
I’m trivializing here but for sake of brevity:
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
There is no difference whatsoever between the GPL and the AGPL for software you distribute.
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.
A few articles I've read suggest that the AGPL terms trigger if you MODIFY AGPL covered code. So if you (1) setup an AGPL service over the network "as-is" with no changes, (2) use the AGPL-covered service from your proprietary code over the network (ie, across a process boundary), then you are in the clear, and your proprietary code can remain closed.
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?
I am not a lawyer, but my understanding is the same as yours - if you host a proprietary service that has some AGPL components (say, an AGPL authentication service that users interact directly with to get a token, that they then pass to the proprietary parts), then you only have to make sure that the source code for the AGPL part is made available (or not even that if you are using it completely unmodified).
Also static linkage provided you provide users with the object files so that they can re-link with a modified library.
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.
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.
Linux dual licenses glibc so that it can be linked without falling under the GPL
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.
Interesting examples. Also, a weird take for them to think that’s not triggering the virality, if not that, what then? Directly using the source code only?
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.
Usually, the developers (and this is over multiple different GPL projects with different leads) have the following thought:
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.
I think I'm with you on this in general
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".
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.
Both things can be true. The wealth of comments in this very discussion from people who aren't sure what exactly is and isn't permitted under the GPL shows that it is vague.
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
Whether it is vague, and whether it is purposely vague as a mechanism to achieve its aims, are different phenomena to the aim of the license. IMHO.
Yep, that's what the GP said.
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.
I believe this is coming from the developers of a piece of GPL software who want to allow proprietary extensions. However, extensions to their software must import a python module that they created to register with their software or something. They don't want to invest time in separating that module and its dependencies into a different project with a different license (some variant of the LGPL), so they choose to believe that importing a python module is somehow different from linking a C library.
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".
If the writer is the only copyright holder, if they just put the exception in writing, it's still OK. Like the exception for the Linux kernel to load proprietary binaries.
Sure, but if the copyright holder is a foundation, you actually need some legal representative to put that in writing, a single dev writing something on GitHub wouldn't mean much, even if they are the sole maintainer.
IANAL that seems to be a distinction without a difference.. you say yourself "the copyright holder" then make a gray case about some entity holding legal ownership that is not the copyright holder.
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.
Sorry, I should have been more clear. I meant that it is fairly common for a project that has a single author and contributor to nevertheless be developed as part of an organization such as Apache. So, even if that single author is the de facto owner, they may not be the legal owner of the copyright.
This perhaps works if a project is new.
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
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.
Not really. Including code in your code would always be a copyright violation. The Oracle vs Google case is very different. The OP is talking about copying implementations while Oracle vs Google is about copying APIs.
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.
> Including code in your code would always be a copyright violation.
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.
It's potentially not an easy one in law, but it is one that the GPL is explicitly intended to capture. The only question is whether it has successfully done so (and that actually depends on the specifics of the usage, as I understand it).
I'd say plugins are mostly safe. In case of java interface isn't part of plugin, so no copy is involved.
The European Commission have published an interesting article disputing the possible viral effect of linking in EU law: https://joinup.ec.europa.eu/collection/eupl/news/why-viral-l...
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.
Interesting opinion but even if the courts will agree it is not relevant because most software is intended to be distributed globally (including at the very least the US market) and will have to comply with most restrictive interpretation of the license.
1. Google has taken the headers from OpenJDK (GPL licensed) into Android ( https://arstechnica.com/tech-policy/2016/01/android-n-switch... )
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.
The conclusion of the article says "[...] so far linking (even statically) is done for interoperability, does not [...]". IANAL but it could mean that linking against a GPL library for interoperability is OK in EU, but it does not mean it's true for general case of linking with GPL libraries.
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/
The term "derivative work" (or similar) is sometimes defined in law, but of course very abstractly (i.e. not specific to software) and differently depending on jurisdiction. (See https://en.wikipedia.org/wiki/Derivative_work) IMO it's exactly because of this ambiguity that many developers' understanding of the term is likely to be incorrect, and that most of us don't really understand what our license choice entails.
I think a better way to say this is that every developer's understanding is absolutely incorrect in some jurisdictions. Maybe they're correct in their jurisdiction, but once you start talking about this online, as with every discussion of legalities on HN, people start talking past each other forgetting that many European countries will disagree with each other, and especially forgetting that the US may have several dozen wildly different interpretations.
Yes , exactly my point. The vagueness is intentional to cause this level of confusion.
I also hate when projects take BSD/Apache licensed code and change it to GPL.
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.
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).
I don't think you can change the license of existing code at all, unless you're the copyright holder. Best you can do is release someone's code as part of a work under another license. Anyway,
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?
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.
I'll tell you a fact that isn't popular or commonly known.
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.
I don't think this is how these rulings worked.
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.
I don't disagree with your take (though I don't know which part of mine you disagree with...)
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.
One argument for you could be that if there is no problem, why aren't they using MIT instead that works the way they want it? No need to use the wrong license if they mean something else.
It always comes down to “of course a corporate dev would suggest that so you can steal our work ”
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.
Extensions, importing, linking? If your (A)GPL licensed app has a plugin framework, does that 'infect' all the plugins to be similarly licensed? There's likely different situations here, or no? Like e.g. Hashicorp go-plugin where separately compiled plugins are dropped into a directory and communicated to via gRPC cross-process. Or WebAssembly Components being composed together.
On the other hand, some people freak out too much. All I did was use a ghostscript dll, which is LGPL if I recall correctly. :/
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?
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.
What constitutes linking, dynamic linking, and static linking, if you use python and plugins? Can the rights holder of proprietary software contribute to or distribute a GPL or LGPL plugin for that software?
You don’t have to distribute the plugin as xGPL but you do need to make it compliant.
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.
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.
> this is not legal
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.
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?
{not disagreeing}
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.*
If it's a copyright violation, it's illegal. Worse if it's intentional
The important part with LGPL is not really about static vs dynamic linking.
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.
Fair enough, but it's still not entirely clear what constitutes linking, especially when it comes to Python, and what the situation is with plugins. The GPL FAQ Says:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
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.
Also you say static vs dynamic linking is not important, but here in the GPL FAQ there is reference to this:
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins
Even saying it's OK with Python is a simplification. In almost all cases it is but what if you compile Python to binary, strip its symbols, statically link, then for good measure, upload the binary to an app store.
That scenario is not a good fit for LGPL.
FFMPEG. Look at the amount of legal horse fertilizer here: https://www.ffmpeg.org/legal.html ... and every time I've seen people asking what they can and can't do, someone from the ffmpeg devs (once in a couple of years when they actually respond to someone) just says "talk to your lawyer". I mean, flip a few switches and suddenly you're under a different licence ... and all this you have to look up yourself. Many (especially smaller) devs just don't care and distribute ffmpeg together with their (often non-oss) tools. Given the amount of these in the wild, if someone really had an axe to grind, they could sue hundreds, maybe thousands of devs of all sizes. It's a total minefield. And one of the most popular (L)GPL packages in existence.
My experience with FFMPEG is that it’s usually not directly distributed for probably those reasons. The only times I remember getting it directly with software, was for GPL software.
Eh, I'm just gonna point out that you can find ffmpeg code (proprietary decoders even) distributed with Electron. I'm not even going to think about how many proprietary apps built on top of Electron have no idea about that. Look at the answer here: https://stackoverflow.com/questions/67799370/legal-issues-in...
It is currently pretty clearly describe. Compile it in LGPL mode and you are good for propriétaire use cases.
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 Python websocket-client library switched from LGPL to BSD without realizing you need to get all contributors to sign off on that.
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/...
It's a good thing to point out that judges are notoriously indifferent about "he said that she said" type arguments. In the presence of anything that looks like a license text or contract that's usually what they take as the starting point for a decision. In so far that is enforcable of course. Most longer licenses usually have some language stating what happens when certain things aren't enforcable.
With GPL, the version matters. I'm not aware of any GPL v1 licensed stuff, it probably was a bit short lived. But there's quite a few things licensed under GPLv2 and GPLv3. v3 tried to close a few loopholes v2 had that some companies working with e.g. Linux or Java see as a feature rather than a bug.
Many corporate lawyers don't like GPL style licenses and particularly AGPL because these licenses have a lot of things to say about things like intellectual property, patents, servers, and uses that are/aren't allowed that probably isn't OK with most corporate lawyers worth their money. With GPLv2, this stuff has been through the courts a few times so the industry seems comfortable with it at this point.
Whether those lawyers are right or not is not something engineers should be overruling based on vague notions of fairness, gut feelings, loose interpretations, etc. The whole "it's fine because we're all nice people" doesn't have much value in a court room. Licenses are for when people stop being nice to each other.
I prefer the MIT license for my own projects. It's simple and clear and completely uncontroversial with corporate lawyers. It has decades of use, is well understood, and has very little ambiguity. Lots of OSS is licensed with it. It's fair for developers and users. Users being able to do what they want with the software is fully intentional on my part. That's a freedom I give them with that license and not something I actively want to restrict. Fully understood and intentional.
One problem I see with the GPL (all versions) is that they make a big deal out of 'linking' your program.
And in a world were C was the only language that mattered, that might have been fine. But more modern languages might have more diverse notions of what linking is and ain't, and there might be gray areas, too.
Dynamic linking (also what most more modern languages do instead of traditional static linking) always has been an utter mess when it comes to GPL "virality".
It's completely untested in court and a lot of legal scholars doubt the reasoning and interpretations given by the FSF (namely that dynamically linking with a GPLed work transfers the same GPL license to that work) would be allowed by current copyright law.
More or less amounts to the question of "do you need to use parts of the original work to make a derivative work".
Another, possibly far bigger problem, is that it's entirely possible to effectively neuter the GPL with a secondary contract. We know this is legally possible because of what Red Hat does (cut you off as a customer if you redistribute the source code of RHEL) as well as a far more direct legal case in Germany where a WordPress theme maker was able to prevent distribution of a theme they made by arguing that the contract made when the theme was sold overrode the terms of the GPL and prevented the buyer from sharing the theme because of agreed to terms in the contract.
Unless the GPl'd work provides a novel API that the GPL code implements; that has been tested in court. The API is protected, by copyright, and linking to that API requires the use of the API. That's why you can't just link to GPL'd code will-he–nill-he, without the possibility of serious repercussions.
That phrase you're looking for is willy nilly. You did a bone apple tea.
Shakespeare had it as will he nill he in Hamlet:
Though I admit I didn't know this until I actually looked it up just now :)
“Will he nill he…” huh, I wonder if that’s the etymology of the modern expression. “Willy-nilly” just seems like a nonsense phrase. “Will he nill he” could be read as “will he or will he not,” right? It seems like only a couple short conceptual hops to go from “whether or not he decides to do something” to “look at all the random things he could do.”
Bone apple tea, with an em dash to boot
will (hypen-minus) he (en-dash) nill (hyphen-minus) he
API protected by copyright? Sounds like a judge somewhere dun goofed, that just makes no sense on the face of it. The specific IMPLEMENTATION of an API maybe, but not the API itself.
https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America%2...
It's pretty clear what it means, based on the goals of the license: To allow the user to easily replace/modify the (L)GPL licensed (part) of a program.
For GPL, that means you can only include GPLed code if you make the whole program available for user to modify and redistribute.
For LGPL, you can include LGPLed code if you make just the LGPLed part of the app available for easy replacement. (so normally this means some form of dynamic linking, and very commonly used in practice with eg. glibc)
So if some company statically links (L)GPLed code to their app or makes it in other ways hard to modify/replace, it's a violation.
Except the "whole program" bit is in question here. A lot of legal scholars doubt that using the GPL in the way the FSF wants it to be used when it comes to linking would actually confer the terms of that license to the final product (because the FSF wants it to be considered a derivative work of the GPL code). In the EU, it's to the point where the EU themselves have written guidance that they doubt this interpretation applies[0]. This would effectively limit the scope of the GPL to always function like the LGPL/MPL (or any other copyright license that limits the copyleft element to the parts of the program actually licensed as such, as opposed to spreading it across the whole work.)
The problem is that the GPL isn't the law; it's something (a license or a contract, the interpretation of which is a toss-up; the FSF wants it to be a license since it allows shrinkwrapping the terms, all legal enforcement has it treated as a contract) that relies on existing law to function. Which fails to work if it tries to do something that legal framework doesn't allow you to do. You can't enforce copyright over derivatives if it's not considered a derivative to begin with.
If the FSF conceded that the GPL was actually a contract and were to write more explicit terms stating that this is a requirement to using GPL'ed source code, they'd probably not run into this problem, but because they insist on forcing it through the framework of copyright the virality of the license only goes as far as the definition of derivative works go.
[0]: https://joinup.ec.europa.eu/collection/eupl/licence-compatib...
What case was that?
Yes, but it's a different license! It's not really comparable with regards to preference because the goal of MIT or BSD is different to GPL.
If $PROJECT-1 can be modified and then redistributed as closed-source by $COMPANY, then MIT is a good fit.
If $PROJECT-2 must only ever be redistributed if $COMPANY redistributes their modifications and derivatives as open-source, then GPL is a good fit.
It depends on the specific project, which is why I cannot say "I prefer MIT" or "I prefer GPL", because for some projects I don't want it repackaged and released as proprietary software, while with others I do want others to repackage and redistribute as proprietary software.
Proclaiming a preference for one type of license over another is akin to saying "I prefer bicycles", because you aren't going to prefer bicycles when needing transport to move house.
I disagree. The GPL is fundamentally an ideological document with an ideological purpose in a way that the BSD and MIT licenses are not.
All software and copyright licenses are ideological documents. You don't see the ideology in BSD and MIT because it is your preferred ideology.
Please read what I wrote more carefully. The phrase "in a way that the BSD and MIT licenses are not" is doing important work, namely implying that there is a way in which MIT/BSD are ideological.
Perhaps ideological came off as an aspersion? I certainly didn't mean it as one. It's just an observation, and frankly a pretty obvious one. I'm quite sympathetic to the Free Software movement and, at least in the first order, would be happy to live in a world where all software is copyleft.
BSD/MIT is essentially reverting to the natural conditions that would obtain without statutory copyright. GPL on the other hand is actively attempting to motivate sharing and respect for user freedom in a way that is far beyond the natural state of affairs. Thus it's fairly described as ideological in a way that the former licenses are not.
You aren’t discussing the controversial part at all. You have laid out the part that everyone agrees with.
GPLv2 means you pass your modifications back - easy.
GPLv2 might mean that by calling a libraries static functions from your code, that is a “modification”, and now must include code that is not logically a modification at all. This is even more grey area if you dynamically link them - hard.
“What is a derivative” has feed millions of lawyer’s family’s, imo this type of broad interpretation does not belong in OSS. Give it to me or don’t, I promise to pass my modifications back, but don’t pretend that integrating it into my code is modification that allows you to see what I do with it.
LGPL makes more sense. But GPLv2/3 has a business model and that is why it is popular and complex.
I wasn't discussing any part at all, I was explaining why the goal of the project determines the license and not the preference of the authors.
If the goal is to allow others to close off the product, then one license is suitable. If the goal is to prevent others from turning it into a closed source product, then you choose the other license.
When the goal is "popularity amongst closed off companies", then one license makes sense. If the goal is "popularity for the community" then the other license makes sense.
There was a no value in arguing over which is easier for companies unless the goal is popularity for companies and o close off.
After all, any company that simply wants to use the software without redistribution doesn't really care.
I am sorry but your view is dying out because it’s unrealistic.
Most things in life have grey areas, most things in life have legal concerns and liability attached.
Even the simplest possible things, like If you sell bicycles and someone breaks their neck, they could sue and there will be grey areas as to the bicycles’s quality. If you sell food and someone gets food poisoning, same thing.
The fact that software developers could make millions and never worry about law, is a giant privilege and it’s disappearing because software is no longer just for kittens and porn, it is now everywhere and it’s responsible for life and limb
Of course the corporate lawyers and enterprise settings are going to take this position, but I find your flippant dismissal of GPLs core uses and purposes seem to belie you are just in a group that prefers the non-user friendly licensing.
That’s ok, but you can’t hand wave away that GPL, especially v3+, is about protecting and defending the user (like tron), while MIT/BSD is not, by calling it “vague notions of fairness” as if GPL hasn’t already seen wins in the courts… on this point I think some research might be due for me though.
I’m just so very tired of the “hey me and my banker/lawyer/insurance friends all hate this - that means it’s useless and dangerous for everybody”
I say the GPL and copyleft and the four freedoms for the user are the tools we use to fight these types of corporations in the first place, and I truly believe not only is GPL not dead but that it will play a vital role in our near and long term future.
Choose your weapons wisely.
Imo the question is do you want to protect passive users access to the code or developers freedom to use the code how they want it even if that does mean they take existing code, modify it slightly, put it in an embedded device, and enable temper protections on the MCU preventing anyone but them from signing new firmware images? If that embedded device is something harmless like a video player or gaming console most open source developers would probably like to use the license as a crowbar to force the device open, but what if it's a medical device, or a payment terminal the user is explicitly not trusted to modify?
If anything medical devices, especially implants, should be modifiable. Otherwise you're stuck with an unmaintainable device (possibly in your body) once the manufacturer goes out of business or the support window ends or whatever. Right to repair and all that.
And this is a very real concern. https://spectrum.ieee.org/bionic-eye-obsolete
For external devices breaking some big, visible "last inspected on XX/XX" seal to do so would be acceptable.
For payment terminals you could do the secure boot thing where replacing the manufacturer keys and flashing custom firmware wipes the TPM storage.
For payment terminals the core problem is that the trust model is ass-backwards. The user is the one at risk from a faulty authn device, so they should be the side "controlling" the authn flow. Merchants would be fine just carrying dumb plastic cards with an ID number. Though these days there's little reason not to just make both sides smart… it could even run on the phones they already have!
It sacrifices the user's freedoms for this. Which is exactly the concern corporate lawyers have with this. Fine if that's what you want but the net result tends to be the vast majority of big companies pretending your project does not exist. Can't look, can't touch, can't use, etc. If a blanket ban on your project across most commercial users is what you are after, AGPL does the job.
Good.
Even so that point is wrong as GPL software is widely used in the industry (Linux, gcc, gnu make, etc).
The main downside with GPL licenses, from the perspective of corporations, is the requirement to share your changes if you distribute the code. GPL v3 and AGPL were both designed to close loopholes that were useful for certain corporations that didn't want to open source their own code. I believe the main ones were "Tivoization" (devices where you can't run modified code due to DRM) and cloud SaaS services where modified GPL code is run without sharing the changes because technically the cloud is not "distribution". GPL v3 was designed to stop the former and AGPL to stop the latter.
FAANG companies generally hate AGPL and ban the use of code licensed under it which is a backdoor way of admitting that their cloud platforms include modified GPL code whose changes are not publicly available.
The permissive licenses like MIT and BSD allow corporations to take your code and modify it without paying you or even sharing the changes with you. All they have to do is give you credit. That's not something any sane corporate lawyer is going to care about.
Both of these types of licenses permit commercial use without paying the people who wrote the code and the entire FOSS community rejects non-commercial licenses as "not open source" at all. Corporations only object to GPL because it prevents them from taking other people's work, modifying it, distributing it and profiting from it without sharing their changes. That can reduce corporate profits by allowing competitors to build derivative works off of the same code.
Personally, I'd prefer if there was a major non-commercial license for code because that would ensure nobody is profiteering off of my work without paying me. People who aren't in this line of work find it strange when you explain to them that somebody could write a portion of a highly successful product and never see a cent in royalties from it.
Non-commercial licenses are considered non-free.
If you intend to be share your code with the world and don't want others to profit on your work without giving anything in return, go with something like (A)GPL. Sure, people will be able to profit on your work, but in return, you get all their bug fixes, testing, support, and improvements.
You have to realize that most contributions to GPL software is made by people who work for money, something that a non-commercial license would not let them do. So by releasing your software with such a license, you prevent the best people from eventually contributing. And why would you open source your software if not to take advantage of the contribution of others (in code or otherwise)? Another reason why you would want to publish your software under GPL (or compatible) is to make use of other GPL (or compatible) software and libraries, you can't do that if you publish under a non-commercial license. So, lots of drawbacks, few advantages.
If you really insist on using a non-commercial license, there are a few listed here: https://www.gnu.org/licenses/license-list.html#NonFreeSoftwa...
Sure, but GPL is fair as well. Just differently.
I like MPLv2, because it seems like it is exactly equivalent to MIT for projects that don't modify my code, and if they do, it forces them to distribute the changes they made to my code. In practice, I strongly believe that it gives developers leverage against their management: as a developer, I can say "I must upstream my changes because it's MPLv2" (which is not exactly right but managers don't really understand it anyway). MIT doesn't give me that leverage: managers know too well that they can just pretend it's theirs (often even forgetting attribution).
Where do you see that attitude in the OSS world? In my experience that's how the games industry operates wrt to mods but for open source projects you usually have a clear license IME.
I worked for a Multinational US company that was doing business with a Scandinavian company. The Scandinavian company wrote a GPL plugin to our software and wanted us to make contributions to it. We didn't think we could do that and still be within the terms of the GPL, they insisted that we could because they would be fine with it.
As the author of the GPL code they have the authority to dual licence it, so surely the fact that they state they are fine with it (especially if in writing) would be enough?
I'd worry the other way, if you're contributing to the GPL code, you'd need to relinquish your rights to any IP contributed to the third party.
Our concern was not that our contribution would be GPL licensed, our concern was that we didn't have permission under GPL to distribute the contributions even if we were fine with them being GPL licensed. For details as to why we were concerned, see https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins - for any company that should be a clear signal to stay away.
An employee of a company saying it's fine in an email is also not issuing another licence. We did suggest they use another licence than GPL, which they eventually did after months of arguing with them that just saying "it's okay because we don't care" makes no material difference to us and that GPL does not unambiguously provide us permission to do what they want us to do.
Hah, yeah, an employee saying that without executive authority would be a big no.
But according to this [0], I read it as quite clearly not allowed to GPL a plugin for distribution within a non free program, even if the plugin was unmodified.
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF
But that is contingent on whether it is one work on not, which in GNU's speculation depends on how it's linked, which is not clear how to understand this for Python, and the intimacy of the communication, which is not something which we can objectively measure. We believed it would likely be one work, the plugin’s author believed it would not be. All of this was just months of wasted energy, spending arguing about licence terms instead of coding.
Of course it was fine, they were the copyright holder. I assume your contribution copyrights were transferred to the other company? As they were publishing the whole plugin as GPL.
I'm not sure why you would assume this, but it would not have happened.
Furthermore, given this https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins - and given there were no exceptions in the plugin, it just seemed like a complete mess to us. Of course the Scandinavian company disagreed because, as I said, they figured we should not care because they are okay with it.
Just quoting from above:
I think it's strange how you can be entirely sure about something which the GNU is not sure about, but the thing is neither the GNU's speculation or yours would be relevant, it would have to go through costly and time consuming litigation to know for sure.
Why would anyone want that?
Given that France uses Civil law and not Common law, does precedent / case law actually matter? (IANAL.)
* https://en.wikipedia.org/wiki/Civil_law_(legal_system)
* https://en.wikipedia.org/wiki/Common_law
It matters in an advisory sense (that is, other courts may use it to gain understanding), but not in a legally binding sense.
Some, but not all, precedents are absolutely legally binding in the French system, they have the same force as the law (unless a later law contradicts them).
In practice, precedence has about the same legal power in both common law and civil law jurisdictions.
That is civil law courts tend to go with the precedent most of the time on the one hand. And on the other hand, a common law judge can always do a bit of nitpicking to argue why the case before her is special and thus different enough from the precedent (or she can pick from multiple different precedents, and then come up with a justification for why the one she picked matches the case before her the most).
Yes, not sure if this is the case but higher courts in civil law systems tend to have some precedent setting powers. It's just more limited than in common law. I'm not sure if this is the case in this ruling in france, but even if it isn't
In a civil law system judges still are aware of previous decisions in similar cases and consistent application of the law is still a principle which exists. The precedent might not be binding but a judge who is in doubt will still uses existing case law and so will appeal courts. They will just always refer to the law as the source of the decision, not the previous cases
The legal precedent seems to be "If you steal GPL code, 14 years later you have to pay $650k - assuming the developer didn't give up before that"
One of the key advantages to a legal precedent is that the next time it won’t take 14 years.
France has a civil law system [0] which doesn't place nearly as strong an emphasis on precedent as common law does, so this specific case probably won't help speed anything up.
[0] https://en.m.wikipedia.org/wiki/Civil_law_(legal_system)
Precedent isn't binding in civil law systems, but that doesn't mean it is ignored. Especially when set by higher courts
There's been a few before: https://gpl-violations.org/news/