Open source licenses are shared resources

366 readers like this.
The Mozilla Public License - almost 2.0 (part 1)

One can easily see examples of software as a shared resource, whether shared by a few people or a few million people. Of course, these shared resources are not always as fully appreciated as they should be. They can pass underappreciated until drama such as a security vulnerability draws attention and illuminates the importance of what is being shared.

But a license? A shared resource?

Yes, open source licenses are shared resources. And, they, too, may be underappreciated until a vulnerability is exploited. Legal documents (contracts, licenses, whatever they may be called) are typically unique to each commercial enterprise. Certainly, there is some commonality. Lawyers adapt from what others have done. Patterns are followed. Text is reused.

A court's interpretation of a detail in one license may impact a future court's decision regarding other licenses that use the same text or pattern. On the other hand, there may be reasons (differences in the license text, differences in business situation) to treat each license as a different license. But, consider the licenses that begin "GNU GENERAL PUBLIC LICENSE Version 3 29 June 2007" or "Apache License Version 2.0 January 2004" or "Eclipse Public License - v 1.0." Those and other commonly used free and open source software licenses are used each time with exactly the same text, starting with the title.

This sharing is good.

Many have thought that their situations were so different as to merit different licenses. But, when it comes to open source software licensing, history strongly suggests that situations are less different than one might think. Observations of the consequences of these (mis)perceptions of need for a new license led to a negative meme about "license proliferation." Now, selecting from a list of existing licenses has become a widely recommended practice, rather than drafting yet another license variant.

OK. License text is shared. Why might that matter?

License text, like natural language text generally, is not absolutely precise or complete. For example:

  • What is the copyleft scope of the GPL? As applied to a program written in Python?
  • What does "module" mean in the EPL? How about when classes in an object-oriented program are subclassed?
  • What does "by combination" encompass in the Apache License?

Focusing on a small number of licenses has an upside. Experiences and discussions can more readily reduce uncertainty through broader common understanding of a few licenses than if license-related actions and debates were divided among hundreds or thousands of different licenses.

This upside can include judicial interpretations. Judicial rulings on points about which people might have differing views can increase certainty more readily if there are fewer licenses. If you are using the Foo License, a ruling on the similar but slightly different language in the Bar License is less helpful than a ruling on the license that you are using.

But, there is risk, too. Judicial interpretations are informed by the facts of the particular dispute before the court. In the legal profession, there is an adage, "Bad facts make bad law." Getting nervous? It gets worse. The court forms its judgment based on the arguments of the parties to the dispute at hand. The interests of the particular parties and the nature of their dispute can lead to presentation of arguments for license interpretation that would not be made by most other users of the license.

A court's ability to look beyond what the parties provide is limited—in most courts, very limited. There can be opportunity for others to offer additional views, such as amicus curiae. Most frequently, this additional input occurs at the appellate level, which may never be reached if the parties settle after trial but before appeal.

In common law jurisdictions, precedent plays a particular role in the judicial decision-making. Civil law jurisdictions take a different approach to achieving judicial consistency. There are also considerations of judicial comity. In short, even though the outcome in one court is generally not determinative of the outcome in another, what courts decide can have varying degrees of impact on what other courts will do.

Here are two examples.

The decision in 2008 by the U. S. Court of Appeals for the Federal Circuit in Jacobsen v. Katzer addresses (with a good result) a legal point of great consequence for open source licensing. Awkwardly, the open source licensing issue arose as a side issue in a dispute involving domain names, trademarks, patents, and, ultimately, the Artistic License. It almost went very badly. The trial court saw the issue concerning the Artistic License as a contract dispute for which damages for breach of contract might be obtained. Fortunately, the appellate court saw the issue differently and reversed the trial court's decision on this point: actions were unlicensed and thus subject to copyright infringement remedies. The record of that case suggests that input from a group of amicus curiae may have played a significant role in convincing the appeals court to see the case differently than did the trial court.

The complex set of disputes involving Versata Software, American Financial Services, and Ximpleware appears to have been settled. But, what might have happened? Versata and AFS had a dispute having nothing to do with open source software—until AFS discovered some. That brought on the author of that GPL-licensed software, but who focused on the revenue generating potential of his patent claims. (See "Lawsuit threatens to break new ground on the GPL and software licensing issues" and "GPLv2 goes to court: More decisions from the Versata tarpit".) What interpretations of the GPL might have been advocated by the several parties? What might a court have ruled as to what certain parts of the GPL mean? It is possible that none of the parties to that litigation tangle would have had an open source community perspective.

In cases that lead to judicial interpretation of licenses, it matters who the parties are.

Licenses are valuable shared resources. What might we do to support these shared resources?

User profile image.
Scott Peterson is a member of the Red Hat legal team. Long ago, an engineer asked Scott for legal advice on a curious document known as the GPL. That fateful question began a twisting path of exploration of the legal aspects of collaborative development, including both technical standards and open source software.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.