I outline four things I’d like to see in GPLv4. For those that don’t know what the GPL is, here’s a Wikipedia article on it. This article is mostly aimed at this generally familiar with the GNU General Public License.
GPLv3 hasn’t taken off the way the FSF had hoped. While I’m a supporter of the GPLv2, like many, I find GPLv3 to be too vague, too complex, and too overbearing. This is despite that I believe most of the GPLv3’s changes are good, solid improvements.
So, I’m starting the conversation on tangible changes to include in GPLv4. I believe that it’s time for a new version. Unlike GPLv3, I think GPLv4 should focus on protecting and encouraging companies to contribute to GPL code. It’s time to have a version of the GPL that embraces freely-open-sourced-software, while also reaching out to encourage companies contribute too.
It’s time for the GPL to welcome companies to contribute, rather than define the rules that they must contribute within.
So, here are four main things I’d like to see in GPLv4. (Full disclosure: I run a tech startup that builds Android devices and tech – so use of the editorial ‘we’ will get a little thick later on).
Better protections against accidental actions
Companies should not have their entire source code threatened in the event of a mistake, or worse, sabotage. In 2011, an HP TouchPad was sold to a consumer containing a debug test build of Android. Despite building their own webOS, HP used Android to test the Qualcomm chipsets that underpinned the device.
HP was actually threatened with litigation, before asking Qualcomm to give them permission to release the source code for the test build. That build of Android was never intended to be used by the public, and HP should not have felt compelled to open source it.
All that HP did wrong, was a production line employee forgot to reflash the device with HP’s webOS firmware before putting it into a box. That alone should not trigger a mandatory source code disclosure. It simply shocks the conscience. Companies are people – thousands of people in many cases. At some point, an individual will make a mistake. When they do, the entire company’s intellectual property should not be permanently threatened, with no cure. With GPLv3, sadly, this is a valid concern.
Furthermore, it’s even possible that a derelict HP employee intentionally undertook the actions above, to force a source code disclosure. This is unlikely, but can’t be definitively ruled out. And, it underscores the need for reform in this regard to the GPL. There are zero defined protections for when an employee actively disobeys the directions of its employer, and could potentially trigger a mandatory code disclosure. Only local governments may provide limited protections in this regard.
The simple fact of the matter is, if companies fear the GPL, they’ll avoid contributing to open source software. A GPLv4 should have a cure period, allowing companies to admit mistakes, pull/takedown/reformulate products, but not have their company threatened over good-faith efforts to the open source community.
Define “dynamically linked” better, or scrap the term altogether
Most of what is in GPLv3 are important, clear improvements. However, they’re clouded and subsumed by one big unknown – the dynamic link.
Apple, for example, was forced to stop contributing to the open-source project Samba, and instead had to build its own SMB file server, based on the final GPLv2 code release of Samba. Now, Samba is deprived of code contributions that Apple would otherwise have been happy to share. Why? Because Apple is afraid that someone might argue that Samba is “dynamically linked” to OS X, and in turn (per rules of GPLv3), force Apple to share the entire source code of OS X.
This is stupid. But some argue even typing a file name into a terminal window constitutes a dynamic link. Others argue you must use some shared library, where code natively interacts in an intended manner, such as a dylib or .dll file to create this scenario.
Vagaries of this degree should not be in the GPL. It should be scrapped, or at least, replaced with clear and concise definitions that most industry experts in engineering (and product management) can explain in human terms.
Allow for walled gardens to have an open space
The “anti-tivoization” terms do not properly define what native code execution implies on a device. Can a device create a sandbox that allows an app to access all the system’s APIs, but not interact with apps in the walled garden that normally interact with one-another? For example, could you allow Foo.app to run in a sandbox (unsigned), but not allow it to communicate with Chromium.app (which is signed)? If Chromium.app and Email.app can normally communicate with one-another because they are signed, is it enough that Foo.app can run unsigned in its own unsigned sandbox?
Again, GPLv3 has vagaries in what the anti-tivoization rules really are. And, in turn, that’s why you see a lot of companies forbidding GPLv3 code, and in turn, contributions to GPLv3 projects.
In this regard, we’d like to see GPLv4 declare that so long as unsigned code can run cleanly (with all available system APIs), that signed apps can run privately. This would allow for protected content (DRM video, for example) to display securely, while allowing it to interact with other secure apps and services – and still allow for unsigned code. Some may argue (including myself) that GPLv3 already permits this, but again, we’d like to see it clearly defined.
Give courts power to rule on GPL matters fairly
The GPL doesn’t really define what happens when a GPL dispute arises. It creates for messy legal situations, often times either benefitting a large corporation – or scaring large corporations away from contributing altogether.
Similar to our first point (protections against accidental actions), the GPL should declare that companies have the right to be bold with the GPL, and if a court rules a violation was not willful or malicious, have the right to cure their actions by phasing out or withdrawing from GPL participation in a project.
For example, in the dynamically linked scenario, if Apple genuinely felt that Samba didn’t dynamically link to OS X, and the court found that it did, Apple should have the right to withdraw Samba code from OS X, without having to open source the code it was dynamically linked to.
This would allow for companies to engage in signing statements, explain openly how their closed-source code works with the open-source project, and contribute to the GPLv4 project unless and until someone makes a valid objection.
In sum, we’d like to see a cure period extended not just to accidental and/or malicious actions, but also to vagaries in the GPL when they arise. This will give companies the ability to better contribute to GPL projects, without fear of a potential disaster down the road. Additionally, code contributions prior to the raising of an objection, should be exempted from forced source code disclosures.
Using the Samba example, if nobody complained about Samba’s OS X interactions for years, and then someone did years down the road, Apple would be required to resolve that dispute and then only face source code disclosures for contributions after losing in a court. This prevents someone from finding a dynamic link that was unintentional, dating years back, and then demanding Apple open-source newer code too as a derivative work. This term would work hand-in-hand with the cure period proposal, ensuring companies would be protected from non-willful mistakes.
Why it’s time
In conclusion, I’d like to outline why I think it’s time for GPLv4 a bit more clearly. Having run a startup for awhile now, we’re about to announce and start shipping products in large quantities.
I’ve turned my back, and turned my back on my wallet, on companies that wanted me to continue to work on technology confined to walled gardens. Companies I’ve loved. Companies I’ve admired. Companies I bought at $4 per share and watched rise to $400 per share. That said, my morals are unphased over these decades in computing.
No one company should have the power to decide what apps you can, or can’t, use on your personal computer… regardless of if it’s in your pocket, on your eye, or on your desktop. Revolutions like Android have shown how open software, and moral, ethical computing, will win the day. That’s a major reason why Android (and in turn, Linux) is now the most popular operating system in the world.
In my time raising Console, Inc, I’ve already seen both the Apple/Samba and HP/Android situations play out. A situation like that could hit a startup, and it could kill a startup. A good startup. A good startup that is engineering and pushing the envelope with open source software. A startup like my own.
I hope this really does jump start the conversation on GPLv4. If it doesn’t, I’ll be tossing this article back on people when it does get started in earnest.
This article has been updated from its original (2014) version with some trivial branding and typo matters corrected.
Thats funny. Protect companies because they “accidentally” use GPL based software.
They had not spend money developing a flash tool, didn’t gave enough information to ALL the ones involved with the webOS project, and the license that needs to be more flexible?
Don’t get me wrong, but you missed the entire point about corporations sucking all they want from Free Software, and blaming that GPL is “too strict”. Develop your own tools or use a BSD-Licensed one damn it!
And continuing your article, you are just defending better integration with DRM technology(that is just a fancy way to say “digital shackles”) with Free Software APIs.
This licence is not about Opensource only. Is about respecting user’s freedoms.
To be clear, I did not say that GPLv3 is too strict. There are terms like dynamic-linking that are vague, open to interpretation, and open to dispute. And I am not seeking more flexibility when I say that companies deserve protections from criminal acts or individual negligence.
If you want companies to avoid GPL like the plague, ignore these topics. It’s precisely why companies like Apple have become so reclusive to GPL projects. The good news, is that it can be solved without infringing on the user freedoms of the GPL.
The GPL is hard to understand for developers. While the leagalize is what is really binding, it needs to be clear for a developer too. If we don’t know what we can and cannot do, how can we use the license?
I avoid the GPLv3 at first because of the misunderstandings and fear in the community about it. Until I happened into a discussion with RMS on a GNU mailing list, I didn’t understand the point of some parts of the license. It’s not as bad as it first seemed.
Your point is completely valid that any future license should be more clear, but at the same time I disagree with your idea for an accident clause. Companies could claim that when they get caught and that violates the spirit of the license. I say this as a BSD license fan too.
For me, the GPLv3 isn’t that bad but the AGPL is. For similar reasons, it seems to apply over a network. If you write a webapp does it apply the AGPL to your browser? It’s a very confusing license. What constitutes a client?
This is a confusing response. Are you for companies like Apple infringing on user freedoms or against? They were not forced to fork Samba, they made a choice. The other choice was to release their software source code under the same license. Nobody held a gun to their head. It was a business decision to infringe on user freedoms that THEY made. Don’t blame the GPL for Apply not willing to comply with the GPL.
Apple stated (rather publicly too) that they were not willing to use GPLv3, because of ambiguity, not an unwillingness to comply.
Apple was more than willing to share Samba’s source with all GPLv3 terms – so long as they were protected from being compelled to share all of Mac OS X’s source code.
Since Apple’s lawyers felt this was a valid concern, and since nobody at FSF could address it – due to the very ambiguities that I point to in-depth here, Apple could no longer contribute. Samba has suffered as a result.
This is also important to the errors-and-omissions protections that I have proposed. Apple has a legitimate claim to Samba being separate from Mac OS X, under the GPLv3. They deserve some protections to make that case in court, and if they lose, to simply cut Samba from Mac OS X – and not be compelled to bankrupt their company giving away all their trade secrets.
I am not blaming the GPL for Apple “not willing to comply with the GPL” – they (and I) have raised real-world issues with ambiguities that have not been addressed since GPLv3’s passage – and continue to be a real, tangible problem for the entire FOSS community.
A fourth version of the GPL that clarifies and addresses these concerns, in a manner that does not void the protections of the GPL, is the best next step in my opinion.