There is no need to bring up the new Open Source AI Definition v.1.0 to evaluate if the Llama 3 model series and its Llama 3.x community licences convey basic freedoms to their users. We agree with the Free Software Foundation’s recent evaluation that the Llama 3.1 Community Licence agreement fails in spectacular ways at granting basic rights:

• Fails at freedom 0, the freedom to use the model for any purpose
• Fails at the Open Source Definition point 5, discriminates against users
• Fails at the Open Source Definition point 6, restricts fields of endeavour

These restrictions were already clear in the license used by Llama 2. The newer versions of Meta’s Llama community licence impose even more restrictions, like excluding any persons in the European Union from using the model without explanation; and all of the restrictions from the previous licences remain. 

We are disheartened to see a couple of individuals entangling their criticisms of the Open Source AI Definition with Meta’s abuse of the term Open Source referring to Llama. The OSAID did not create any confusion about the proprietary nature of Llama; in fact, Meta’s open washing, and our response to it, predate the OSAID entirely.

These individuals are supporting Meta’s open washing efforts, and sowing fear, uncertainties and doubts within the community.

What you can do about it

At a time when Meta is trying to redefine Open Source for their own benefit and at the expense of our freedom, we call on the whole Open Source community to unite and call out Meta’s open washing.

OSI will continue to fight back against open washing with public statements, events, and educational work with the Open Source and AI communities, lawmakers, and businesses.

Rather than forcing everyone individually to do that, the ESBs are instead sent a list of subjects that need proving and are asked to recommend a set of standards that, if observed, will demonstrate conformity with the law. This greatly simplifies things for everyone and leads to what the lawmakers call a “presumption of conformity.” You could go comply with the law based on your own research, but realistically that’s impossible for almost everyone so you will instead choose to observe the harmonized standards supplied by the ESBs.

This change of purpose for standards is very significant. They have evolved from merely being a vehicle to promote interoperability in a uniform market – an optional tool for private companies that improves their product for their consumers – to being a vehicle to prove legal compliance – a mandatory responsibility for all citizens and thus a public responsibility. This new role creates new challenges as the standards system was not originally designed with legal conformance in mind. Indeed, we are frequently reminded that standardization is a matter for the private sector.

So for example, the three ESBs (ETSI, CENELEC and CEN) all have “IPR rules” that permit the private parties who work within them to embed in the standards steps that are patented by those private companies. This arrangement is permitted by the European law that created the mechanism, Regulation 1025/2012 (in Annex II §4c). All three ESB’s expressly tolerate this behaviour as long as the patents are then licensed to implementers of the standards on “Fair, Reasonable and Non Discriminatory” (FRAND) terms. None of those words is particularly well defined, and the consequence is that to implement the standards that emerge from the ESBs you may well need to retain counsel to understand your patent obligations and enable you to enter into a relationship with Europe’s largest commercial entities to negotiate a license to those patents.

Setting aside the obvious problems this creates for Open Source software (where the need for such relationships broadly inhibits implementation), it is also a highly questionable challenge to our democracy. At the foundation of our fundamental rights is the absolute requirement that first, every citizen may know the law that governs them and secondly every citizen is freely able to comply if they choose. The Public.Resource.Org case shows us this principle also extends to standards that are expressly or effectively necessary for compliance with a given law.

But when these standards are allowed to have patents intentionally embodied within them by private actors for their own profit, citizens find themselves unable to practically conform to the law without specialist support and a necessary private relationship with the patent holders. While some may have considered this to be a tolerable compromise when the goal of standards was merely interoperability, it is clearly an abridgment of fundamental rights to condition compliance with the law on identifying and negotiating a private licensing arrangement for patents, especially those embedded intentionally in standards.

Just as Regulation 1025/2012 will need updating to reflect the court ruling on availability of standards, so too should it be updated to require that harmonized standards will only be accepted from the ESBs if they are supplied on FRAND terms where all restrictions on use are waived by the contributors. Without this change, standards will serve only the benefit of dominant actors and not the public.

To have the chance for powerful Open Source AI systems to exist in any domain, the OSI community has incorporated in the Definition this principle: 

