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.