Open source is not meant to be free of charge. It is just meant to have no internal ledger (everyone contributor bears their own costs and derives their own benefit from the greater work) – but since open source has to make no distinction (internal=external) that also resolves as no external ledger, by accident. (Aside: This by the way is a major issue legislatively, where the “internal” development of open source code ends up regulated much more than that of proprietary code.)

But that's unfortunately led to a worldview that wants to treat all engagement with open source as philanthropic, denying those engaging in supporting roles any means of compensation and guilt-tripping anyone who needs support into silence. I call that “dictating other people's sacrifices” – it happens all over the charity sector too, where people seem to think skilled workers should work for peanuts “because it's a charity”. I try to make sure that all the places where I have a say pay as many people as they can all they should, and then leave it up to those people how to spend (or donate) the resulting income.

Tags, Links and Mentions

• #OpenSource #Community #Sustaining #PayTheMaintainers #FreeSoftware #SoftwareFreedom #Governance #Notes

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

The European Commission recently published a public draft of the standards request associated with the Cyber Resilience Act (CRA). Anyone who wants to comment on it has until May 16, after which comments will be considered and a final request to the European Standards Organisations (ESOs) will be issued. This process is all governed by regulation 2012/1025, of which more in a future post.

This development is important for every entity that will have duties under the CRA (“manufacturers” and “software stewards”). Conformance with the harmonised standards that emerge from this process will allow manufacturers to CE-mark their software on the presumption it complies with the requirements of the CRA, without taking further steps.

For those who depend on incorporating or creating open source software, there is an encouraging new development found here. For the first time in a European standards request, there is an express requirement to respect the needs of open source developers and users. Recital 10 tells each standards organisation that

“where relevant, particular account should be given to the needs of the free and open source software community”

and that is made concrete in Article 2 which specifies:

The work programme shall also include the actions to be undertaken to ensure effective participation of relevant stakeholders, such as small and medium enterprises and civil society organisations, including specifically the open source community where relevant

and that requirement is made concrete in article 3 which requires proof that effective participation has been facilitated. The community is going to have to step up to help the ESOs satisfy these requirements – or have corporates masquerading as community do it instead.

Notes, Tags and Mentions

• #Policy #CRA #OpenSource #FreeSoftware #SoftwareFreedom

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

The definition of “open source” in the most recent version (article 2(48)) of the Cyber Resilience Act (CRA) goes beyond the Open Source Definition (OSD) managed by OSI. It says:

“Free and open-source software is understood as software the source code of which is openly shared and the license of which provides for all rights to make it freely accessible, usable, modifiable and redistributable.”

The addition of “openly shared” was a considered and intentional addition by the co-legislators – they even checked with community members that it did not cause unintended effects before adding it. While open source communities all “openly share” the source code of their projects, the same is not true of some companies, especially those with “open core” business models.

For historical reasons, it is not a requirement either of the OSD or of the FSF's Free Software Definition (FSD) and the most popular open source licenses do not require it. Notably, the GPL does not insist that source code be made public – only that those receiving the binaries must be able to request the corresponding source code and enjoy it however they wish (including making it public).

For most open source projects and their uses, the CRA's extra requirement will make no difference. But it complicates matters for companies that either restrict source availability to paying customers (such as Red Hat) or make little distinction between available and non-available source (such as ForgeRock) or withhold source to certain premium elements.

A similar construct^{1} is used in the AI Act (recital 102) and I anticipate this trend will continue through other future legislation. Personally I welcome this additional impetus to openness.

Notes, Tags and Mentions

• #CRA, #OpenSource, #Policy, #Europe, #FreeSoftware, #SoftwareFreedom
• {1} The mention in the AI Act has a different character to that in the CRA. In the AI Act it is more narrative, restricted to a recital and is a subset of attributes of the license. In this form it actually refers to virtually no OSI-approved licenses. In the CRA the wording part of the formal definition in an Article, so much more impactful, and adds an additional requirement over the basic requirements of licensing.

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