An Open Source AI needs to make available three kinds of components: the software used to create the dataset and run the training, the model parameters and the code to run inference, and finally all the data that can be made available legally.

Recognizing that there are four kinds of “data”, each with its own legal frameworks allowing different freedoms of distribution, we bypass what Stephen O’Grady called the “AI conundrums” and give Open Source AI builders a chance to build freedom-respecting alternatives to pretty much any proprietary AI.

Limiting Open source AI only to systems trainable on freely distributable data would relegate Open Source AI to a niche. One of which is that the amount of freely and legally shareable data is a tiny fraction of what is necessary to train powerful systems. Additionally, it’d be excluding Open Source AI from areas where data cannot be shared, like medical or anything dealing with personal or private data. What remains for “Open Source AI” would be tiny. There are abundant motives to reject this limitation.

The fact is, mixing openly distributable and non-distributable data is very similar to a reality we are very familiar with: Open Source software built with proprietary compilers and system libraries.

Is GNU Emacs Open Source software?

I’m sure you’d answer yes (and some of you will say “well, actually it’s free software”) and we’ll all agree. Below is a rough diagram of Emacs built for the GNOME desktop on a modern Linux distribution. Emacs depends on a few system libraries that GNOME provides with OSI-Approved Licenses. The whole stack is Open Source these days and one can distribute Emacs on a disk with all its dependencies without too much legal trouble. Imagine scientists who want to freeze the whole environment of an experiment they made; they could package all the pieces of a system like this without trouble and distribute it all with their paper. No problem here.

Now let’s go back to an age when Linux systems weren’t ready. When Stallman started writing Emacs, there was no GNOME and no Linux, no gcc and no glibc. He thought very early on that in order to have more freedom, he had to create a wedge to allow Emacs to run on proprietary software.

Emacs on the latest Solaris versions would look something like this: some pieces like X11 and Gstreamer are Open Source. Others, like libc and others aren’t. The hypothetical scientists from before couldn’t really freeze their full scientific environment. All they could say in their paper was: “We used Emacs from this CVS version, built with gcc version X with these makefile; tar.gz attached” and make a list of the operating system’s version and libraries versions they used. That’s because they have the right only to distribute Emacs, X11, some libraries and not the rest of Solaris.

Is Emacs on Solaris Open Source? Of course it is, even though the source code for the system libraries are not available.

One more question, Emacs on Mac OS: it can only be built with a proprietary compiler on proprietary GUI and other proprietary libraries.

Is Emacs on Mac Open Source? Of course it is. Can you fully study Emacs on Mac OS? For Emacs, yes. For the MacOS components, no. There are many programs that run only on MacOS or Windows: for OSI, those are Open Source. Would someone argue that they’re not “really Open Source” because you can’t see “everything?” Some people might but we’ve learned to live with that, adding governance rules in addition to those of the Open Source Definition. Debian for example requires that programs are Open Source and support multiple hardware platforms; the ASF graduates only projects that are Open Source and have a diverse community of contributors. If you only want to use Open Source applications running on Open Source stacks, you can decide that! Just as you can decide that your company will only acquire Open Source software whose copyright is owned by multiple entities. 

These are all additional requirements built on top of the base floor set by the Open Source Definition.

For AI, you can do the same: You can say “I will only use Open Source AI built with open data, because I don’t want to trust anything less than that.” A large organization could say “I will buy only Open Source AI that allows me to audit their full dataset, including unshareable data.” You can do all that. Open Source AI is the floor that you can build on, like the OSD.

Bypassing the conundrums

We’ve looked for a solution for almost three years and this is it: Require all the data that is legally shareable, and for the other data provide all the details. It’s exactly what we’ve been doing for Open Source software: 

You developed a text editor for Mac OS but you can’t share the system libraries? Fine, we’ll fork it: give us all the code you can legally share with an OSI-Approved License and we’ll rip the dependencies and “liberate” it to run on GNU. The editor will be slightly different, like code that runs on some ARM+Linux systems behaves differently on Intel+Windows for the different capabilities of the underlying hardware and OS, but it’s still Open Source.

