Years ago, while the GPLv3 was still being drafted, I got a chance to attend a presentation by Richard Stallman. He did his whole routine as St IGNUcius, and then at the end said he would be answering questions in a separate room off to the side. While the more causal nerds shuffled out of the presentation room, I went along with a small group of free software aficionados that followed our patron saint into the inner sanctum.
When my turn came to address the free software maestro, I asked what advantages the GPLv3 would have to a lowly hacker like myself? I was familiar with the clause about “Tivoization“, the idea that any device running GPLv3 code from the manufacturer should allow the user to be able to install their own software on it, but this didn’t seem like the kind of thing most individuals would ever need to worry about. Was there something in the new version of the GPL that would make it worth adopting in personal or hobby projects?
Interestingly, a few years after this a GPLv2 program of mine was picked up by a manufacturer and included in one of their products (never underestimate yourself, folks). So the Tivoization clause was actually something that did apply to me in the end, but that’s not the point of this story.
Mr. Stallman responded that he believed the biggest improvement GPLv3 made over v2 for the hobbyist programmer was the idea of “forgiveness” in terms of licensing compliance. Rather than take a hard line approach like the existing version of the GPL, the new version would have grace periods for license compliance. In this way, legitimate mistakes or misunderstandings of the requirements of the GPL could be resolved more easily.
So when I read the recent announcement from Red Hat that said they would be honoring the grace period for GPLv2 projects, I was immediately interested. Will the rest of the community follow Red Hat’s lead? Will this change anyone’s mind when deciding between the GPL v2 and v3? Is this even a good idea? Join me below as I walk through these questions.
Defining Forgiveness
The title of the Red Hat announcement is “Providing a Fair Chance to Correct Mistakes”, which is basically the perfect way to summarize the grace period added to the GPLv3. But for our purposes, let’s take a look at the full text, taken from the “Termination” clause of the GPLv3:
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
OK, so what does that mean?
Basically, the first paragraph is saying that if you distribute a GPLv3 covered work and violate any of the license terms, you forfeit your license and therefore the right to distribute the work. Under the GPLv2, this would have been the end of the road. You broke the license, now deal with it.
But the next paragraphs give you a way back. It says that if you stop violating the license, and the upstream license holder (generally speaking, the original developer) doesn’t want to push the issue, your rights are reinstated. Further, if you fix your license violation in a timely manner (30 days) after the original developer notifies you, and assuming you aren’t a repeat offender, then you’re also in the clear.
It’s important to note that this clause protects you whether or not the license holder contacts you about the violation. If you realize on your own that you messed up and fix it, you’re covered. If they do contact you, you just need to fix the issue within a reasonable amount of time.
GPL: TL;DR
This may not seem like that big of a deal at first. After all, how hard is it to follow the terms of the license, right? Well, if we were talking about something simple like the 3-Clause BSD license, then no problem. But the GPL is a considerably more wordy license than others, and also asks more of the user.
Did you include a full copy of the license with the program? Does each source code file in the program contain a header that says it’s licensed under the GPL? Did you make sure all of the files modified from the upstream version contained dated comments that highlight the changes you made? If you’re distributing only a binary, did you make sure the source is hosted somewhere that the user can reasonably find it?
These are just a handful of the requirements contained in the ~2,500 word GPLv2. It’s easy to see how somebody who is not well versed in the license could easily skip some of the more esoteric requirements, especially in the click-and-fork era of GitHub. Any one of these infractions could (at least in theory) lead to forfeiture of your rights as granted by the license.
But with the clauses added to the GPLv3, these problems can be solved with a simple email or Tweet. Notify the developer who made a mistake, give them 30 days to fix it, and the problem goes away. It’s a much friendlier way of handling licensing mistakes, made possible in part by the ease of communication we now enjoy; a situation which could hardly be imagined 30 years ago when the GPLv2 was being written.
Will Everyone Get Onboard?
The new mechanisms for handling licensing issues introduced in the GPLv3 are a benefit for developers and take some of the stress out of using the GPL, and retroactively honoring them for older versions of the GPL is no doubt a great thing for the community. But will it stick?
Google, IBM, and Facebook have announced they will join Red Hat in honoring the grace period for GPLv2 covered works, and even Linux kernel developers are adopting a similar approach, but that still leaves a whole lot of companies and developers who aren’t obligated to do anything outside of what the license says. With luck, more and more companies will adopt this attitude towards supporting the GPLv2, and in time perhaps even individual developers will; but surely not all of them.
That said, the situation becomes murky when you have certain subsets of the community following the spirit of the law, and others following the letter of the law. Allowing a few heavy hitters in the industry to essentially add terms to an existing license (even if they have the best of intentions) could be seen as a slippery slope.
In the end, if you like the clauses added in the latest version of the GPL, then you should probably just use the latest version of the GPL, rather than relying on industry to pick and chose which parts they will or won’t honor. But if you can’t, or won’t, then at least there’s a chance you’ll get a pass; depending on who you deal with.
Sounds like the difference between “grace” given informally, vs grace given in a formal manner. As the original copyright holder one does have some leeway.
“I was familiar with the clause about “Tivoization“, the idea that any device running GPLv3 code from the manufacturer should allow the user to be able to install their own software on it, but this didn’t seem like the kind of thing most individuals would ever need to worry about. ”
There’s also the “web” loophole and let’s not get into patents.
Patents is covered in GPLv3. The “web” loophole is covered in AGPL.
In the end the license terms mean almost nothing in the absence of enforcement. And enforcement isn’t at all necessary when an infringer is a good-faith actor willing to do the right thing.
Grace
Note that the FSF’s motivation has always been to bring infringers into compliance, for our common benefit, not to extract money from the infrigers.
There have been actual cases of people (mis-)using the GPLV2 to extract money from infringers (including tricking them into signing contracts to then extract more money from them in a scheme which can only be called copyright trolling.
One well-known case is Patrick McHardy:
https://lwn.net/Articles/694890/
https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering
https://lwn.net/Articles/731941/
Needless to say, this discredits the whole free software movement.
The GPLV3, with its grace clauses, makes those shenanigans more difficult. The Linux kernel (in which the above drama unfolded), alas, is V2 only
He can’t discredit the whole movement, as there are people who agree with him.
Certainly no one person can speak for a whole movement!
Or we can just all use the MIT licence and get on with the fun part – writing code.
BSD, MIT or any CC. GPL and RMS are incredibly damaging to open source.
> GPL and RMS are incredibly damaging to open source.
[citation needed]
On the contrary, I think “open source”, as you call it wouldn’t even exist without the GPL and GNU.
As an illustration (I could cite much more cases, mind you), take Linux. GCC (with all the goodies like assembler, linker, libc & friends), the GNU fileutils and textutils, most of the user space (X11, which is MIT but is compiled with… you guessed it) were all in place and waiting when a student from Finnland started hacking at an operating system kernel which became… Linux.
All other viable C compilers were either too tiny at that time or had been sucked into proprietary operations.
This is just a little example.
I’m convinced that we *need* a diversity of free licenses which do their best to coexist peacefully. I’m also convinced that copyleft licenses take a key position in keeping the free/open ecosystem healthy (although I don’t think they need to be the only ones, by far).
Retransmitting Microsoft’s (and Apple’s) favorite FUD (as you are doing) doesn’t help but them.
Well said.
What you say reinforces my view. GPL and all its problems are far too synonymous with open source.
The BSDs are a much better example than Linux.
Reality trumps theory, every single time.
BSD is wonderful in theory, just like socialism or communism or trickle-down economy or any other utopia is.
In practice, things like commercial closed-source derivatives lead to a lot of enhancements and fixes being stuck in proprietary projects, with quite a few developers eventually switching to those proprietary projects (as paid work, because everyone has to earn a living somehow).
The end result is that the openly developed part remains a seed pool, growing many separate projects, with little to no feedback from the proprietary projects back to the original seed pool. Evolutionarily, it is a dead end.
You can see this in the FreeBSD and OpenBSD projects especially well. There is not that much innovation there, just good engineering by a dedicated core developer group. Other popular projects using similar licenses, like the Apache server (which, by the way, won over its proprietary derivatives, out of sheer engineering robustness, rather than innovation), seem to have similar characteristics.
(There are a large number of GPL projects with similar characteristics, however: GNU m4, make, and so on. I do suspect that these projects would not be harmed by being licensed under BSD or similar licenses.)
However, when we look at projects with a lot of innovation (as in experimentation, number of features added, or amount of code replaced as a function of time), they tend to be licensed under the GPL. I have no proof that this is because of the license — correlation not being causation –, but I do know a lot of developers who choose GPL, explicitly, because they want to be able to include enhancements developed in derivatives.
This has nothing to do with feeling “ownership” of the code. I personally publish a LOT of example snippets as CC0 (although I usually don’t bother specifying the license unless someone asks), but for larger projects, definitely prefer GPL3. (There are certain libraries I’m developing that I intend to release using either a CC or a BSD-like license, but they implement a specific format, and there is not much “evolutionary” potential in them; although they definitely would benefit from better engineering and multiple developer viewpoints to make them better/more robust.)
The choice of GPL on my part, and many of my developer colleagues agree, is based on the desire of maintaining that “evolutionary potential” for the project. Most BSD proponents believe that having closed-source derivatives is not harmful to the original project at all, but I and many others disagree: the “evolutionary potential”, the possibility of reintegrating new insights and features and solutions developed in the derivatives, is extremely valuable, and lost if the derivatives are closed-source.
Finally, the number of e.g. active Linux kernel developers being paid for their work by various companies, compared to e.g. OpenBSD, OpenSSH, or any other project licensed under the BSD license, is itself a stark reminder of reality. With GPL, these companies realize they do not benefit from trying to close the source (and having these capable developers work only on the in-house derivatives). With BSD, it is normal and non-controversial to poach developers off from open projects into in-house proprietary closed-source derivative development.
Christ, it’s easier to just bootleg Windows.
You’re an ignorant
No yaw!
Actually, some of the CC licenses are more restrictive than the GPL, so I think you’re confused. Companies would gladly take the GPL over Creative Common Attribution-NonCommercial-NoDerivs, for example.
BSD or MIT has the function of corporate welfare. It’s a gift to a really big company, often made by an individual, and the big company can treat the individual as their unpaid employee. There are practical business reasons to use BSD or MIT, when you want everyone including big companies to use something over all other goals. For example when you are putting out a reference implementation to use a web service that you provide. But without a good business reason like that, for individuals to just put all of their work under BSD or MIT is somewhat self-defeating. Work that I have put under GPL has been expanded tremendously by the contributions of companies. The fact that big companies have to comply with the license is annoying to rich folks who would rather we give them gifts. But every little girl wants a pony.
“For example when you are putting out a reference implementation to use a web service that you provide. ”
Or trying to propagate a standard as fast and wide as one can. e.g. network stack, etc.
CC is bad for code, as it’s not intended for code at all.
BSD or MIT gives the code the most freedom.
GPL gives the end user the most freedom. (And with end user I mean the user of the software, not the software engineer)
Depending on your look on the world, both can be damaging. As you look from different perspectives.
CC is pretty bad for everything (except CC0).
Eg for images – for most projects attributions are at best a hassle and unsightly, It’s easier to go to a stock site and buy images.
CC demands very prominent attribution, which just won’t work for most projects. Give it away free (CC0), or sell it.
Creative Commons works wonderfully in environments like podcasts and internet radio, i.e. formats where attribution not only isn’t intrusive but is even something that the end consumer often wants. It is intended for magazine/variety show type uses, not code or components.
Only license I ever use voluntarily is the MIT license.
The GPL is to cohesive and just a bad manifesto.
MIT is simple. Do what you want with the code. No bullshit.
If you actually wanted to just write code and not worry about the license details and the license camps and all that you’d be using the Apache 2 license, as then all the different camps can all make use of your code and you can Just Code or whatever.
You’re not advocating for getting on with writing code, you’re advocating for Team MIT License.
On November 27, Red Hat, IBM, Google, and Facebook announced that they would give infringers of their GPL software up to a 30-day hold-off period during which an accused infringer could cure a GPL violation after one was brought to their attention by the copyright holder, and a 60 day “statute of limitations” on an already-cured infringement when the copyright holder has never notified the infringer of the violation. In both cases, there would be no penalty: no damages, no fees, probably no lawsuit; for the infringer who promptly cures their infringement. I’ll discuss this in a question-and-answer style:
Q: Does this change any court case involving the GPL that is presently in progress? A: No. Red Hat, IBM, Google, and Facebook are not known to be involved in any recent cases of enforcing their copyrights on any software under the GPL license. Red Hat once suggested that it could enforce the GPL against patent aggressors, but I am not aware of any cases in which they have done so.
Q: Does this change the way that GPL license on Linux or any Open Source program will be enforced? A: That’s unlikely. It is not in the interest of those four companies to become involved in enforcement of the GPL license in the future. Thus, their promise to allow an infringer to cure their infringement within certain time limits is irrelevant. Red Hat and IBM would rather sell Linux systems than make their customers afraid by bringing lawsuits. Google and Facebook have bigger fish to fry.
Q: Does anyone else have to provide the same time limits? A: No. The companies involved in the announcement are not the entities that bring GPL enforcement lawsuits. There are thousands of copyright holders in the Linux kernel who could theoretically bring a lawsuit, and perhaps one hundred thousand authors of GPL-licensed software other than Linux (but which might be included as part of a typical Linux system). None of those parties are compelled by today’s announcement. But in general those parties have been voluntarily waiting much longer for infringements to be cured without penalties.
Q: Does their announcement comply with the Principles of Community-Oriented GPL Enforcement drafted by the Software Freedom Conservancy? A: Sort of. It’s obviously inspired by them and by a previous announcement by the kernel team which is also inspired by SFC’s principles but doesn’t mention them. The Open Source developer community in general doesn’t just wait 30 days for an infringer to cure their infringement without any penalties. Historically, they’ve waited much longer and the community principles do not specify any particular duration. The infringements of some of my compliance customers would have been impossible to resolve in just 30 days. Some cases have been settled quietly after more than a year in progress, without any cost, or perhaps only a reasonable compliance auditing fee. One of my customers, a Fortune 100 company, was asked to pay $5000 in auditing fees in resolution of a GPL infringement in a Billion dollar product line. Current infringers may be asked for more simply because these cases are expensive to pursue, but in general the community prioritizes compliance over income and does not ask for huge damages as a company in the proprietary software industry would.
Q: Why was today’s announcement made? A: The companies are concerned by one person, Patrick McHardy. I have no personal knowledge of this, but attorney Heather Meeker has documented it. It is said that he has brought about 50 copyright infringement claims regarding the Linux kernel, with intent to collect income rather than simply obtain compliance with the GPL license. Pretty much everyone in the Open Source community and the companies involved all object to this behavior. Me too. But as far as I can tell, it’s McHardy’s legal right to bring such claims regarding the copyrights which he owns, even if it doesn’t fit Community Principles which nobody is actually compelled to follow. The big companies and community members (and I) wish to discourage McHardy and other parties who might wish to become “copyright trolls” in a similar style and exact damages out of unintentional infringers of GPL-liccensed and other software.
Q: Did the Linux Kernel Team make a similar announcement to that of the four companies? A: Yes. Here’s what they had to say. It is probable that in the future the kernel team will stop accepting contributions from people who don’t sign on to the policies at that link. They have presently excluded Mr. McHardy from the kernel team. But it’s important to note that there is lots of existing work in the kernel by copyright holders who are not required to comply with those principles, and the copyright holders all of the GPL software other than the kernel (a larger body of software than the kernel by far) are not required to comply with those principles.
Q: Is it true that the principles the four companies announced today are taken from the GPL 3 license, but they are applying them to GPL 2? A: Yes. If your software is under GPL 3, the same waiting periods that the four companies have promised are required. Thus, it is ironic that when originally presented with the opportunity to apply the GPL 3 to Linux, Linus Torvalds and the Kernel team were quite hostile about it, while the kernel team’s recent announcement attributes the principles they have adopted to the text in GPL 3. Perhaps they’ve learned something since those hostile moments.
Q: I have more questions. A: Send them to bruce at perens dot com.
The version of this comment with links is at https://perens.com/2017/11/28/understanding-the-red-hat-ibm-google-facebook-gpl-enforcement-announcement/
GPL v.WHATEVER… China doesn’t care!
Not true! A number of non-compliant Chinese firms have been brought in once they were informed of their responsibilities.
Not everybody in China cares, not everybody in the US cares.
Naomi Wu cares, that’s why she created the sino:bit educational platform! (with engineering donated by elecrow) The purpose is to teach IP principles by giving access to open source tools to young people. Once they start in the industry, they’ve already developed their thinking about how they copy code; so it is vitally important to start before then, to teach them IP hygiene as children. And of course it is much easier to give kids something and teach them why you gave it to them, and get them to value that, then to just tell them “no” and expect them to care.
https://github.com/sinobitorg
https://www.elecrow.com/sino-bit-v1-0.html
China does care, and they’re working on it! Thank you Naomi! <3
“While the more causal nerds shuffled out of the presentation room, I went along” – so the writer is non-causal, I take it?
I would go so far as to say that I have graduated to professional nerd at this point, yes.
Which allows you to break causality? :P
It’s a way to make your nerds more effective.
I came to the comment section looking for exactly this. Thank you.
I don’t believe in “opensource” that still has string attached, even if those strings supposedly are designed to coerce the user to release opensource. I keep it simple. If I don’t want it to be opensource, I don’t release it. If I release it, it gets released under MIT.
That’s why that stuff is called Free Software instead of Open Source.
You claim to be against coercing the user, but MIT does have some important strings attached.
If you want to avoid coercion, might I suggest looking into the Apache 2 license? Then projects that are MIT licensed can still copy from you, and so can everybody else, including GPL and proprietary projects.
I find it odd that one of the major “license teams” in the open source world wants to claim that they are uniquely more open than everybody else, even when their license isn’t the most compatible, or the least encumbered by conditions.
Is Red Hat going to give that ‘grace period’ to others or to itself (and partners)? You know, so they can play foul of open source for commercial reasons. Because there seems to be a slow steady trend towards more commercialism in the Linux world too.
Cynical minds want to know.
GPL is useless without strict enforcement by the copyright holders. on multiple occasions I’ve tried (unsuccessfully because I’m not a copyright holder on the Linux kernel) to get companies to release source code for their modified versions of the Linux kernel in devices that I’ve bought. if the copyright holders aren’t willing to enforce the license, it doesn’t help end users at all.
Take for example TripWire; if they had had accident forgiveness they would have had a better chance to avoid releasing an open source version, but as it was they had to release it to avoid a product recall!
But I already liked GPL 2 better than 3.
(reposting because it apparently didn’t go through the first time)
GPL is f*cking useless without strict enforcement by the copyright holders. on multiple occasions I’ve tried (unsuccessfully because I’m not a copyright holder on the Linux kernel) to get companies to release source code for their modified versions of the Linux kernel in devices that I’ve bought. if the copyright holders aren’t willing to enforce the license, it doesn’t help end users at all.
Praise be to Saint Ignucius!
The effect on hobbyists is a bit over-stated in my opinion, because it is unlikely that an enforcement action could do much to them. For example, if they didn’t repeat the license information in every file, that is easily fixed. And since they do have a license, you can’t easily go after them for copyright violation. It isn’t enough to show a technical violation, you have to show a meaningful violation that harms you; without having been harmed, you don’t even have standing to sue! And even then as long as they add the license blocks to the files you pointed out in the suit, now the issue is moot and you have no case.
May emacs and gcc be with you, always!
Look whats not happening with MOSH due to the licensing…..
The license can actually deter usage….
I always thought it was hilarious how Linux users rant about GPL and LGPL and AGPL and security, but gladly use kernels littered with binary blobs with full privileges in their system that have never been analyzed.. Mostly for 3D acceleration for a game and art market that doesn’t really exist for OSS..