This just makes me more confident in choosing GPL licenses for my projects in order to ensure user freedom.
Interestingly in this case, this ruling also reduces intermediate developer hassle for devs who are already used to working with GPL code. So that's a nice win (=
Will be interesting to see where development / contributions by various players go in the future.
Actually it also reduces intermediate developer hassle: it's better if I don't have to rely on closed source firmware, firmware updaters, drivers, SDKs, proprietary tools.
It create openness in the whole software stack.
You of course may be sued yourself if you have a project using GPL'ed code that doesn't comply with the the current view of GPL (ie, release of encryption keys) or if you infringe your own GPL copyright in some proprietary project (ie, GPL code where user was promised access is in something that you don't want available broadly).
This is all good for users for sure for things like open core projects and projects that used to be open but moved away etc
That is what is so exciting / different about this. When you make available software under the GPL, you have now entered into a CONTRACT (not copyright anymore) with all users that binds you to the terms of the GPL and gives them a right to sue for violations of THEIR independent rights.
This is the power of this new ruling, they can then sue you or anyone for breaking this agreement with them. Obviously will take some experience to see how far this can be taken. My understanding is the conservancy may want to try to leverage this to try to get GPLv3 effects into GPLv2 and a few other things the developers of for example Linux are not so hot on.
Sure, anyone can sue you for anything. However nothing in this removes the copyright holders' ability to issue non-GPL licenses. A user of a product that uses a non-GPL license for that code would still have no standing for that suit.
Historically one could contribute to a GPL project (potentially on a significant level for a corp) but wouldn't worry too much about using it in your own product that was potentially locked down - ie, DRM / motor duty cycle control, rev limits etc.
Linus / Linux have a long history of being pretty relaxed about your use cases, with the one key provision that you share your code.
Now, the group of people who can sue you is much larger. And some of them (conservancy in particular) may have views that don't align with your GPLv2 interpretation (particularly around tivoization / lock down issues for hardware devices). So if you are contributing too and shipping GPLv2 code - yes, you as the distributor of a larger body of code probably have a higher risk now of being sued.
https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...
The main reason the GPL exists was to insure changes to code (forks) were available to original developers of the code so they could include those changes if they wanted (this was a result of issues with earlier unix systems that had fragmentation from forks). Additional, Linus, author of Linux, has been clear that his focus is getting code back, what happens to hardware was not covered in his mind by GPLv2.
So there is a dispute as to what GPLv2 requires with respect to hardware. It's clear that the code must be shared, and that's what a lot of GPLv2 devs have focused on. That the source code be shared, including scripts used for compilation and installation.
But (one view) is that is separate from mandating behavior of hardware, and that hardware can still check if its running approved code and refuse to run if approved code is not loaded.
That's why this case is so huge. The actual developers of Linux are not likely to try to enforce a term they don't think exists, the SFC very well may.
So what Linus wants from the GPL isn't even mentioned in the GPL.
It is only through a culture of contributing upstream and through upstreams reaching out to downstream redistributors and asking them to contribute upstream that anything gets upstream at all.
I suggest you read Conservancy's posts and the GPL, it does mention that installation is required to be possible and this requirement has always been present and enforced by copyright holders for GPL software, including for Linux itself.
Only if you had a time machine. Once you’ve distributed the code the horse has left the barn.
You can impose a new license on new versions of the software though.
> you infringe your own GPL copyright in some proprietary project
You can't infringe your own copyright. If you own the copyright to the code, you can't violate GPL by using it, even if that code is licensed under GPL. This is because a copyright holder releasing only their code under one license, can also release that code under another, proprietary license.
If you contribute to an open source project, then use that code in for example a locked down device, a user / conservancy who views that as a violation of GPL can sue you. That's important because historically developers on linux kernel have not agreed with conservancy views on things like encryption keys, and so have not pursued these types of claims and were somewhat unlikely to fully litigate claims against other contributors especially beyond just sharing code back.
As the conservancy notes, the universe of potential claimants (even with bogus claims) is now much much larger.
If it is only code you wrote and you haven't transfered your copyright to the project, then No, this creates no standing.
> That's what's so new about this. There is now a contract (not copyright) element - which binds you and the recipients of your code.
Incorrect, there is a contract that binds you and recipients of the code under a GPL license.
If you receive that code under a different license, that contract doesn't exist.
Edit: Let me put it this way. Let's say you create a library and make it available under GPL. Any company that uses your code under that GPL license, has entered a contract with you that allows users of their software to sue them for GPL violations. However, you can also simultaneously offer a non-GPL, proprietary license for that library to paying customers. Those paying customers would not be part of any GPL contract, they would instead have whatever contract they signed with you when buying the proprietary license. The users of that paying customer would have no grounds to sue that paying customer, because that paying customer never agreed to the GPL contract. (OFC if you use other people's code in your library under a GPL license, then you don't have the legal right to offer a propriety license for that code.)
Consider carefully your example, you've contributed to some GPLv2 body of code. Now you ship that code on your device (making available corresponding source code, but not decryption keys). You are not the only copyright holder, this is a collective effort.
Can you avoid the GPL'ed requirements? No. More critically, this allows new requirements to be asserted (under the GPL) that GPLv2 developers might not have considered something they want to enforce (hardware unlock) but users and activists might want to try and enforce.
All good for the users. Glad to hear this is welcomed by developers and those hiring open source contributors. This is still going to be a change from past GPLv2 experience I think for some / many.
edit: if not, maybe you're trying to say that the people who control the license to the project (and have the contributors' agreements to prove it) can't relicense the code however they want (and however is allowed in the agreement) for whoever they want? Because I don't think that's true.
There are different views on the GPLv2. Most of the contributors / developers on GPLv2 just wanted you to share back your code, so most litigation in this space followed that approach. Even there, it was at times pretty cooperative.
The SFC has a MUCH more aggressive view. They have views around DRM / unlocks on hardware and much more that are very user rights focused, but pose complications to developers. In the past though, they really couldn't pursue these claims because despite lots of contributors to projects, many didn't support their approach and so wouldn't work with them to make copyright claims. To give you a sense of some developers views:
"lawyering has become a nasty festering disease, and the SFC [Software Freedom Conservancy] and Bradley Kuhn has been the Typhoid Mary spreading the disease." - Linus Torvalds (key player in the Linux kernel development).
They and the EFF created Affero GPLv3 and GPLv3 to try and solve for some of the issues they felt were important, but developers didn't really get on board.
The key is SFC can now sue folks making and distributing devices with OSS software WITHOUT any permission or input from the creators and copyright holders of the software, that is what is so huge. And this is particularly important because many authors and copyright holders have different views on these issues compared to the SFC.
We went though this once with GPLv3 already. SAMBA for example moved pretty aggressively to GPLv3. I'm not sure apple kept contributing to it or updating it in their software once that happened.
Sure, its easier to get standing to enforce GPL, but the legal requirements of abiding by GPL have not changed due to this decision. The only change is that GPL violations that were hard to pursue are now easier and people that have been violating GPL will be more likely to face consequences.
If this that GPL projects have lower adoption rates then that is because fewer people who would have violated the license will bow avoid it. Similarly, if fewer projects areadr available as under GPL, it is because they are adopting licenses that have fewer restrictions.
I don't personally see the advantage of having a more difficult to enforce license. Either your license accurately matches your intent in a court of law and should be enforced rigorously, or it doesn't match your intent and you should use a different license.
Selectively enforced licenses seems like selectively enforced laws: ripe for corruption.