What has powered open source to become part of 75% of all software and drive nearly €100 bn of GDP in Europe? Reuse, yes. But that was always possible. Collaboration, definitely. But repositories existed for years before open source was coined in 1998. The software freedom philosophy. Absolutely, but that went 15 years without triggering a software revolution. I suggest it's something less measurable and observable — developer confidence — and that the effects involved are stochastic, not deterministic.

No Confidence

As a result of the automatic global ownership of copyright by the authors of any software, no developer — even if supplied with the source code — may make much use of software written by others without being granted permission to do so. There are basically two ways such permission is granted:

• With a 1:1 contract — usually connected to a license fee or ongoing subscription fee but sometimes formed through agreement with the terms of an End User License Agreement (EULA).
• Through the terms of a general license available to the public at large, contingent on acceptance of the conditions in the license but without executing a contract.

Gaining the confidence to proceed in both cases involves studying the terms, understanding what is and is not permitted and understanding what duties must be performed. For most people, gaining confidence to proceed involves obtaining legal advice, which usually means paying for it. For most of us, that means not reaching a position of confidence.

It's Software Freedom All The Way Down

In large part this is addressed by the philosophy of Software Freedom that evolved from Richard Stallman's early experiences. Software Freedom ensures all uses are expressly permitted (with conditions) by having the author(s) grant permission in advance, with the goal of every recipient of the software being self-sovereign. But the philosophy needs a vehicle to become real.

The software license does that. It leverages the need for a copyright license to create an opportunity to deliver all the rights necessary to “enjoy” the software. By enjoy, I mean the rights to use, improve, share and monetise the software, for any purpose, in any place and in any combination, subset or superset. All necessary rights are assumed to be granted unless stated otherwise.

Uncertain About Freedoms

These freedoms definitely provided a foundation for developers to have confidence they had code they could reuse and collaborate over. But the freedoms were only definitely available under the GPL family of licenses – any others needed an opinion from a gatekeeper who worked opaquely. Using only the GPL family was controversial because of the “copyleft” provisions that seemed to some who had been working in the open for decades to force adherence to an ideology with which they did not identify. So people tried their hand at writing other licenses.

In the late 1990s, more and more products were claiming they were using “free software licenses” but there was no way to be sure they objectively delivered software freedom in your own circumstances, at least until the FSF had commented. Even then legal advice would likely be necessary given the monochrome view FSF tended to have. Worse, the “free software” term was being used casually in support of proprietary models accompanied by custom licenses, so the risks were not imaginary.

Grey Areas

What drove creation of new licenses? Every software project and its anticipated usage has its own context, so even the simplest licenses work in different ways for different people. In particular, some users prefer to take software that has been freely offered to them and use it as the basis of software that is offered restrictively to others, perhaps even avoiding attributing their work to its original authors. But away from that extreme, there are many dimensions to consider and, wise or not, there's a license embodying each of them.

Having many licenses may be a source of choice and diversity, but in every case the key question a developer will ask is “can I use that code?” There are licenses that are highly burdensome to comply with, licenses that use copyleft in a way that is incompatible with the way it's used by other licenses, licenses that lack clear patent grants, and many more. Which licenses deliver software freedom under conditions you can accept?

Not everyone has a lawyer (or easy access to a software freedom guru), and of course even people with a lawyer may not really want to ask every single time they see a new license. So, lacking confidence to proceed, developers avoid new licenses. This lack of developer confidence had a chilling effect and held back a wave of open collaborative development which in turn meant software freedom remained the privilege of an elite rather than a benefit for all.

Stochastic Confidence

Open source succeeded not by making things black-and-white but by clearing enough shades of grey to make things feel OK to the majority. It created stochastic confidence – enough confidence they had the freedom to reuse, collaborate and innovate for a critical mass of developers to gather and do so.

Collaborative evaluation against the Open Source Definition (OSD) was sufficient to give many people confidence there was a low probability of further permission-seeking. Crystalised and recorded by OSI, it created sufficient developer confidence to re-use code downstream from elsewhere. Yes, there were still uncertainties – but not enough to poison the network effect. OSI thus catalysed a network effect of collaboration and reuse by creating an open mechanism to create stochastic confidence in developer communities.

