Open source does not mean what you think it means

Getting your Trinity Audio player ready...

To some, litigation of any kind is seen as a bad thing: it means little more than a dispute and a collapse in a relationship and something to be avoided at all costs.

However, the fact is that litigation—and litigants—are vital mechanisms by which questions of law are explored and defined. Legislation can never account for every foreseeable circumstance. Even (or especially) where legislation already exists covering a point of law, the application of that law is an exercise in interpretation and the examination of precedent. This means that it is not only inevitable but an important feature of society that people will use the courts to establish their rights, which works to both their own benefit and the benefit of society.

No industry is in direr need of this than the blockchain industry. In 2021, billions upon billions of transactions take place on blockchains based around the world and these transactions are relied upon to be correct. Certainty around licensing is vital to uptake of software products, especially at the enterprise-level.

Unfortunately, the Bitcoin community in particular has fetishized the concept open-source to the extent that it has become nearly inseparable from the promise of Bitcoin and blockchain technology generally. This has confused many about what open-source licensing actually means. It seems self-evident that in no way does open source take a project or the responsibility of the creators and users outside of the law, but it is a sadly common attitude throughout the digital asset community.

The result of this has been open hostility to any legal action which might be seen as infringing on ‘open-source’, despite the fact that such legal action is a necessary part of legal development in most jurisdictions. Ultimately, this attitude is self-defeating. An incorrect understanding of the law is no shield against a plaintiff who does understand the law, as those who have recently found themselves on the receiving end of Dr. Craig Wright’s legal letters have discovered. 

Open-source licensing and enforceability

Open source licenses are those which allow software (or other products) to be freely used, modified and shared.

Generally, open source licenses fall into one of two categories: “copyleft” and “permissive.” A copyleft license is one in which code derived from open source code inherits the terms of the original license. A permissive license is one which allows the software to be reused in any other project, including ones which are not released under an open-source license themselves.

There has been some debate about the legal basis for enforcement of open-source licenses.

Under one analysis, a license is a contract between the creator and the user of software. However, some requirements that typically apply to contracts are not present: the author is contracting with an unknown number of users who do not notify the creator that they have entered into a contract. Likewise, it is foreseeable that someone might download a piece of software without having notice of the license, which would make enforcement of a contractual claim difficult. A critical component of a contract is consideration: in other words, there must be an exchange of value between the parties for there to be an enforceable contract. Damages can also be difficult to prove because an open source licensee is not asking for payment or royalties.

Another approach is to consider open-source licenses “bare licenses,” which are what copyright holders grant in order to allow the recipient to exercise any of the rights embodied in the copyright. Unlike the contractual argument, here there is no requirement for an acceptance on the part of the licensee, because without the grant of the license, there can be no use of the software without infringing upon copyright anyway. For a licensor to enforce a copyright claim, they must prove that the work was copyrightable, and they must prove authorship of the work. However, this analysis cannot rely on the vast body of contract law to assist with interpreting the terms of the license. At the same time, this means that the rigorous contract termination requirements governed by contract law do not come into play in the situation of a bare license, meaning it can generally be revoked at any time, as was done in the English case of Robson v Hallett. 

These are not mutually exclusive. In cases where courts have been asked to enforce open-source licenses, they have accepted the ability for claims to be brought in contract and in copyright (See Jacobsen v Katzer).

Not only do these approaches differ in the elements they require to be established, but also in the remedies. For example, an infringement claim in the U.S. is backed by the regime of the Copyright Act, which provides for statutory damages and legal costs.

Why does it matter for blockchain

These are not academic questions. They are important; even more so for businesses. Businesses are being invited to rely on blockchain technology—often open-source—at a time where the rules governing the software are not clearly understood. The boundaries of the law in this area are still being worked out.

For example, imagine a situation where there are three programmers: A is the author, B is a programmer to whom the license has been granted, and C is another programmer unconnected with A. If A grants a license to B with the condition that use of the original code be attributed, which he fails to do while C incorporates the unattributed code of B into their own project, what recourse does A have?