For Open Source AI it’s a similar dance: You can’t legally give us all the data? Fine, we’ll fork it. For example, you made an AI that recognizes bone cancer in humans but the data can’t be shared. We’ll fork it! Tell us exactly how you built the system, how you trained it, share the code you used, and an anonymized sample of the data you used so we can train on our X-ray images. The system will be slightly different but it’s still Open Source AI.

If we want to have broad availability of powerful alternatives to proprietary AI systems that respect the freedoms of users and deployers, we must recognize conditions that make sense for the domain of AI. These examples of proprietary compilers and system libraries used to build Open Source software prove that there is room for similar conditions when talking about Code, Data and Parameters within the definition of Open Source AI.

We asked Joseph P. De Veaugh-Geiss, a linguist and KDE’s project manager, to provide us with an explanation. If that’s not enough, we have one more argument at the end of this post. 

Why Open Source is not hyphenated

In summary:

• “open source” (no hyphen) is a lexicalized compound noun which is no longer transparent with respect to its meaning (i.e., open source is not just about being source-viewable, but also about defining user freedoms) which can then be further compounded (with for example “open source license”);
• by contrast, “open-source” (with a hyphen) is a compound modifier modifying the head noun (e.g. “intelligence”) with open having a standard dictionary meaning (i.e., “transparent” or “open to or in view of all”).

Open Source as a lexicalized compound noun

“Open source” is a lexicalized compound noun.  Although it originates with the phrase “open source software”, today “open source” is itself a unique lexeme. An example, in Red Hat’s article:

Open source has become a movement and a way of working that reaches beyond software production.

The word open in “open source” does not have the meaning “open” as one would find in the dictionary. Instead, “open source” also entails user freedoms, inasmuch as users of the software for any purpose do not have to negotiate with the rights owners to enjoy (use/improve/share/monetise) the software. That is, it is not only about transparency.

A natural example of this usage, in which the phrase open source license is clearly about more than just licensing transparency:

Because Linux is released under an open source license, which prevents restrictions on the use of the software, anyone can run, study, modify, and redistribute the source code, or even sell copies of their modified code, as long as they do so under the same license.” (from Red Hat website https://www.redhat.com/en/topics/open-source/what-is-open-source)

Note that “open source license” is itself a compound noun phrase made up of the lexicalized compound noun “open source” + the noun “license”; same for “open source movement”, etc.

What is lexicalization?

According to the Lexicon of linguistics (Utrecht University), ‘lexicalization’ is a “phenomenon by which a morphologically complex word starts to behave like an underived word in some respect, which means that at least one feature (semantic, syntactic, or phonological) becomes unpredictable”.

Underived word here means the phrase has a specific, unique meaning not (necessarily) transparent from its component parts. For instance, a “black market” is not a market which is black but rather a specific kind of market: an illegal one. A “blackboard” can be green. In other words, the entire complex phrase can be treated as a single unit of meaning stored in the mental lexicon. The meaning of the phrase is not derived using grammatical rules.

Today, the meaning of open source is unpredictable or semantically intransparent given its usage (at least by a subset of speakers) and meaning, i.e., open source is about user freedoms, not just transparency.

Other examples of lexicalized compound nouns include “yellow journalism”, “purple prose”, “dirty bomb”, “fat chance”, “green card”, “blackbird”, “greenhouse”, “high school”, etc. I tried to think of examples which are composed of adjectives + nouns but with a specific meaning not derivable by the combination of the two. I am sure you can come up with many more!

In some cases, lexicalization results in writing the compound noun phrase together as a single word (‘blackboard’), in other cases not (‘green card’). One can also build larger phrases by combining the lexicalized compound noun with another noun (e.g., black market dealer, green card holder).

Hyphenated open-source is a compound modifier

By contrast, open in “open-source intelligence” is the dictionary meaning of “open”, i.e., “open to or in view of all” or “transparent”. In this case, open-source is a compound modifier/compound adjective with a meaning comparable to “source-viewable”, “source-available”, “source-transparent”.

For compound modifiers, the hyphenation, though not obligatory, is common and can be used to disambiguate.  The presence of a head noun like “intelligence” or “journalism” is obligatory for the compound-modifier use of open-source, unlike in lexicalized compounds.

Examples of other compound modifiers + a head noun: “long-term contract”, “single-word modifier”, “high-volume printer”, etc.

Examples

There are some examples of  the compound-modifier use on Wikipedia where I think the difference between meanings lexicalized compound noun and compound modifier becomes clear:

“Open-source journalism, a close cousin to citizen journalism or participatory journalism, is a term coined in the title of a 1999 article by Andrew Leonard of Salon.com.” (from Wikipedia)

“Open-source intelligence” is intelligence “produced from publicly available information that is collected, exploited, and disseminated in a timely manner to an appropriate audience for the purpose of addressing a specific intelligence requirement” (from Wikipedia)

In these examples open-source is clearly referring to transparent, viewable-to-all sources and not to something like ‘guaranteeing user freedoms’. Moreover, my intuition for these latter examples is that removing the hyphen would change the meaning, however subtle it may be, and the change could make the original sentences incoherent (without implicit internal modification while reading):

•  “open source journalism” would refer to journalism about open source software (in sense I above), not transparent, participatory journalism;
• “open source intelligence” would refer to intelligence about open source software (in sense I above, whatever that would mean!), not intelligence from publicly available information.

The Open Source Initiative says: No hyphen!

If that explanation still doesn’t convince you, we invoke the rules of branding and “pull a Twitter”, who vandalized English with their Who To Follow : we say no hyphen!

Luckily others have already adopted the “no hyphen” camp, like the CNCF style guide. Debate closed.

If you like debates, let’s talk about capitalization: OSI in its guidelines chose to always capitalize Open Source because it is a proper noun with a specific definition. Which camp are you on?

In the light of the EU’s own research showing the huge impact of Open Source on Europe’s economy, the authors of these legislative instruments sought to ensure that the lifecycle of Open Source software was impacted as little as possible. Indeed, at FOSDEM 2023 the authors of the CRA and PLD said as much in their first-of-a-kind main track appearance. But when we all looked at the details, community members found that was not as true as we hoped. As a range of organizations explained, the CRA was likely to be an existential threat to Open Source development, because instead of placing all the compliance requirements of the CRA on companies deploying Open Source software for profit, the obligations as written potentially fell on developers and Open Source foundations.

Reactions To The Final Text

Many OSI Affiliates engaged with the European Commission, European Parliament and European Council during 2023. With the welcome coordination of Open Forum Europe, a group met regularly to keep track of progress explaining the issues. Many of us also committed time and travel to meet in-person. As a result of all this effort from so many people, the final text of the CRA mitigated pretty much all the risks we had identified to individual developers and to Open Source foundations. As the Python Software Foundation said in their update:

…the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

And the Eclipse Foundation wrote:

The revised legislation has vastly improved its exclusion of open source projects, communities, foundations, and their development and package distribution platforms. It also creates a new form of economic actor, the “open source steward,” which acknowledges the role played by foundations and platforms in the open source ecosystem.

As the Apache Software Foundation said:

So, all in all, this is mostly good news for volunteers who run and innovate with open source software. Or, more accurately, much better than most of us could have imagined at the end of last summer.

This time last year OSI recommended that the CRA:

…exclude all activities prior to commercial deployment of the software and … clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.

That recommendation has been accepted and implemented, and the OSI is very grateful to the various experts who took the time to listen.

OSI Observations

While it’s all much better, and while the burden placed on individuals and charities is minimal, there are still challenges ahead. For example, the concerns that the Debian project articulated give cause for thought. With Open Source projects exempted from the requirement to place a CE certification mark on their software, downstream users will need to pay careful attention to their responsibilities under the CRA as well as to their liabilities to consumers under the PLD.

In particular, “digital artisans” using Open Source software at small scale – the main concern of Debian – will need guidance from the European Commission. While the experts we have met have all said that using an Open Source software distribution as part of a commercial activity is unlikely to require CE marking of the distribution itself, the interpretation of the key phrase “making available on the market” will need careful clarification. OSI encourages the Commission to seek expert advice from the Open Source communities as they did last year, and not to rely on outsourced consultants alone in preparing this advice.

FOSDEM 2024

There is also the question of how future engagement by legislators should proceed. The effort made by developers and Open Source foundations in 2023 is not sustainable, and the Commission needs to accommodate the Fourth Sector in future deliberations. To get this started, a group of us who have engaged during 2023 got together to organize a unique set of workshops at FOSDEM 2024 on Sunday February 4. If you want your voice heard, come along to one of the workshops!

Here’s a short list to help the co-legislators understand the engagement from the Open Source community.

• OSI and the experts with whom they engage are not trying to get all of Open Source out of scope as maximalist lobbyists do for other aspects of technology. An exclusion from the regulation for Open Source software per se would open a significant loophole for openwashing. But the development of Open Source software in the open needs to be excluded from scope just as the development of software in private is. Our goal in engaging is just to prevent unintentional breakage while largely embracing the new regulation.
• There is no one way to use Open Source. Many of the policymakers we’ve spoken to think of Open Source components in supply chains under the care of foundations like the Eclipse Foundation that are used essentially as-is. But the freedoms of Open Source are also used for stack building, consumer tools, enabling research, hobbyist tinkering, as the basis for European small businesses like XWiki, Open-Xchange, Abilian, and more. All these many other uses exist and are broken differently by the CRA. Software is primarily a cultural artifact and that aspect must be prioritized.
• There is no single Open Source business model. People make money from Open Source (by charging for it, running it as a service and supporting it) and with Open Source (by simplifying their businesses and reducing costs); they shape markets via Open Source by enabling adjacent businesses, commoditising competitors without then monetising their customers, and more – there are a significant number of business models made possible by software freedom. So any attempt to identify commerciality is sure to be model-specific and consequently have unintended consequences for other models.
• Even larger foundations like Linux Foundation do not actually employ the sort of staff who ensure code compliance – Open Source is conceptually disjoint from proprietary software. To comply with the CRA – if they find themselves in-scope – they will need them to hire a whole new operating unit. To them, the burden of compliance is not a cost of development funded by revenue as it would be for a manufactured physical good where staffing exists and just needs adapting.

As we did in January, OSI still recommends the Cyber Resilience Act should exclude all activities prior to commercial deployment of software and clearly ensure that responsibility for CE marks does not rest with any actor who is not a direct commercial beneficiary of deployment.

“Open Source” means software under a license with specific characteristics, defined by the Open Source Definition (OSD). Among other requirements, for a license to be Open Source, it may not discriminate against persons or groups or fields of endeavor (OSD points 5 and 6). Meta’s license for the LLaMa models and code does not meet this standard; specifically, it puts restrictions on commercial use for some users (paragraph 2) and also restricts the use of the model and software for certain purposes (the Acceptable Use Policy). 

Why Open Source matters

An Open Source license ensures that developers and users are able to decide for themselves how and where to use the technology without the need to engage with another party; they have sovereignty over the technology they use. Open Source is premised on the understanding that everyone gets to share no matter who you are. The commercial limitation in paragraph 2 of LLAMA COMMUNITY LICENSE AGREEMENT is contrary to that promise in the OSD. 

OSI does not question Meta’s desire to limit the use of Llama for competitive purposes, but doing so takes the license out of the category of “Open Source.”  

The OSD does not allow restrictions on field of use because you can’t know beforehand what can happen in the future, good or bad. That’s what allows the Linux kernel to become popular in medical devices as well as airplanes and rockets. 

But the Meta policy prohibits use in several areas that might be highly beneficial to society, such as regulated/controlled substances and use for critical infrastructure. Even something that sounds as simple as “you must follow the law” is problematic in practice.  What if the law in different places is inconsistent? What if the law is unjust?

Avoiding adding more confusion

The license for the Llama LLM is very plainly not an “Open Source” license. Meta is making some aspect of its large language model available to some, but not to everyone, and not for any purpose. OSI realizes how important it is to come to a shared understanding of what open means for AI systems. These are new human artifacts, much like software was a new creation of human intellect in the 70s. We’re running a series of events to craft a common definition of “open” in the AI context and we welcome submissions of ideas.

Below is the text of the letter we sent.

June 16, 2023
Katherine K. Vidal
Under Secretary of Commerce for Intellectual Property
and Director of the United States Patent and Trademark Office
United States Patent and Trademark Office
600 Dulany Street
Alexandria, VA 22314-5796

Dear Director Vidal,

The Open Source Initiative (OSI) is a California 501(c)(3) public charity advocating for and enabling the benefits of open source (community developed and maintained) software in the interests of every citizen. It does not advocate on behalf of any for-profit entity or any political group.

We very much appreciate that the USPTO has provided the opportunity for input on this important matter in advance of the formal rulemaking process. OSI is writing in particular to provide information for your consideration regarding the use of third-party entities to challenge patents.

The oversight of each open source project is usually in the hands of an unincorporated association of individual contributors, or a dedicated public charity (like OSI’s 80+ Affiliate members). Many of the leaders in these communities are entrepreneurs leading small businesses. Open source projects use OSI-approved licenses, which openly convey all rights necessary to use, improve, share and otherwise enjoy the software without any necessary relationship with its rights holders. As such, no open source project depends on patents and communities rarely tolerate royalty-due elements, preferring to design without any encumbered parts.

Open source projects and their maintainers are uniquely vulnerable to attack by hostile parties such as patent trolls (sometimes called “non-practicing entities”) and companies rent-seeking over so-called standard-essential patents. The projects and their non-profit fiduciary hosts are not of a scale to be able to manage the usual defenses of large corporations, while the individuals themselves may seem worthwhile targets for avaricious litigators. When a project faces a patent attack, it is thus frequently defended by others as a matter of civic duty.

The rule changes that the Patent and Trademark Office propose would greatly limit the ability of open source projects to be defended by these third parties. This would both chill the innovation and progress arising from open source software – which contributes billions to GDP – as well as embolden malicious litigators seeking reward where they have no claim simply because their victim is unable to defend themselves.

OSI consequently encourages the USPTO to reconsider these rule changes and avoid the harm they would cause open source software.

Your sincerely,

Stefano Maffulli
Executive Director
Open Source Initiative

Open Source Initiative is a 501(c)(3) corporation (EIN:  91-2037395).

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

But reciprocal patent licensing is very common in the software industry generally and Open Source in particular – it’s part of the terms of the Apache License for example – so the accusation seemed far more likely to be projection by the SEP-dependent legacy industries of Europe. One useful insight into the whispers to which DG COMP responded can be seen in the extra information AOM has added to its legal page in response to the matter. The questions they address have such obvious and innocuous answers that only express sophistry could have been behind such questions, given the sophistication of the actors involved.

This is all crucially important to Open Source software, and not just as an endorsement of reciprocal terms. While there are edge cases, generally Open Source projects avoid standards which embed royalty-due patents, not primarily because of the royalties but because of the need to submit to the control implied by privately negotiating terms with the patent holders – an obviously anti-competitive aspect for any market entrant, about which Europeans complain.

It only takes one patent aggressor to rob everyone of viable Open Source video, so it seems entirely reasonable to scrupulously maintain hygiene by requiring any beneficiary of AV1 to commit to waiving royalties (and thus their negotiation). AOM is creating standards expressly intended to allow implementation by Open Source projects, so their terms are both rational and reasonable … unless you want to keep Open Source out of your cozy market.

The clouds have not all dispersed. AOM’s licensing is unfortunately based on a non-OSI-approved license (for excellent reasons but still an issue). Hopefully this will become more and more unfashionable as Open Source expands its reach. Also, significantly, there are hostile patent pools which, unfathomably and without evidence that their mountain of claims are actually essential, assert that the AV1 standards infringe patents in the pools.

But this is good progress and underlines that the “reciprocal” mechanisms so common in Open Source licenses are generally pro-competitive.  Perhaps the Commission will now move on to ask why such an obviously anti-competitive arrangement as standards bodies permitting royalty-due patents in their specifications is still tolerated?

This article first appeared on Webmink in Draft.

Image it’s not thieving if it’s from the bin, right? by Simon Phipps.