Compatible licensing also provides a vehicle for shared rights upstream. The level playing field of open licensing makes it possible to contribute improvements – making open source lower maintenance while remaining highly maintained collectively. Communities operating under a “license in = license out” basis see a free flow of code.

So the answer to why open source worked ultimately is a brew of factors that is hard to acknowledge for those with direct-causal minds – consensus on licenses, confidence about IPR grants, upstream contribution enablement and more. None of these factors alone is sufficient to trigger the network effect of open source development, reuse and collaboration. Neither is any factor alone sufficient to stop the effect if removed. Rather, it is a matter of moving members of the fourth sector from a fog of uncertainty to a point where they are confident to reuse, improve, contribute and innovate. Open source works via a stochastic effect that is hard to quantify yet undeniable.

Antipatterns

So what will break open source? Nothing so crude as a ban. Anything that lowers the stochastic confidence level below the point where the network effect works in a given context will do the job. Some causes of lower confidence/needing further permission:

• The need to license patents, especially in relation to standards
• DRM
• Geographical embargoes
• Contributor License Agreements (even a DCO will reduce adoption)
• Uncertainty in the interpretation of a license
• Licenses that have not been OSI approved
• Restrictions in the license. Conditions may be problematic if you don't want to comply with them but that's not a restriction. All OSI-approved licenses are permissive. All have conditions. None require negotiation – that would be a restriction.
• Compliance certification requirements
• Developer certification requirements

This is not to say all these things are certain to prevent an open source network effect triggering. Rather, each thing reduces the average level of confidence of part of the potential adoption community. This is the reality overlooked by corporations following their usual path to optimising short-term gains.

Notes, Tags and Mentions

• From a keynote address at FOSS-North, Gothenburg, April 2023
• According to Oxford Languages, stochastic means “having a random probability distribution or pattern that may be analysed statistically but may not be predicted precisely.”
• #OpenSource #FOSS #FLOSS #FreeSoftware #SoftwareFreedom #Causality
• The photo is my own, taken in the Everglades and actually a colour photo not B&W!

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.

The choices we make are relevant to others only to the extent that they abridge the choices of other software users. It is never OK to bully someone over their software freedom point-of-compromise.

• For choices which only affect the individual, it is polite and appropriate to start with the assumption the individual has mindfully considered their choices and to leave unspoken the differences one observes between those and one's own choices or a Utopian ideal. We can only truly know our own selfhood.
• For choices made by another person which affect oneself, it may be appropriate to politely ask why those choices are being made in such a way as to impose a loss of choice on oneself if they truly do. But in most cases where the abridgment is minor or avoidable, it is better to lead by example. It is rarely appropriate to hector and never OK to bully.
• For choices made by an organisation, it can be more appropriate to ask the organisation to justify their choices when they impose a loss of liberty on others. Even so, one should start out assuming they have considered the issue and reached a balanced compromise according to their mission and means.
• For organisations that choose to enjoy the benefits of software freedom themselves and then choose to withhold those freedoms from their customers, it is much more appropriate to question their decision and perhaps weight that decision heavily against any purchasing choices. If they pretend they are somehow open source while using licenses not generally accepted as delivering software freedom to all, public criticism is likely to be warranted – that's an abridgment too far.

What else is “an abridgment too far”? When I can only choose systems that leave me with no practical software freedoms, and when the person or organisation forcing that choice either has not considered the issue or in doing so has needlessly ignored software freedom as a key factor. In just these cases it may be reasonable to politely inquire why and then to go further if the response is unreasonable.

Tags, Notes and Mentions

• #OpenSource #FreeSoftware #SoftwareFreedom #FOSS #FLOSS #Terminology #Definition
• The image is my own, of a gull slipstreaming the air around the Manly Fast Ferry in Sydney harbour

Follow @webmink@the.webm.ink to be informed of new posts. To discuss this post please reply from Mastodon etc. (search for the URL) & include @webmink@meshed.cloud as WriteFreely still doesn't display replies. More.