A Plea for Fairness for Non-profit Developers of Open Source Software

ISC and NLnet Labs today sent a joint letter to the European Parliament committee working on the EU Cyber Resilience Act.¹ What follows is the letter, and some additional explanatory text provided to the committee.²

April 19, 2023 Amsterdam, Washington DC

To: ITRE’s (shadow)rapporteurs on the Cyber Resilience Act

A plea for fairness for non-profit developers of open source software

Dear Members of the European Parliament,

We appreciate and applaud the goals of policy makers in both Europe and the United States to focus greater attention on the relationship between the software supply chain and cybersecurity. Our purpose today is to highlight an issue of ongoing concern to many of us who develop open source software without a profit motive: how to apportion the proposed new regulatory and liability burdens among the various economic actors engaging in software distribution in a manner that is both fair and equitable. We write to you as two non-profit developers and maintainers of some of the most well-known and widely adopted open source internet infrastructure software, each without shareholders and recognized as charities in respectively the Netherlands and the US.

Parties involved in this complex content-based ecosystem, which is unlike anything else in industrial history, must be treated fairly - and be seen to be treated fairly - by policy makers. Without a fair allocation of burden, policy makers risk destroying the very open development and distribution system that enabled the creation and operation of the Internet they now seek to protect. Fairness demands that “Responsibility must be placed on the stakeholders most capable of taking action to prevent bad outcomes, not [..] on the open-source developer of a component that is integrated into a commercial product.” This quote, from the US Cyber Security Strategy, is fully consistent with the NLF and the Blue Guide. In contrast, the CRA moves away from the nuanced multifactor discussion of charitable activities in the Blue Guide and places the burden unconditionally on non-profit developers like us, merely because we seek to recover maintenance and development costs by providing charged-for technical support or consultancy services to businesses that implement or operate our software.

We ask you not to undermine this funding model that has allowed us to distribute secure and stable open source internet infrastructure software for decades without the intent to make a profit and to consider the following amendment and justification.

Respectfully,
Internet Systems Consortium, Inc.
Stichting NLnet Labs

Cyber Resilience Act and Product Liability Directive: an open plea for fairness by ISC and NLnet Labs

(non-profit developers of open source internet infrastructure software)

New Legislative Framework (NLF) of the European Union
The New Legislative Framework normally imposes responsibilities on those who “make a product available” on the market. The Blue Guide clarifies that, “A product is made available on the market when supplied for distribution, consumption or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge.”³ The Blue Guide goes on to tell us, “Commercial activity is understood as providing goods in a business related context."⁴ We conclude that Europe, like the United States, wants to impose responsibility on those who are best placed to carry the burden - those who supply products in a business related context.

Non-profit distribution of open source internet infrastructure software should not be viewed as a “commercial activity” in a “business related context”⁵ The Blue Guide recognises that determining the existence or nonexistence of a “commercial activity” can be complicated in the case of non-profit organisations.⁶ It gives a non-exhaustive list of factors to consider when determining whether a non-profit organisation is distributing a product “in the course of a commercial activity”: (i) regularity of supply; (ii) characteristics of the product; and (iii) intentions of the supplier. Going through these in turn, we note the following.

Regularity of supply.
For multiple decades our organisations have been developing and giving away open source DNS software for free. Regularity of supply is the hallmark of a healthy open source project and is to be encouraged.

Characteristics of the product.
Our software is not intended for consumer use. Our software is adopted, installed, configured, and managed overwhelmingly by sophisticated entities such as internet service providers and others who manage complex networks and incorporated by third parties into their commercial, for-profit, product and service offerings.

Intentions of the supplier.
Our organisations were established for the purpose of empowering others to grow and operate the internet. We build a series of tools - tools adopted and used by sophisticated technology experts - to maintain the Internet.

The text of CRA appears to deviate from the Blue Guide creating significant uncertainty about scope of application.

Although we set out our observations above using the multiple factors provided by the Blue Book explaining why we believe our organisations and similarly situated entities should not be treated as supplying software as part of a “commercial activity” in a “business related context,” the text of the proposed laws under discussion seems to drag us away from that analysis.

The amendment to Recital 10 of the CRA recently proposed in the rapporteur’s draft report of March 31st would leave the text as follows:

(10) In order not to hamper innovation or research, only free and open-source software supplied in the course of a commercial activity should be covered by this Regulation. In the context of software, a commercial activity might be characterized not only by charging a price for a product, but also by charging a price for technical support services… (emphasis added)

We appreciate that this language helps to emphasise existing Blue Guide commentary that a “commercial activity” can include circumstances where a product is given away for free.⁷ Unfortunately, this language also suggests (rather strongly) that this is the end of the analysis. It seems to say that “charging a price for technical support services” alone is determinative.

This is the point that concerns us.⁸

Developing software that will be given away for free still requires funding.
Writing secure and stable software requires professional, timely, and recurring engineering effort and oversight. History teaches that this cannot be accomplished long-term by the efforts of volunteers alone, no matter how talented. This, in turn, means that somebody must pay for the effort. By definition, open source software is not sold - it is given to the world for free. Similarly, maintenance is not sold - it is given away to the world for free. The challenge becomes how to secure financing without breaking the benefits of the open source model. Grant seeking activity alone is not sufficiently predictable. Those who provide grants are typically more interested in funding new features and less interested in funding routine maintenance activity that is critical to promote security and stability. Offering affiliated technical support or consultancy services to implementer/operators to cover the cost of continued maintenance and development has become a popular model to secure recurring revenue to cover the cost of continued maintenance and development.

Our Plea For Fairness
Please do not jeopardise this non-profit funding model that has allowed us to fulfil our charitable mission of distributing secure and stable open source internet infrastructure software these many decades.