Akka Ratchets The Rights Away

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.
  • Used a Contributor Agreement despite also using a license entirely suitable for use without one.
  • Change of CEO recently saw the departure of a respected open source leader who had been at the helm during the community-building years.
  • The web site does not mention open source as a customer benefit.
  • The typical 10-year cycle of the rights-ratchet model from open source to proprietary was nearly up.

Those familiar with the rights-ratchet model will undoubtedly have been preparing for the switch. Anyone else may be surprised by it – this time.

Are bug bounty programs good for Open Source?

Seems obvious doesn’t it? They have to be a good thing surely? They are paying people to work on Open Source software – isn’t that increasing the sustainability of open source?

Stag Beetle emerging from elder blossom
Stag beetle emerging from elder blossom

Except the money isn’t going to open-source development; it’s going to a cottage industry of hacking that will likely sell the defects to the highest bidder. Even if the highest bidder is part of a white-hat bug bounty program the community that owns the code may well not have members who can fix the problem readily. Even if the community has got commercial contributors they may not have the income necessary to fix all these bugs found by people who are not buying their product.

Even assuming they want to (screenshot):

Bugs and Knowing

It’s good to have bug reports and know about defects, but there can be down sides. If the defects are exploitable vulnerabilities – CVEs – the reports are kept on a private security list until fixed to avoid informing black-hats. But in projects that can’t fix the defects fast enough they may well end up being disclosed before there is a resolution.

They also show up on CVE databases and become a cause for support calls and demands for resolution from volunteer community members, increasingly so as automatic scanning tools spread. Some of the bugs are rejected by the developers who own the software because in some cases being a bug or a feature is truthfully a matter of opinion, resulting in “will not fix” false positives.

A case can be made for bug bounty programs run for a company seeking low-cost penetration testing to be handled by their professional development team for a commercial product. It can also be made for an administration seeking community testing of public systems, like the Swiss government. But community-focussed programs like the European Commission’s Open Source bug bounty are well-meaning but surely miss their mark, creating work for communities and their commercial backers without generating donations or revenues to pay for bug resolution.

Who Can We Fund?

Specifically to that example, there’s nothing in the EU program that actually leads to any maintainers being paid, which is because that’s “software procurement” and has stringent rules. There’s a 20% uplift for bug reports who propose fixes for their bugs, but the on-ramp for maintainers of the targeted code is usually substantial and a 20% premium is unlikely to be enough to incent someone to come on board as a maintainer.

The EU has built outbound funding programs for Open Source at NL Net and NGI, but they are all earmarked for “the next big thing”, not for the boring job of keeping Open Source maintained. Edgy new features have indeed been paid for by them, but they have no regard for funding bug-bounty burdens. One fix would be to associate an earmarked grant with a matched bug bounty award so the maintainer could go claim it, giving a concrete incentive to invest the time.

Ideally, the grant to the reporter would be at least partly tied to the bug getting fixed as well. But even if the community has members able and willing to take on bounties, haggling with one or multiple unknown parties over acceptance of a solution after the investment has been made is huge risk for small rewards for implementors.

Conclusion

In the sense they reflect a growing realisation by software consumers that strip-mining Open Source is not sustainable, bug bounties are definitely welcome. But they are not the solution to creating sustainability. Open Source in the supply chain is not mainly or even largely about security. Rather, it has the same profile as Open Source elsewhere – a collaborative matter where beneficiaries share the sunk costs in proportion to the benefits gained.

Bug bounties prioritise the non-contributor’s worldview – the quality of the strip-mined commodity – and neglect the true community view – pooled innovation and shared costs. They are a good first step, but need to be rapidly followed by enlightened self-interest expressed by funding and enabling of the maintainers rather than just rewarding their users.

The Future Of Innovation Has Patent-Free Standards

It may come as a surprise to find that some supposedly “open“ standards – including those ratified by standards development organisations (SDOs) like ISO, CEN and ETSI – can’t be implemented without going cap-in-hand to the world’s largest companies to buy a licence. As I explained for OSI, it’s the result of a legacy approach to innovation from the days when it was only really about hardware.

As with any legal loophole, simply existing meant it was exploited and became the norm, even if it was initially temporary (“like income tax”). Once exploitation of a legal loophole becomes competitive, it becomes its own justification for the existence of the regulations (“look at the economic value of this segment”) and they become near impossible to remove – even when the original justification has ceased to need preferential protection.

So today we see a swathe of rich consumer electronics and telecoms companies, addicted to the revenue they get from licensing the patents (SEPs) they have embedded in “open” standards*, lobbying hard to ensure their value to the economy is recognised. They have much to lose from the loss of their special status, so invest much to protect it and to glorify it.

On the other hand, software companies have less to gain by the reformation of this anachronism – to the extent they have flirted with SEPs, maybe even a little to lose. Meanwhile, the new world of Open Source powered innovation lacks rich lobbyists due to its diffusion, and is accustomed to working round the obscenity of valuable standards being taxed by patent cartels. While the freedoms of Open Source mitigate to a degree, this means interoperability and interchangeability are being sacrificed on the altar of SEP protection.

