TLF Connect Mentee Reflection: Legal considerations for the use of open-source software by startups
James Carstensen is a Legal Technologist, Graduate Law Student, and mentee in the TLF Connect Program. James’ mentor in the program is Dominic Woolrych, CEO of Lawpath.
In this piece, James reflects on the legal implications of startups’ use of open-source software.
As a TLF Connect Mentee, I was matched with Dominic Woolrych, CEO of the Sydney-based Lawpath, which provides legal document automation for businesses, ranging from incorporation to generating the terms and conditions for websites. This was just the tip of the iceberg, really. His platform leverages Amazon's AWS system, which has a lot of powerful technologies under the hood, like NLP (natural language processing) and elastic search - toys I hope to one day get the change to play with.
I took a look at Dom's system and attempted to leverage my prior training as a business/systems analyst before studying law to provide input and ideas. Dom impressed me with how much he had already considered - every idea I could throw at him he had already put thought into. We ended up talking about a lot of interesting ideas and topics about current and upcoming developments in legal tech. As I’m currently in Germany, isolated from my peers in Australia and unable to return home due to the pandemic, connecting with a professional was a great opportunity to engage with the field.
One of the topics of our discussions was open source development and innovation. Open-source is an important topic for legal tech startups. Typically launching with minimal resources, they often make use of open-source platforms (sometimes whether they realise it or not).
Many aren't aware of the risk of so-called "open source infection." Under the GNU General Public License (GPL)[1], software that includes open-source code must also itself be open source. This can, theoretically, lead to the unintentional conversion of proprietary in-house systems to open source.
This topic raised three interesting questions:
How enforceable is an open-source license?
Is it even a license?
Is infection an actual legal risk?
Of course, these are complex questions that cannot be answered overnight, but we took a crack at it, anyway.
The GPL did not appear to be judicially tested until 2004, a good 15 years after its first release in 1989[2]. The decision of Welte v. Sitecom in the District Court of Munich[3] is touted as the "first-ever judgment" on the enforceability of the GPL, finding it to be an enforceable copyright infringement. A later Paris Court of Appeals decision held that non-compliance with the GPL can also be a breach of an IT contractual arrangement.[4].
The interesting takeaway from these and other cases is the debate over whether the GPL is a license or contract.[5] Some have argued that it does not meet the elements of contract (lacking consideration or meeting of the minds),[6] yet these cases have appeared to accept the enforcement of GPL as part of a broader contractual obligation. This is clearly a complex question that needs deeper analysis than we could resolve in a few chats. But the legal outcomes we looked at suggest that using the GPL within a broader contractual arrangement would at least help facilitate its enforceability as part of the terms of the contract.
If the GPL is indeed enforceable, the critical remaining question is how dangerous is the risk of "infection"? The maligned part of the GPL3.0 is Article 5, which states:
"You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: ...
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged."
At a surface level, this does seem to infer that repacking open-source within your own solution could result in the obligations of the GPL3.0 encompassing it.
Like the contract/license dichotomy, the subject of open-source virality is heavily debated. The term might be a bit sensationalist. It is not really infection. It is actually just how copyright and derivation works.
Funnily enough, the question of contract versus license arises once again: Phil Albert, a San Francisco patent attorney office writes:[7] "If the software system is not a derivative work, a copyright license is not needed unless there is some other relationship between the parties that creates other obligations." He concludes: "If the license limitations are not acceptable, whether it is the GPL or a restrictive end-user license, the choice is to avoid using that software." This may seem to bode ill-tidings for startups relying on open-source technology, but all is not lost.
The key appears to lie in the technical meaning of derivation. Canadian Attorney Lawrence Rosen wrote on the distinction:[8]
Static linking requires a modification to the code of one program to allow it to link to another program. Such a modification, since it requires changes to the source code of the linking program, arguably creates a derivative work. If the linking program is licensed under the GPL, then the derivative work also becomes subject to the GPL.
Dynamic linking, on the other hand, is a transitory relationship between two programs for which they are each pre-designed. The linking program need not be modified to implement the linkage. For example, a printer driver for a new printer can be installed in a program without modifying the source code of the original program. Such linkage does not constitute the creation of a derivative work.
There's a difference when developing between modifying source code and simply interfacing with existing "code". What Rosen appears to be saying is that making use of open-source will not automatically "infect" the entire proprietary system your startup might be basing all of its hopes and dreams on. However, under the general principles of derivative works, it is vitally important to ensure that the way any open-source software under a license like the GPL is utilised is at "arms-length."
These discussions emphasises to me the characterisation of legal tech as an interdisciplinary field that requires input from both legal and technical professionals, with a need to jointly understand both the legal principles and underlying technical processes that power innovation. And that's what makes it so interesting.
References
[1] GPL 3.0 https://www.gnu.org/licenses/gpl-3.0.en.html
[2] GPL 1.0 https://www.gnu.org/licenses/old-licenses/gpl-1.0.html
[3] case 21 O 6123/04 (Welte v. Sitecom Deutschland GmbH), District Court of Munich, 19 May 2004, http://www.jbb.de/fileadmin/download/urteil_lg_muenchen_gpl.pdf (German); http://www.jbb.de/fileadmin/download/judgment_dc_munich_gpl.pdf (English). Welte also successfully won a similar claim against Skype a few years later in 2007: case 7 O 5245/07 (Welte v. Skype Technologies S.A.), http://www. ifross.de/Fremdartikel/LGMuenchenUrteil.pdf.
[4] EDU 4 v. AFPA, Cour d’Appel de Paris, Pôle 5, Chambre 10, no: 294, http://fsffrance.org/news/arret-ca-paris-16- .09.2009.pdf.
[5] See for example: Jones, P. (2003). The GPL is a license, not a contract. Linux Weekly News; 1; Hietanen, H. A. (2007). A License or a Contract, Analyzing the Nature of Creative Commons Licenses. NIR, Nordic Intellectual Property Law Review, Forthcoming.
[6] Kumar, S. (2006). Enforcing the Gnu GPL. U. Ill. JL Tech. & Pol'y pp. 16-24
[7]Albert, Phil (2004) GPL: Viral Infection or Just Your Imagination? https://linuxinsider.com/story/gpl-viral-infection-or-just-your-imagination-33968.html.
[8] Rosen, Lawrence (2001) The Unreasonable Fear of Infection. http://www.rosenlaw.com/html/GPL.pdf See also: Theresa Gue (2011) Triggering Infection: Distribution and Derivative Works Under the GNU Public License, pp. 130-132