There’s been a regrettable rise in the number of projects switching to “fauxpensource” proprietary licenses. In the main, this is the inevitable consequence of the rights-ratchet model running its course and reflects the growth of open source ten years or so ago, the model’s typical life-cycle. The rights ratchet model offers open source freedoms in the initial years of a product to secure adoption and market acceptance and then gradually removes their viability from customers as the company seeks to control their ecosystem and increase revenue.
So the license change that LightBend applied to its Akka product to end its open source status was in retrospect more probable than not given the available evidence that they were using a rights-ratchet business model, just like Elastic and other before them.
Signs that together seem a clear warning include:
VC backing includes VCs who have previously advised portfolio companies to ignore the community rather than leaving money on the table.
I’ve repeatedly heard lawyers arguing about whether Open Source licenses and FRAND terms are compatible. But ultimately it doesn’t matter, because the toxin remains whatever the answer – legal compatibility is the wrong lens. When developers come to an Open Source project, they need to find a level playing field, a uniform surface with no traps, a fully illuminated environment with no shadows. Without them, collaboration is compromised.
But the presence of a standard with embedded patents (standard-essential patents or SEPs) under so-called “Fair Reasonable and Non-Discriminatory” (FRAND) terms introduces inequality. Some developers believe they are unaffected, because their usage is purely personal or they are poorly advised. Others are unconcerned because their employer is part of a cross-licensing cartel with the patent holder. But the remainder must each go privately and under NDA to the patent holder(s) and negotiate individual terms to use the patents. They then can’t publicly share the exact arrangements — or possibly even the existence of the arrangement — because of the NDA. Individual terms and secret rights are the opposite of open collaboration and destroy trust.
It’s this inequality that is toxic, not the precise compliance with the legal terms in the Open Source license. Whether great legal minds find the presence of SEPs compatible or incompatible with the license, the inequality of the participants in the community is what makes it avoid SEP-laden standards. That’s why the Open Standards Requirement for Software says any SEPs have to be waived or freely licensed in advance – to restore the level playing field. It’s not because of ideology or an anti-patent agenda or an attempt at market manipulation. The open source network effect underlying the market depends on it.
So learned dissertations about the compatibility of FRAND terms with Open Source licenses may be academically interesting, but they aren’t relevant. All SEPs in standards intended to be implemented as Open Source must be waived or freely pre-licensed, or the standard won’t be implemented by open communities
GitHub’s CoPilot tool may well be revolutionary, according to Bradley Kuhn. An AI trained by reading a massive and unidentified corpus of code, assumed to mostly be open source and licensed for any use to Github under their terms of use, it is able to watch what you are coding in your IDE and make suggestions on how to autocomplete the code – potentially at length. It is a kind of Clippy for code. It has just had the ultimate validation; Amazon copied it.
No room for a co-pilot
Sure, quit Github
While that may seem an unalloyed good to many programmers, there is an outbreak of moral panic surrounding it, as evidenced by the recent call to boycott GitHub because of it. Now, I am all in favour of people using distributed tools instead of centralised ones. Git itself is intended as a distributed tool and in a way it’s offensive for GitHub to have annexed its name to create a centralised and proprietary control point.
I am also keen for everyone as far as they can to exercise self-sufficiency over their computing and control of their personal data, and given Git was written as a response to the final abridgement of that self-sovereignty by the author of an earlier tool that the Linux developers were dependent on, Github is again somewhat offensive. Those would both be fine reasons to encourage people to move on from Github and to escape the social honeypot of carefully crafted network effect funnels that it embodies.
… but not because of Copilot
But Copilot is not a great reason to quit, or at least not for the reasons people insist on articulating. Those reasons seem strong on copyleft maximalism and the homeopathic thinking that assumes because there was GPL vapour in the air everything written at the time is infused. They also seem laced with a residual mistrust of Microsoft.
Copilot is unlikely to be infringing copyright. Certainly not in the USA. Probably not in most other places (although see Brown for more nuance). Even for humans, learning patterns doesn’t infringe copyrights, and quoting minimal or essential fragments rarely rises to the level needed for protection by copyright. Copyrights are not the same as patents, and re-expressing the same idea does not amount to infringement – even if such infringement were possible for a machine. Which it is not, so all these considerations are moot in many jurisdictions.
Copilot is unlikely to be breaching the GPL. That could only happen if copyright was being infringed. Just because the author of a work doesn’t like use of their code by Microsoft’s tool, that doesn’t somehow create an infringement that triggers the license.
Copilot in not morally bankrupt for using open source code for training. The whole point of Open Source Free Software is to give anyone the unconditional right to study the code and learn from it. If that’s a via an automated tool that makes the matter more efficient, it makes no difference.
Making a new thing that does the same as my patented widget is always an infringement of my patent, but making a new thing that does the same as my copyrighted code is not. An unfortunate consequence of the propaganda term “Intellectual Property” is that non-specialists munge all the concepts for all of {Copyright, Patents, Trade Secrets, Trademarks, Database rights} into one big hairball and assume anything matching the hairball triggers some form of infringement of any/all of the concepts. So arguments that mix-and-match IP concepts to imply an infringement are … problematic.
You shouldn’t use it for Open Source though
AI code helpers like Copilot are thus very unlikely to infringe rights per se. But that doesn’t mean code made by them should be welcome in Open Source projects.
To summarise a long article, Reda concludes that the output of an AI like Copilot is best understood as Public Domain. But ironically, that’s the real problem with Copilot for an Open Source developer. Public Domain is not Open Source, and AI-generated code introduces friction that works against the Open Source network effect for just the same reasons. As Brown explains, not every jurisdiction has the same degree of certainty or the same attributes to its conclusion about AI-generated works as seems commonly understood in the USA.
So while you may feel comfortable using AI-generated blocks in your code, what will you write in the pull-request to give others the same confidence? Even Github (and indeed Amazon) are at pains to point out that’s your responsibility, not theirs. Their tool may be a very helpful learning aid, but it’s something of a trap for the responsible Open Source contributor.
There’s a different case to be understood in every jurisdiction both about the code origin and the threshold for copyrightability. While the (many) lawyers I have heard from have largely waved a hand and said the arguments would never stand up in court, the arguable cases create a context where a community can’t rely on AI-generated code without further advice. Just like Public Domain, that added friction makes it non-viable for any community serious about provenance.
The biggest challenges are the ones exerting subtle, systemic steering effects that people don’t take seriously. Github may not be a digital scofflaw, but their tool is a Siren tempting you onto rocks that can ruin communities.
Using open source elsewhere is not relicensing, it’s overlaying a second license.
So you’re considering taking some open source code under a minimal, non-reciprocal OSI-approved license and putting it under a different open source license, hopefully in combination with your original code (or another form of larger project).
Don’t call this “relicensing” – it is not! The original license will continue to apply and you remain responsible for complying with its requirements. Only the copyright holder can change the license. You’re not relicensing – instead you are using the rights the license has given you and applying an additional license to the combination of the earlier work and your work.
All open source licenses are permissive. They give you permission in advance to use the software for any purpose, to improve the software any way you wish and to share the software with whoever you want. They are the opposite of proprietary licenses, which place restrictions on each of these freedoms. Any license with restrictions would not be considered OSD compliant.
All open source licenses include conditions. Some relate to attribution. Some relate to reciprocal licensing. None of them restrict how you can use, improve and share the software, although you must comply with the conditions in order to do so. Some people consider some conditions so onerous they rise to the level of restrictions, but the consensus of the community has been they are wrong.
Today’s licensing games are thus mainly about testing where the accumulated burden of conditions is effectively a restriction – “constructive restriction”. There’s certainly a line where that would become true – for example, where the conditions associated with deploying the software as a cloud service are so hard to comply with that the software is effectively unusable in that field of use.
The OSD doesn’t include much to help with this so it’s contentious every time and sometimes leads to sophistry. This is probably the area where the Open Source Initiative needs to do the most work to modernise the license approval process.
The lesson Elastic’s restrictive relicensing teaches is that those using open source to ratchet a software startup will forsake software freedom eventually if they’re aggregating rights. That’s no reason to believe open source needs updating.
Many of the responses to the decision of Elastic to drop open source licensing for their products and instead use restrictive commercial licensing have involved asking whether they were justified to do so based on market conditions (especially the provision of a service by Amazon Web Services) or diving into the minutiae of what they actually did. Some see it as support for the hypothesis that the very definition of “open source” is out of date. But to do so is to swallow the bait of distracting explanation and overlook the actual value of open source and why Elastic — and the cloud databases before them — no longer care about it.
It’s not enough for you to have the rights you need; your community needs the same rights.
A few people reacted negatively to my article on why Public Domain software is broadly unsuitable for inclusion in a community open source project. Most argued that because public domain gave them the rights they need where they live (mostly the USA), I should not say it was wrong to use it.
Choosing between licenses – even copyleft vs non-reciprocal – is less important than ensuring everyone has equal rights & responsibilities.
I’m often asked which open source licence is best for businesses who want to release a project as open source. Usually behind the question the issue is a desire for corporate control somewhere in the organisation. This tends to flow from a conviction the only way a business can succeed is by keeping some sort of copyright (or patent) control that creates an artificial scarcity. Continue reading →
Open source ensures developers already have permission to innovate and don’t need to ask first.
If you want your code to be open source, it needs an OSI-approved copyright license. Code with no license to the copyright isn’t open source. But project success needs more than just an OSI-approved license — it needs “permission in advance” for every developer and deployer. Continue reading →
Facebook’s BSD+Patent license combo fails not because of the license itself but because it ignores the deeper nature of open source.
In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. They are using the 3-clause BSD license (BSD-3), a widely-used OSI-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant but with equally broad termination rules to frustrate aggressors. Continue reading →
Meshed Insights Ltd 