It is not an ideological outlook that makes thoughtful Open Source advocates oppose patents in standards. It’s primarily pragmatic. Requiring a patent license to implement a standard implies that those implementing it must engage in private negotiation to get a license to proceed. That’s super-toxic to Open Source, whose mainspring is code owners giving advance, un-negotiated, equal permission to enjoy the software in any way – use, improve, share, monetise – all protected by a rights license reviewed and approved by OSI. So most projects avoid or work around SEP-encumbered standards and the ones that don’t are industry-specific.

OSI thus takes the position that standards destined to be implemented as Open Source must come with all the rights waived (and has done so for 15+ years). For some, that is already true; for others it is being actively resisted. If you want the crop of innovation you have to get the growing conditions right, and this new crop has different needs to the old hardware world and its long horizons. The future of innovation is open innovation, implemented as Open Source. Using anachronistic patent-centric metrics and regulations will chill that future. How about we don’t do that?


*Reusable Footnote: The word “open” is overloaded here.

(An edited version of this article appeared in the OpenUK survey report 2022)

AI Code Is Like Public Domain Code

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.

Spitfire in Guildhall Square, Southampton (ironically with no space for a co-pilot)
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.

(Thanks to the Patreon backers who made this post possible)

An End To API Gaslighting?

The Supreme Court decision in Oracle vs Google ends a decade-long nightmare for open source developers.

Sunlight or gaslight?*

The decision of the US Supreme Court (SCOTUS) to reverse the erroneous conclusion of the US Federal Circuit appeals court (CAFC) that Google’s use of the Java SE API in Android was a copyright infringement comes as a great relief to open source programmers everywhere. Software developers have always assumed that merely including a function prototype in their code does not require copyright permission as it’s just a fact about the implementation.

Continue reading

What Did Sun’s OSPO Do?

Started in 1999 and established as an official corporate function in 2005, Sun’s Open Source Program Office (OSPO) was among the first in the industry and maybe the first to use the name.

As I’ve discussed in earlier posts, corporations are the vehicle for the collective expression of many individuals. However, to the outside world they are a monolith, and are expected to be consistent as well as predictable in their actions.  With the many varied, implicit expectations and explicit obligations that different open source projects have, transforming a company’s reputation into that of a good actor in open source is a complex task.  It’s also a necessary one if you expect other actors to invest their time and work in your project, or to give you influence in steering a project together.

Continue reading

Accommodating Open Source In Standards Processes

Holders of zero-tolerance positions on both sides of the divide need to realise that accommodating open source productively inside standards bodies is both viable and happening now.

A fine balance

You’ll recall that open source and open standards are orthogonal concepts where even the words they share (like “open”) are defined differently. That doesn’t mean they are mutually exclusive, nor that they are bad together – they can be cultivated well in the same garden. There is great value from accommodating the two orthogonal concepts so that neither is invalidated by non-mandatory elements of the other. When they combine, great value is unleashed.

Continue reading

Software Freedom For Business Value

Software freedom is important to as an idea, but it also creates all the value of open source for business and should be jealously guarded by OSPOs.

In talking about open source, I and others routinely use the expression “software freedom” to refer to the set of rights upon which the open source phenomenon is based. It arises as a synonym for “free software”, an unfortunately ambiguous term that leads people hearing it for the first time to conclude all the primary attributes of open source software relate to money — price, cost-of-ownership, license fee and so on.

“Software freedom” puts the focus in the right place — on the essential liberties required to benefit from the software. One problem with this alternative term is we are becoming accustomed to hearing discussions of “freedom” be limited to activist or political contexts, and consequently regard the term “software freedom” with caution. But a focus on software freedom isn’t just for the revolutionaries.

Continue reading

Permission Beyond Licensing

Is that single-company-controlled project actually open source in the sense of delivering software freedoms to you or just about delivering prospective customers to its host company? Here are 7 tests.

I frequently sum up the nature of open source licensing as granting permission in advance to developers or users to use, improve and share the software for any purpose. But the “Permission In Advance” lens has uses beyond just the rights to copyrights and patents granted in an OSI-approved license. 

In my consulting engagements, I use a “thinking tool” to help clients work through their proposals for new open source community activities. Evaluating a project’s licensing, patent, and community management strategy — both to join it and to host it — should begin with the question: “How confident are community members that they have permission in advance to do whatever they need to succeed?” The more reasons for confidence, the larger the community.

Here are some of the questions community members will be asking, perhaps silently, about single-company open source projects and their own agency as a member of the community:

Continue reading

OSPOs As Community Advocates

Is your Open Source Program Office just part of your corporate defences, or is it the community’s advocate inside your company as well?

Supplies?

As we considered before, corporations are not a person, but are rather a vehicle for the collective expression of the vision of many individuals, showing the outworking of the processes and systems they devise to embody their vision. So the work of an Open Source Program Office (OSPO) needs to address social change within the company and address community needs outside as well as compliance or other corporate self-protection.

Continue reading