The EU's Proposed CRA Law May Have Unintended Consequences for the Python Ecosystem

After reviewing the proposed Cyber Resilience Act and Product Liability Act, the PSF has found issues that put the mission of our organization and the health of the open-source software community at risk. While we support the stated goals of these policies of increasing security and accountability for European software consumers, we are concerned that overly broad policies will unintentionally harm the users they are intended to protect. We feel that it is important to consider the role vendor-neutral nonprofit organizations—especially public software repositories—play in the modern development of software. 

Many modern software companies rely on open-source software from public repositories without notifying the author, and certainly without entering into any kind of commercial or contractual relationship with them. If the proposed law is enforced as currently written, the authors of open-source components might bear legal and financial responsibility for the way their components are applied in someone else’s commercial product. The existing language makes no differentiation between independent authors who have never been paid for the supply of software and corporate tech behemoths selling products in exchange for payments from end-users. We believe that increased liability should be carefully assigned to the entity that has entered into an agreement with the consumer. We join our European open source colleagues at the Eclipse Foundation and NLnet Labs in voicing our concerns over how these policies could affect global open source projects.

Why does the Python Software Foundation care about CRA?

The Python Software Foundation (PSF) is a nonprofit charitable organization that exists to promote, protect, and advance the Python programming language, a cornerstone of the modern technology sector. We are based in the US, but for more than 20 years we have served a global open source community of students, teachers, entrepreneurs, academics, scientists, artists, public sector workers, hobbyists and commercial software developers. The PSF does not sell software, but we provide a public square for developers to download code and talk about code, and we host components that other entities may include in their products. We facilitate technical discussions for the ecosystem generally and support many educational opportunities for the worldwide community of Python developers.

We do many other things in the service of our charitable mission, but there are two activities that could be affected by the CRA:

1) We host and provide the core Python programming language, standard library and interpreter to any who wish to use it free of charge. It may be downloaded from our website, and a version of Python is downloaded over 300 million times per day.

2) We host the Python Packaging Index (PyPI), a vast library of software packages, written by thousands of different entities and individuals, that is made available in a single place where all packages are public and freely available. PyPI is critical infrastructure for the entire ecosystem, and thousands of individuals and enterprises depend on it, downloading 10 billion packages in an average month.

To be absolutely clear, nobody pays us for software, either for the core language or any of the packages that you can download from the repository we maintain. At first glance, that might lead one to believe that there is no money being made with Python or Python packages. In fact the reverse is true: a large number of people who build things with Python, analyze data with Python or create AI models with Python are doing so at a commercial company, academic institution or government agency that pays them to work there, and in fact a not-insignificant share of the profit-generating tech economy relies in some part on Python. For instance, many well known applications including YouTube, Instagram and Spotify are all built using Python code.

Hosting Python and Third-party Python Software in the Open is a Public Good

We host a lot of software that is used in commercial applications and nearly everyone—except the PSF itself—is making a lot of money selling products that use Python code and libraries. We host that software so that it can be examined by anyone for flaws or bugs. We also host that software so that it can be used to teach new coders and the next generation of tech pioneers. Any policy that does not provide clear carve outs for repositories offered for the public good will do irreparable harm to the individual’s accessibility to the power of modern software development.

We’re concerned that some of the current proposed policy language doesn’t make things clear enough for an ecosystem like Python’s. Under the current language, the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products. The risk of huge potential costs would make it impossible in practice for us to continue to provide Python and PyPI to the European public. Certainly, everyone wants security, for consumers to have reasonable assurances, and for the software industry to be accountable to its customers. However, it is critical that those assurances are expected from the correct entity and that the legal burden for any lapse in accountability is levied against the correct entity. Many of the software elements that end up in commercial software or hardware products come from publicly available open source repositories like PyPI where no compensation is given. Open source languages and repositories shouldn’t be thanked for the public services they freely provide with an open-ended risk of ruinously costly legal action. The PSF should not be liable for every application or device that happens to contain some Python code.

Assigning liability to every upstream developer would create less security, not more. Leaving individual and/or under-resourced developers in a legally murky position when contributing to public repositories like the Python Package Index would almost certainly create a chilling effect for them. Only entities who are selling enough software or software/hardware combinations to absorb the ramifications of product liability could continue to operate in the open. The user improvements and shared security benefits of global software collaboration would only be accessible to those developers working on behalf of a few large companies. Growth and innovation would be stifled. The security of languages like Python depends on the continued availability of a neutral, non-commercial entity that can act as a clearinghouse for new software, improvements, and bug fixes that can be shared freely by the entire software community.

Increased Clarity is Needed

Rather than following the code all the way upstream, we would prefer to see policy makers follow the money. Many components are not a product by themselves and it is a mistake to risk any shift of financial burden from the entity that compiles and sells a product to the open source developer that they received a free bit of code from. All coders should be working towards a world of greater security for end-users, but no one developer can imagine all the ways in which an individual open source component will be used and combined with other components for consumer use. Consumer liability and responsibility cannot be assigned until a product is assembled and something is for sale.

In particular, we believe that there are two phrases in the CRA that cast too wide of a net. In Article 16, “A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of the product with digital elements shall be considered a manufacturer for the purposes of this Regulation.” is too broad. Open source is full of people who make a substantial modification to a piece of public code but do not have any contractual or financial relationship with the entity or entities that might eventually use that code in a commercial product. Secondly, in Recital 10, the phrase “…by providing a software platform through which the manufacturer monetises other services.” is not specific enough. Public code repositories and their hosts may offer paid classes or sell tickets to conferences about shared open source code while still having no control over the way commercial entities use that code in their products. Disincentivizing educational activities or curtailing public patches from third parties will not make European software consumers safer.

