Regulatory language cannot be the same for all software

In reviewing the language and concepts being used in the various draft bills and directives circulating in Brussels at present, it is clear that the experts crafting the language are using their understanding of proprietary software to build the protections they clearly intend for Open Source. This may be the cause of the problems we continue to see as the instruments iterate, especially in the absence of direct consultation.

Proprietary software and the company that places it on the market can usefully be seen as the same target for those creating legislation. The software is constructed in secret, under the control of a single party, and the controlling party is responsible for both funding the work and monetizing the result. However, the same cannot be said for Open Source software, which is created openly by a globally-distributed and unaffiliated community whose relationship with the larger work is “volunteer”. Using terminology associated with the worldview of proprietary software in legislation that affects Open Source is at best ambiguous and at worst extends consumer regulation to the domain of research and development.

Open Source software is an artifact arising from the interactions of a community of contributors with no contractual binding between them beyond the Open Source license itself, which disclaims all warranties and has no conduit for funds. If there is an Open Source charity or trade association hosting the community, there will also be only a limited binding to it and probably none that is a funding conduit. Many communities are unincorporated and don’t even have this level of interconnection.

Because of this, those who place the artifact with digital elements on the market must be assumed to have no financial, organizational or indeed morally relevant relationship with any other party involved in the artifact’s origination or use until proven otherwise. There may be links, but it’s best to start from the assumption there will be none because making them is an outside activity with no accommodation in Open Source licensing.

In many cases (sadly) those placing the artifact on the market have no connection at all with the community, not even at the level where it is appropriate to consider members of the community as suppliers. As one community member wrote:

I am not your supplier. So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code.

The software and the community thus need to be considered separately when choosing language that applies regulation affecting Open Source. Some highlights to note:

• The software is made freely available under an OSI-approved license that ensures its consumer may do anything it wishes without needing any relationship with rights holders.

• The members of the community collaborate for many different reasons, and even when those reasons have commercial intent the commercial intents in play are likely to be unrelated both formally and informally.

• Many community members have a moral/ethical basis for their participation which can sometimes take priority over pragmatic convenience.

• Treating the software and the company placing it on the market as interchangeable is unsafe.

• As a consequence, it is unsafe to assume that because two parties are monetizing a piece of Open Source software, that there is a flow of funds or even a relationship between them. Regulation should only apply to the party triggering the clause in the legislation, unlike with proprietary software where it is reasonable to assume a link.

This article first appeared on Webmink in Draft.

Image of Fallen Head by Simon Phipps