Similarly, it is highly relevant to a business looking to use open-source software to build their own product whether or not their new product inherits the license of the original software—where that license is open source, the ability of the business to monetize their new product is restricted. This is the case for some open-source licenses, but not others.

Perhaps most importantly is the question of developer liability for open-source projects. This is a part of a topic beyond the scope of this article, and CoinGeek will be examining the subject in depth in the near future. However, it is worth noting that open-source licenses typically contain disclaimers absolving the licensor of liability, which may or may not be enforceable depending on the circumstances. This differs depending on jurisdiction, but in the United States and the United Kingdom courts are typically suspicious of disclaimers which prevent the subject from pursuing legal redress.

Open source needs litigants

Nothing about the legal actions launched by Dr. Wright is inconsistent with open-source licensing, despite how the move has been painted by certain parties. On the contrary, the courts have always been used to explore and define the legal rights and obligations which attach to open source development. For the law to develop in response to new technologies, it needs plaintiffs and sets of facts on which to rule. This is a feature rather than a bug of our legal system.

To illustrate, it was as recently as 2006 that the question of whether the consideration element of contract formation was satisfied in the case of an open-source license was settled in the United States, for instance (Jacobsen v Katzer). There, the court ruled that compliance with the obligations imposed by the terms of the license was legally recognized consideration. Jurisprudence in this area is constantly developing.

However, while the exact boundaries may yet to be fully explored by the courts, the one thing that we can say for certain that open-source does not mean is that it absolves either the creator or the user from liability. It does not protect those using the license from litigation.

Consider this: releasing a blockchain under an open-source license may mean that it is able to be forked without violating the license. A software project being worked on my independent parties is likely to stumble upon disagreement at some point, and the practice of hard-forking is a method afforded by open-source to allow that disagreement to be resolved. However, just because this is the case does not mean that other areas of law have no relevance: a legitimately forked blockchain might not violate the license itself, but if that fork deceptively passes itself off as the original, then well-established legal concepts such as fraud and intellectual property still apply.

Similarly, if a developer releases software under open-source licensing with the intent that the software be used for an illegal purpose, then nothing in the license can save either party from criminal liability. This very question was addressed by the then commissioner of the Commodity Futures Trading Commission (CFTC), Brian Quintenz, who considered whether the CFTC should pursue open-source developers whose product is used to violate CFTC regulations.

“Absent proof that developers intended that the code facilitate conduct that is illegal, the CFTC should not bring a case against them. On the opposite side of the spectrum, there are instances where developers knowingly design code that can be used for unlawful purposes, and intend that the code be used for such purposes… In that situation, the CFTC could pursue a case against the developer under an aiding and abetting theory.”

However, it is important to note that Quintenz stressed he was speaking about an area of law which is still developing. His focus here is on intent, but the degree to which a creator’s intent matters if their open-source software is used for an illegal purpose is yet another question that must be teased out by litigation in absence of legislation and regulation.

Other areas of law which will be relevant and which must be considered alongside open-source considerations are that of duties, fiduciary or otherwise, which might arise as a result of the relationship between the creator and users who are relying on their creation.

Conclusion

Many more lawsuits stand between blockchain and mass adoption. Enterprises will only be so willing to commit themselves to a technology if it is still fraught with legal misunderstandings or open judicial questions. Businesses will not be able to rely on open-source software if they are to be attacked and ostracized whenever they are forced to enter litigation to assert or defend their rights.

To suggest otherwise is to stick one’s head in the sand. The law applies to you whether you acknowledge it or not. A business might be able to continue for some time while operating under a misunderstanding of their legal obligations, but an injunction from a licensor might bring the entire business to a screeching halt.

More clarity is always better. It is thanks to motivated plaintiffs that the wider community will be able to get this clarity on how the law applies to open-source software and blockchain generally. That is something we will ultimately celebrate.