The existing, publicly available open source ecosystem already provides robust and evolving security mechanisms where we share news about where individual components should be used and more importantly how they shouldn’t be used. When a flaw is discovered in a popular piece of software, we publicize patches and get potential vulnerabilities addressed across hundreds of products and tools. Chilling participation in these processes makes us more vulnerable, not less.

Conclusion

We need it to be crystal clear who is on the hook for both the assurances and the accountability that software consumers deserve. Language that specifically exempts public software repositories that are offered as a public good for the purpose of facilitating collaboration would make things much clearer. We'd also like to see our community, especially the hobbyists, individuals and other under-resourced entities who host packages on free public repositories like PyPI be exempt. We believe these exemptions would help both consumers and the open source ecosystem, as well as the economic actors who depend on it. We hope that policy makers in the European Union will carefully consider complex and vital ecosystems like Python when drafting landmark policies that affect open-source software development.

PSF members and Python users in Europe may wish to write to their MEP voicing their concerns about the proposed CRA law before April 26th, while amendments that will protect public open source repositories are still being considered.

Protecting the Python Trademarks

Who is the Trademarks Working Group?

The Python Software Foundation Trademarks Working Group was created by the PSF Board of Directors to  monitor and authorize (or prohibit) use of trademarks held by the PSF.  The WG—initially dubbed committee—was created in 2008, and has been co-chaired by me since 2010, adding Marc-André Lemburg in 2013.  We've had a variety of other members over the years, with Iqbal Abdullah being a wonderful and helpful member of the WG for the last couple years.

You can write to us any time at on the Trademarks WG mailing list.  If you ever want to use one of our marks, please do write to us.  Even for those uses that are completely non-contentious, we'd rather quickly approve them and have a record in the mailing list archives than just not know about the use (the archive is not public, however, since legal issues, even potential litigation, are sometimes discussed).

We would welcome participation by more Python community members (being a PSF member is not strictly required, just an interest in helping Python maintain its branding).  Helping with the working group is a pretty small time commitment, but as with many volunteer efforts, folks often drift away from such efforts over the course of years.  By all means contact us if you have an interest in trademarks and an hour or two a week to spend helping us in these discussions.

Our Goals

The PSF holds registered trademarks in a large number of jurisdictions—incrementally increasing in number over the years—and "use trademarks" worldwide.  Obviously, legal regimes around intellectual property, and trademarks specifically, vary somewhat around the world; for the most part trademarks serve a similar purpose everywhere though.

We don't want the brand and reputation of Python to be used in a deceptive manner. However, Python being free and open source software (FOSS), and the PSF being devoted to such freedom, the licensing policy adopted by the PSF is very liberal and serves the purpose of promoting the use and knowledge of Python rather than trying to obtain commercial advantage (as many for-profit product marks are used).

Let's go back to what marks the PSF maintains.  The name "Python" is a wordmark that is registered in many places.  Nominative use of the name is always permitted when it is used to describe the Python programming language. In contexts such as books devoted to the language or about associated libraries, tools, etc. we ask publishers to include a small notice in the front matter that mentions the PSF trademark.  We have an official usage policy and a Frequently Asked Questions that detail permitted usage, with the FAQ having more examples and a less formal tone (probably best to start with the FAQ if you have questions).

Similarly, the names "PyCon" and "PyLadies" are also wordmarks of the PSF. The policies around use of PyCon and of PyLadies are each a little bit different from the Python wordmark, since they serve  different purposes.  Essentially, we want to make sure that when those names are used, they maintain an identity and advance the goals for which the marks were created.  The PyLadies wordmark is monitored and authorized by the PyLadies leadership rather than the Trademarks WG, so email to them is the best place to ask questions of them.

Trademarks are Tricky

The trickiest part of what we do on the Working Group is approve use of the "two-snakes" Python logo.  A great many really wonderful Python-related user groups, conferences, software projects, publications, blogs, and other efforts that do a great job of promoting Python, understandably don't understand the arcana of trademark law. In particular, the rules we need to maintain about derived logos can feel obscure and counter-intuitive in the FOSS world.

The key issue is that trademark is not copyright.  For people familiar with copyleft and software freedom, it feels like the right to create derived products should be as little restricted as possible, perhaps not at all. While I endorse that wholeheartedly for copyright, that's not how trademarks work—nor, I believe, how they should work.  Trademark is instead a kind of consumer protection, it's a way of saying that a particular thing is what it purports to be.  In a way, a trademark is like a signature or a seal (whether a physical or a digital version of such); it's a testament to authenticity of a thing.

Apart from my particular philosophical attitudes about trademarks, the laws around them have a specific concept of dilution wherein merely permitting a use that makes a mark less distinct can remove the protection altogether.  Specifically, it means that if the PSF allows groups to make completely well-meaning, and often even beautiful, changes to the shape of the two-snakes logo, we could wind up losing the ability to stop malicious actors from misbranding their non-Python things with the logo.  To be clear, many derived logos are absolutely permissible, and the FAQ discusses what distinguishes permissible and impermissible derivations (and what can be "inspired by but not derived from").

Happily, all the good actors we've dealt with, in my 15 years working on this, have come to understand the concerns of the PSF, and have modified their customized logos in ways that allow us to authorize them.  It's slightly unfortunate that a few others have slipped through simply because the WG never knew they existed until they were already in use, but we've worked with those groups (largely conferences and user groups, sometimes software projects) to fix things going forward.  It's a little bit of politics, a little bit of professionalism, but mostly it's just reaching out to the truly wonderful people who make up our worldwide Python community.

David Mertz (mertz@gnosis.cx)