My write-ups
Welcome to my blog!
Here I share some of my work and articles. Although, admittedly, these articles are mostly written for my own educational purposes.
Enjoy your stay,
Eliot Roxbergh
In lack of new blog posts, I would like to refer to some small projects I’ve recently done. These projects have a more practical nature.
2023-05: I tried the open-source security device Tillitis TKey. A more trustable alternative to 2FA tokens, for instance? Find my post here: https://www.assured.se/posts/getting-started-tillitis-tkey-security-token (or for a shorter version: https://github.com/Eliot-Roxbergh/tillitis_hello).
2023-04: After working with a client, I updated my earlier post on GPL compliance to include additional information about LGPL.
2022-10: I spent one month using the open-source Linux phone, Pinephone, as a daily driver. Linux phones are still immature, but the essentials are coming into place.
Find my post here: https://github.com/Eliot-Roxbergh/notes_pinephone.
After working with C for the last two years (2020-2022), I did some small side projects to practice and summarize what I have learned.
My latest exercise Portknock gives an example on how to develop in C (cmake, code analysis, GCC flags, unit tests, ..), and Static Analysis compares different static analysis tools for C.
For reading on security for the C language see Secure C that contains my study notes, intended for use as a reference.
Portknock Exercise (code exercise with summary of testing and flow: cmake etc.)
https://github.com/Eliot-Roxbergh/task_portknocker
Static Analysis (short case study & presentation on SAST for C)
https://github.com/Eliot-Roxbergh/static_analysis
Secure C notes (summary of the Secure Coding in C and C++ book & other notes)
https://github.com/Eliot-Roxbergh/examples/blob/master/c_programming/book_secure_c.md
React exercise
https://github.com/Eliot-Roxbergh/examples/tree/master/c_programming/examples/react_exercise
Notes on development and more
https://github.com/Eliot-Roxbergh/examples/
To expand on the earlier article on GPL licensing, I did a read up on patents in open-source software which I present here. Feel free to email me any comments or corrections (e@ this domain).
Eliot Roxbergh 2021-06-09
Patents, unlike copyright, aims to protect an invention (i.e. an underlying logic) as opposed to a specific implementation (i.e. work). In this article, I refer to US law. Where, from what I understand, software patents are more broad and powerful than in the EU. Software patents are controversial, but that is a topic for another time.
Initially, my questions were i) why are companies seemingly hesitant to contribute to open-source software from an intellectual property perspective? Considering most companies in some way use open-source software, to then share their changes upstream could benefit them by lowering their technical debt. And ii) what is the risk for a consumer of open-source software to be liable, mainly does a party absolve its patent rights by distributing a work under an open-source license? To partially answer both these questions, I present two possible defenses explaining why patent rights are usually not enforeable for the work distributed by a patent holder. In short, these reasons are patent exhaustion as well as the rights given in the software license.
Comment regarding the EU: In the European Union, “programs for computers” are said to be not patentable, but in practice, certain software patents are both present and enforceable [1] (although seemingly more limited than in the US [2]).¹ Still, the general ideas presented here apply. Ideas, such as, patent exhaustion as well as you cannot expect to sue your users for behavior that you clearly allow in the license (i.e. an implicit patent clause). The issues with software patents are also said to be less severe in the EU [2], partly since it is harder for patent trolls to operate, as they need to pay legal costs if the suit is lost [3].
¹ More on this here: https://www.bardehle.com/europeansoftwarepatents/software-patent-epo/ (and also https://en.wikipedia.org/wiki/Software_patents_under_the_European_Patent_Convention).
[1] - https://fsfe.org/activities/swpat/swpat.en.html, https://www.epo.org/law-practice/legal-texts/html/epc/2020/e/ar52.html
[2] - https://startupxplore.com/en/blog/startup-patents-in-europe/, https://thenextweb.com/news/how-the-us-patent-mess-affects-european-tech-and-startups
[3] - Voet, Milan, Trolling the U.S. and EU Patent System: Solved by a Loser-Pays-Attorney-Fees Regime? (May 4, 2018). Available at SSRN: https://ssrn.com/abstract=3463481
As one could expect, it is not possible to give a complete answer on patent law for open-source software as this depends on, for instance, the jurisdiction and potentially the license text in question. Still, it is true that if a patent holder distribute a work, they should not be able to sue legitimate users for patent infringement. The two possible defenses are patent exhaustion and an interpreted patent license (implicit or explicit) from the software license [1].
Firstly, the idea behind patent exhaustion, is that the patent holder should not profit more than once for the transfer of a good [2]. Therefore, distributing a work (including as open source¹) exhausts the patent. So, by providing a work as open source, it makes the patent holder’s relevant patents harder to enforce (as someone could then reuse the open-source code to circumvent the patents). Moreover, patent exhaustion could also extend to (re)distribution, which risks limiting the patent’s enforceability, even if the patent holder only redistribute another’s work. In other words, the patent holder lose some rights to enforce patents to the benefit of the users, for the work conveyed as open-source (regardless if it is theirs or not).
Secondly, if a software license provides certain rights, such as to use and modify the software, it would be hard for the author to argue that a patent they hold could then restrict these rights they have specifically granted. That is, an implicit patent license can generally be assumed for the agreed use, as stated in the software license. The exact wording in the software license is thus also very important. However, as long as the (implicit patent clause) interpretation has not been tested in court, it will not be completely certain. This is why some modern licenses (such as GPLv3, discussed later) include a clause that explicitly grants a patent license to its users.
¹ As I use the term here, open-source software must fulfill two requirements: software (1) whose source code is available and (2) whose license allows its users to use, modify and redistribute this code (and binaries, if included). Not to be confused with source-available software, that is, software whose code is available to view but without these additional rights. Arguably, open-source software does not need to be free of charge. However, when I write here, I have gratis open-source software in mind. For a quick reference, Wikipedia on open-source software, “software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose [..] software that is by definition licensed free of charge”.
[1] - https://www.elgaronline.com/view/journals/qmjip/8-3/qmjip.2018.03.03.xml, https://www.ipmvs.com/news/the-federal-circuit-defines-implied-licenses-and-examines-exhaustion-doctrine/
[2] - https://lwn.net/Articles/780078/, https://archive.fosdem.org/2019/schedule/event/patent_exhaustion/
A possible defense is to argue patent exhaustion (regardless of the software license). Namely, if a patent holder, sell or otherwise distribute a work covered by their patent, the patent is exhausted. Then it is no longer possible for them to sue for patent infringement for that conveyed work. This also applies for open-source distribution, so that if the work is released as such, they may not sue the users for patent infringement [1][2]. With patent exhaustion, note that the patent is still in effect and enforceable, however just not when it comes to the distributed work in question.
Taking patent exhaustion further, it could also apply for redistribution. This is an important point, since for instance, if a company redistribute a large project like Linux, it should be that they exhaust all their related patents by doing so. Moreover, if a company clone a Git repo, make some changes, and then make a pull request. Then, this could count as redistribution which would exhaust any patents applicable for the complete repository (at least James Bottomley argues this in his blog [2]). For these reasons, patent exhaustion could indeed be why some companies are hesitant to contribute to open-source projects. More on patent exhaustion here [1][2].
[1] - https://lwn.net/Articles/780078/, https://archive.fosdem.org/2019/schedule/event/patent_exhaustion/
[2] - https://blog.hansenpartnership.com/a-roadmap-for-eliminating-patents-in-open-source/
Other defenses could be based on the rights granted in the provided software license. To make it absolutely clear, the license can state that its users receive a patent license for the covered work, this is what is called an explicit patent clause. However, even if such a clause is not included, the license can still provide assurances (not to be confused with patent exhaustion) in the form of an implied patent license for the user; Open-source licenses state that the users of the software are given several rights, and if a patent license would be required to practice these rights, such a license can be implied (as this behavior was specifically allowed by the patent holder as per the license) [3]. Therefore, the licensee should be allowed to freely use and distribute the covered work (according to the terms of the license) even if the open-source license does not mention patents specifically. Examples of an implicit patent clause can be seen in the MIT license [2] or in the here stronger GPLv2 license, as these do not explicitly mention that a patent license is given to the user. [1]
The less clear the license is regarding patents, the higher the risk that the implied patent license defense is not recognized for some reason (although this should suffice for most cases in the US, for instance [2][1]) or that the extent of this patent license is insufficient as there might be certain edge cases [4][1][3]. Another question is to what extent an implicit patent clause has been tested in court, as it otherwise makes the situation uncertain [1].¹ For these reasons, some licenses provide an explicit patent clause to avoid depending on an implicit interpretation, as seen in GPLv3 and Apache. In these licenses, it is stated explicitly that the patent holder grants a patent license for use according to the terms of the license.² That being said, the implicit clause in e.g. GPLv2, still provides protection in many cases and jurisdictions [3]. In a 2006 talk, Richard Stallman states that an explicit patent clause was added since the clause in GPLv2 was not sufficient in all countries and that “[the explicit patent license in GPLv3] is pretty much the same as the implicit patent licence that US law gives people” [9].
Regardless of patents, the work is still naturally covered by copyright, and its license may put additional restrictions thereon. For instance, if the patent holder distributes the patented work under GPLv3, for a licensee to then utilize the granted patent license in their own work it must constitute a derived work, and thus also be licensed under GPLv3 (as is one of the requirements of the GPLv3 license). Otherwise, no patent rights are given, and the holder may choose to enforce the patent (remember that both patent exhaustion and a patent clause only gives rights when handling the conveyed work in question).³ [8]
Since an open-source license should allow for redistribution and modification, anyone could, in theory, then use, sell, and modify that patented code legally. So by the nature of open source, someone could potentially extract and modify the patented code and use it (i.e. the derivative work) themselves, without infringing on any patents held by the authors (or on the software license). Although from a patent viewpoint, this could in some ways be restricted depending on the interpretation of the patent license granted by the license, where an explicit patent clause could provide stronger rights.⁴
Comment: This article discusses defenses regarding the implicit patent license of GPLv2: https://assets.fenwick.com/legacy/FenwickDocuments/potential_defenses.pdf
¹ There are not many court cases regarding GPLv2’s implicit patent clause. For instance, there is a case from the US (XimpleWare/Versata 2013-2015) [10], but the situation is still not entirely clear.
² More than that, GPLv3 states that a contributor authorizes use under this license for the contents of its “contributor version”, referring to the whole GPL-licensed work. So just by distributing a GPLv3 work, the patent holder grants a patent license for the complete work (and not only for any modifications made) - specifically a “non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.” (from GPLv3 section 11). Also mentioned here on slide 18 https://www.ipa.go.jp/files/000028295.pdf (Eben Moglen, GPL3: Process and Product, 21 December 2007).
³ Discussed more in-depth here https://opensource.com/article/18/3/patent-grant-mit-license ([2]).
⁴ For instance, it is not as clear if the licensee changes or adds directly to the patented code, whether that addition is covered by the implied patent license they have received. Mentioned here regarding GPLv2 in the EU: http://en.swpat.org/wiki/Implicit_patent_licence#European_Union.
On another note, some licenses also include a so-called patent retaliation clause, this penalizes a user (of the software) who would sue a contributor (i.e. author) or another user of the open-source project for patent infringement. In which case, the license is terminated and the plaintiff (i.e. the suing party) loses all their rights under the license including any patent licenses granted [7].¹
Two examples of licenses that include a patent retaliation clause are Apache and GPLv3.² GPLv3 states that you may not impose any restrictions on the rights granted by the license, and if you violate the license, your rights provided by the license are terminated [6]. Here, they also specifically mention that “you may not initiate litigation [..] alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it”. Regarding the explicit patent clause, GPLv3 states that every recipient is given the patent license necessary to exercise all rights provided by the license [5].
¹ Although, arguably, they may still use the software, considering GPLv3 states: “You are not required to accept this License in order to receive or run a copy of the Program”
² As usual, it varies depending on the wording in the license. A comparison of patent retaliation clauses is presented here, pp. 15-38 http://people.apache.org/~cliffs/apacheconEU2007-schmidt-spectrum.pdf (Cliff Schmidt, 2007)
Here follows small excerpts from the main licenses mentioned earlier, as relevant for patent licenses.
In GPLv3 we have an explicit statement;
“Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor’s essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.” [6]
GPLv2 has an implicit statement (which does mention patents, but not specifically that users receive a patent license);
“if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.” [4]
Finally, in MIT, we see an even weaker implicit statement which does not mention patents at all;
“Permission is hereby granted [..] to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so” [2]
[1] - http://en.swpat.org/wiki/Implicit_patent_licence
[2] - https://opensource.com/article/18/3/patent-grant-mit-license
[3] - https://assets.fenwick.com/legacy/FenwickDocuments/potential_defenses.pdf
[4] - http://www.gnu.org/licenses/gpl-faq.html#v2OrLaterPatentLicense
GPLv2 implicit patent license, see section 6 and 7 https://www.gnu.org/licenses/old-licenses/gpl-2.0.html (and mentioned here: https://news.ycombinator.com/item?id=1978507)
[5] - https://www.gnu.org/licenses/quick-guide-gplv3.html
“Whenever someone conveys software covered by GPLv3 that they’ve written or modified, they must provide every recipient with any patent licenses necessary to exercise the rights that the GPL gives them. In addition to that, if any licensee tries to use a patent suit to stop another user from exercising those rights, their license will be terminated.”
[6] - https://www.gnu.org/licenses/gpl-3.0.en.html
[7] - https://www.gnu.org/licenses/gpl-faq.html#v3PatentRetaliation
“In effect, yes. Section 10 prohibits people who convey the software from filing patent suits against other licensees. If someone did so anyway, section 8 explains how they would lose their license and any patent licenses that accompanied it.”
[8] - https://assets.fenwick.com/legacy/FenwickDocuments/IP_Bulletin_Summer_2006.pdf
[9] - https://fsfe.org/activities/gplv3/tokyo-rms-transcript.en.html
[10] - HAAPANEN, Anna Kaarina. Free and Open Source Software and the Mystery of Software Patent Licenses Under the GPL. Journal of Open Law, Technology & Society, [S.l.], v. 7, n. 1, p. 19-28, dec. 2015. ISSN 2666-8106. Available at: https://www.jolts.world/index.php/jolts/article/view/107. Date accessed: 15 feb. 2023.
One aspect I have not considered here, is how a patent suit would play out in practice. For instance, a party should have been able to provide a legitimate defense based on patent exhaustion, but nevertheless be forced into accepting a settlement due to high legal costs. This, to some degree, is a reality since patent trolls do exist, thanks to cases like this.
Another question; if an open-source project infringes on a patent, who is held liable? Anyone can in theory be sued (such as the author, distributor, or user), and this in practice largely depends on who has the money [1]. However, do some licenses “change” (or make clearer) who is liable for patent infringement? For instance, does the patent clause in GPLv3 or Apache make a difference here? Reading the GPLv3, I did not find any direct mention of this.¹ And to the contrary, by distributing a work under any license I would assume you are more likely to be liable than a mere user of the software. Consider that (from my understanding) the software license is a legal contract between the (e.g.) author and the user. Therefore, to then license this work without (copyright or patent) rights would undoubtedly be problematic for the licensor, especially if they are doing so knowingly. We also see this reflected in the wording of GPLv3, “A “contributor” is a copyright holder who authorizes use under this License”.
¹ At first I thought the following paragraph could be relevant, “If you convey a covered work, knowingly relying on a patent license and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License […]”. However, this is referred to as the downstream shielding provision and not relevant for our question (because as I understand, “relying on” means that you in some way benefit from a patent license). Clarification from Richard Stallman, “We were already concerned about [..] the possibility that a distributor might receive a patent licence which did not explicitly impose limits on downstream recipients but simply failed to protect them. What if one company pays Microsoft for a patent licence where Microsoft says “Alright, we won’t sue you, but we’re just not making any promises about your customers if they redistribute it”. We had already written a downstream shielding provision into GPL version 3 saying that if you convey the program, and you are benefitting from a patent licence that is not available, that does not extend to the downstream users, then you have to do something to shield them.” - https://fsfe.org/activities/gplv3/tokyo-rms-transcript.en.html
[1] - https://ocpatentlawyer.com/everyone-in-the-supply-chain-could-be-sued-for-patent-infringement/
In this article, I have summarized some important things to keep in mind when using a GPL project together with your own work (under any license).
I have focused on GPLv3, but GPLv2, LGPLv2.1, and LGPLv3 are also discussed.
I am not a lawyer and I do recommend reading the relevant licenses - also explained in detail here [1]. Additionally, note that much is still up for debate and depends on jurisdiction and case law.
Eliot Roxbergh 2021-01-27
[1] - https://copyleft.org/guide/
Addendum: I use the term GPL contamination, referring to situations where using a GPL work incorrectly would legally require you to release your work under the GPL license as well (or stop using GPL work in a fashion that is not allowed). However, one could argue that GPL contamination is a too negative wording, as it only refers to the fact that if you use a GPL work beyond what is expressly allowed in the license, you are in breach of contract and could be held liable - but in this situation, you may instead license your work under the GPL and accept to be “contaminated”.
Note: In the following paragraph, I try to summarize how the FSF (/the GNU Foundation) themselves interpret the GPL license. However, as I later mention in the section on GPL Linking, most seem to argue that you can go further - for instance, to dynamically link against a GPL program, regardless how it is used, and still not be contamined.¹
To be sure that your work is not contaminated by the GPL, according to the FSF, the following should apply: The work should be an aggregate (as per the GPL license), meaning that it is separate and independent from the GPL licensed program. Therefore, the work should be able to function on its own, and any GPL components easily exchanged. The FSF states, that “you cannot incorporate GPL-covered software in a proprietary system” [2] and that a proprietary work cannot link to a GPL work (“because the program actually links to the library [..] the terms of the GPL apply to the entire combination”) [9]. On the other hand, they describe that it is allowed to use a plug-in with a larger work (one of which being covered by GPL) as long as they do not form a single combined program. Specifically, you are allowed to use fork and exec to run the plug-in. [1] The term used is that both works should communicate “at arms length” [2]. At a minimum, the programs should run as separate processes and communicate over an IPC mechanism like pipes. They cannot directly share any data structures. [3]
The GPL does not apply if the project is only used privately or internally within a company, and not distributed to anyone else [4].
If you convey a work covered by GPL in a non-source format (e.g. as a binary), additional to the source code, you are also required to provide installation instructions. These instructions could include makefiles and installation scripts, or whatever is necessary, to generate and (if applicable) run the executable. This is required for GPL (v2, v3) and LGPL (v2.1 [5], v3), however, it is more explicitly stated in the later versions: GPLv3 and LGPLv3 [6]. For libraries covered by LGPL it is also required to enable the users to relink and run the libraries, as well as to provide instructions on how this can be done [7]. Comment, in the case that the work is only conveyed in source code, and not in any non-source format, you are not required to provide installation instructions as stated in the GPL licenses (also discussed here [8]).
Side note, LGPLv3 incorporates the full GPLv3 license and is therefore equivalent in many areas.
¹ “Contamination” is often used in this context, which means that your work will be under the GPL license due to how it interacts with a GPL-licensed work. Thus you are forced to release your work under the GPL as well or risk getting sued (for breach of contract and/or for copyright infringement [10]).
[1] - https://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins
[2] - https://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
[3] - https://www.gnu.org/licenses/gpl-faq.html#MereAggregation (included below)
“An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program’s individual license would grant them.
Where’s the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.”
[4] - https://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
[6] - https://www.gnu.org/licenses/gpl-faq.html#InstInfo
Specifically:
LGPLv2.1: “an executable [..] must include any data and utility programs needed for reproducing the executable from it” - https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
GPLv3: “The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.” - https://www.gnu.org/licenses/gpl-3.0.html
[7] - https://www.qt.io/licensing/open-source-lgpl-obligations
[9] - https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
[10] - https://perens.com/2017/05/28/understanding-the-gpl-is-a-contract-court-case/
Additional discussion, not referred to in this article:
https://softwareengineering.stackexchange.com/questions/50118/avoid-gpl-violation-by-moving-library-out-of-process
https://softwareengineering.stackexchange.com/questions/367844/can-i-include-a-gpl-v3-binary-with-my-proprietary-application-if-i-prompt-the-us/367850#367850
https://softwareengineering.stackexchange.com/questions/102778/is-running-an-executable-as-a-child-process-the-same-as-linking-a-library
https://opensource.stackexchange.com/questions/5447/to-which-extent-gpl-license-contaminates-my-project
GPLv3 and LGPLv3 are generally stricter than GPLv2 and LGPLv2.1, respectively.
The main differences between the versions are the following:
In general, the (L)GPLv3 license was also internationalized, avoiding US-specific terminology [5,8].
For more information: the changes are briefly discussed here [5, 7], and in more detail here [8].
¹ Together with the explicit mention of patents, so called patent retaliation is also included in GPLv3 [9] [10].
² For more information on software patents, including for GPLv3, see my later post Patents and open-source Software.
[1] - https://www.qt.io/licensing/open-source-lgpl-obligations
[2] - https://www.gnu.org/licenses/gpl-faq.html#Tivoization (included below)
“When people distribute User Products that include software under GPLv3, section 6 requires that they provide you with information necessary to modify that software. User Products is a term specially defined in the license; examples of User Products include portable music players, digital video recorders, and home security systems.”
[3] - https://www.gnu.org/licenses/gpl-faq.html#v3PatentRetaliation
[4] - https://fsfe.org/activities/gplv3/patents-and-gplv3.en.html
[5] - https://www.ifross.org/en/what-difference-between-gplv2-and-gplv3
[6] - https://www.gnu.org/licenses/license-compatibility.html, https://www.apache.org/licenses/GPL-compatibility.html, https://opensource.stackexchange.com/questions/11082/why-is-the-gnu-gpl-v3-compatible-with-the-apache-license-v2-0
[7] - https://www.gnu.org/licenses/rms-why-gplv3.html
[8] - https://web.archive.org/web/20181223234838/https://www.ipa.go.jp/files/000028295.pdf (Eben Moglen, GPL3: Process and Product, 21 December 2007)
[9] - https://fsfe.org/activities/gplv3/patents-and-gplv3.en.html#Compatibility-with-broader-retaliation
[10] - https://www.gnu.org/licenses/gpl-faq.html#v3PatentRetaliation
Since any linking to or from a GPL-covered program would create a single combined work (according to the FSF), another license was also created: the Lesser GPL (LGPL). The LGPL allows for libraries to be used from works covered by other licenses (including proprietary works), while otherwise providing the same rights as the GPL. In the same way as the GPL, LGPL comes in two versions (v2.1 and v3) and some differences between them were mentioned in previous section. The LGPLv3 itself refers to the complete GPLv3 license, but adds a few exceptions when it comes to libraries and is therefore more lenient in these cases. LGPLv2.1 is a stand-alone license, but shares the same spirit. Note that these terms are still regarding distribution of software (i.e. when you “convey the work”): not necessary for internal or personal use.
According to the LGPL, to put it bluntly, your work gets contaminated by LGPL if it is what they call “based on the library”¹. That is, if your work directly includes LGPL code or if your work cannot function without the LGPL parts (either on its own or by replacing the LGPL work) it is “based on the library”; in other words, if your work and the LGPL work form a combined work (except for linking as is explicitly allowed in LGPL). However, the LGPL is referred to as weak copyleft² since much can be accomplished while combined (linked) with another work, which then falls under “works that use the library”.³ [1]
In the latter case, for “works that use the library”, your work is not contaminated even if you link against an LGPL licensed library. The following applies: You may dynamically link against LGPL licensed libraries without disclosing your work. However, if you provide the LGPL library (dynamically linked), you need to provide its source (as well as the license text, and build instructions). On the other hand, if you statically link, you also need to provide information to enable users to relink the software, including providing the object files (or source code) of your work (however it does not need to be under LGPL). [2] According to one source, statically linking can easier be seen as “based on the library”, and that it is therefore safer to dynamically link [3].
There are also two more differences between GPL and LGPL (both versions), not regarding linking, which I can mention briefly; First, modifying code (and then distributing the changes) works like the regular GPL, however there is a clause that a LGPL library cannot depend (should still be useful) on a “facility” (i.e. data or function) that is supplied by an application “other than as an argument passed when [..] invoked” (see “facility” in LGPLv2.1/v3). Second, if a header file from LGPL is used in the application (i.e. your work) it could be that its object code (i.e. the “binary”) is also covered by LGPL (see “header file” in LGPLv2.1/v3).
Comment: My understanding is that GPLv2.1 is in general more allowing (or vague) than v3; In v3, more terms are strictly defined (mainly “Application” and “Combined Work”) whereas in v2.1 they are not and instead up to interpretation. Therefore you could make the argument that, for instance, linking from a LGPLv3 library to a proprietary work is NOT allowed, as only an “Application” is granted those rights [7]: an Application is defined in LGPLv3 as “any work that makes use of an interface provided by the Library, but which is not otherwise based on the Library”. However, from my reading of LGPLv2.1 the situation is different. That is, it could be acceptable to link from a LGPLv2.1 library to a proprietary work, if the following definition in LGPLv2.1 applies: (“work that uses the library” is described as) it is “A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it”. Then, we need to argue that section 4d1 applies, that linking from the library to our work is “linking with the library” and that the linking mechanism indeed “uses at run time a copy of the Library”. So the big question is: can linking from the library be argued to be a type of linking with the library. Note, these are only my personal oberservations from reading both licenses.
Comment: Instead of licensing your work under the LGPL, it is also technically possible to license under the GPL while explicitly allowing linking (i.e. a GPL linking exception) [4]. An example of this is the so-called Classpath exception, as used in the GNU Classpath Java library [5]. However, by choosing GPL with the Classpath exception in favor of LGPL, you are forgoing the few requirements (described just above) that other works linking against your work have.
¹ This terminology is specific to LGPLv2.1 but remains true also for LGPLv3.
² Copyleft refers to open-source licenses, such as the GPL, that require changes or extensions to the work to also be licensed under the original license (i.e. the license provides a “contamination” clause) [6].
³ TODO: LGPL also has another clause (v2.1: section 7; v3: section 5) which discuss additional allowances for combining two libraries (one of which is “based on” the LGPLv2.1 library and the other is not) into one. Is this useful? What are some practical examples of this?
[1] - https://copyleft.org/guide/comprehensive-gpl-guidech11.html
[2] - https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic (included below)
“(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user’s computer, you need not convey the library’s source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library’s sources, in one of the ways for which the LGPL provides.”
[3] - https://www.qt.io/licensing/open-source-lgpl-obligations
[4] - https://en.wikipedia.org/wiki/GPL_linking_exception
[6] - https://www.gnu.org/licenses/copyleft.en.html
[7] - Discussed here: https://opensource.stackexchange.com/questions/9274/what-permissions-does-lgpl-3-0-grant-if-the-licensed-work-links-against-a-propri
Tangentially relevant: https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs
In this section I use the term GPL for referring to both GPLv2 and GPLv3, as they should be similar when it comes to linking.
To summarize: From a legal perspective, it is safer to use dynamic linking over static linking, as the risk of contamination is lower.¹ Dynamic linking is generally considered to be within the law according to legal experts, or at least, it should be allowed if it can be shown that the program in-fact functions and provides value even without the GPL work. Still, it is impossible to say conclusively without considering specific jurisdictions and for instance recent cases regarding GPL compliance.
FSF describes that it is not allowed for a proprietary program to directly link (dynamically or statically) to a library licensed under GPL [1] (as described earlier, they need to communicate “at arms length”). However, legal experts often claim that it is acceptable to dynamically link to a GPL work. Especially if the proprietary work is separate from the GPL work and does not depend on it. Ergo, the proprietary work should be able to utilize components other than the GPL-affected ones and still function (additionally, it should not be a derivative work of the GPL project). [2,4] Indeed, this is contrary to what the FSF writes [1]. Still, just because the FSF argues that the GPL should cover dynamic linking, does not necessarily make it so in practise [4]. From what I have read, dynamically linking GPL code is most often interpreted as to be allowed: in US [2,5], English [4], and EU [3] law. While statically linking is often seen as not allowed or uncertain. According to one source, statically linking should be the same as including the code directly [4].
¹ Dynamic linking is always safer than static linking, regardless if the license is (L)GPLv2 or v3.
Additional reading
This was also discussed in an LWN article, regarding a presentation by Armijn Hemel, which states: “The key point is that the build-time and run-time environments may be different […]. This is important because, in his opinion, dynamic linking moves questions about derivative works and the application of the GPL license into run time, because it is only at run time that libraries are linked with a program. The dynamically linked libraries that are used at run time could indeed be different—and have different licenses—from the libraries that were specified during the static linking phase. This implies that (depending who you ask) declaring the wrong dependencies in a binary could trigger license compliance issues.” [3]
For an introduction to linking and GPL I refer to [4]. And for another perspective, “In short, the debate over static and dynamic linking simply misses the mark”, see [5].
Not law focused, Practical GPLv2 Compliance, (authored by Armijn Hemel et al.),
https://www.linuxfoundation.org/resources/publications/practical-gpl-compliance
[1] - https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL (included below)
“Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL”
[2] - http://mediatechlaw.mstreetlegal.com/2014/04/25/open-source-dynamic-linking-and-licensing-consideration-for-developers/ (GPLv3, US law)
[3] - https://lwn.net/Articles/548216/ (≈EU law)
[4] - https://web.archive.org/web/20130514013222/https://moorcrofts.com/documents/GPL%20-%20the%20Linking%20Debate.pdf (GPLV2, English law)
[5] - https://web.archive.org/web/20110514024547/https://www.law.washington.edu/lta/swp/law/derivative.html/ (GPLv2, US law)
[6] - https://www.qt.io/licensing/open-source-lgpl-obligations (LGPLv3)
In general, license compatibility refers to the fact that you can combine multiple programs of different licenses (which you do not hold the copyright for) as long as you adhere to the licenses. For instance, you may take a BSD and an MIT licensed program and combine them into one proprietary program. You may then release this work under a proprietary license and impose any additional restrictions. However, you must still fulfill all the requirements of the licenses, which in this example requires the inclusion of both original copyright notices. Far from every license is compatible, as each obligation in the licenses must be fully followed. [p. 161, 1]
GPLv3 (and a similar clause in GPLv2) states that “you may not impose any further restrictions on the exercise of the rights granted or affirmed”, which limits its compatibility with other licenses. Therefore, one needs to be careful when claiming a license is compatible with GPL, possibly even if the license is listed as compatible by the FSF [p. 160, 1]. It is due to this clause, that GPLv3 code cannot be included in Apache projects, while the opposite (i.e. Apache code in GPLv3 projects) is allowed [4].
Comment: GPLv2 and GPLv3 are not compatible. However, as it should be explicitly stated that “GPL version 2 or any later version” can be used, the user or developer can decide which version to follow. As far as I understand, this has nothing to do with license compatibility but rather a type of multi-licensing.
First, if there are multiple contributors (i.e. copyright holders) to a project, all must agree if you are to change license (e.g., by signing a CLA beforehand). However, there is an exception. Namely, you are always allowed to switch to a compatible license [2]¹. Of course, the old license still applies to the software at that earlier point.
Second, when multiple compatible projects are merged, all licenses still apply to their respective parts. However, if you wish, the combined program can be seen as licensed under only the most stringent license present - assuming they are compatible. For instance, GPLv3 and Apache 2.0 are compatible (in one direction [4]), and together a combined work under these licenses could be seen as the strong copyleft GPLv3 [3].
¹ Details regarding compatible licenses are described here [3].
[1] - Andrew M. ST. Laurent (2004), Understanding Open Source and Free Software Licensing, ISBN 978-0596005818
[2] - https://opensource.stackexchange.com/questions/33/how-can-a-project-be-relicensed/46#46
[3] - https://www.gnu.org/licenses/license-compatibility.html
[4] - https://www.apache.org/licenses/GPL-compatibility.html (included below)
“Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF’s licensing philosophy and the GPLv3 authors’ interpretation of copyright law.”
Master’s Thesis: Protecting Confidential Erlang Workloads with Intel SGX (2020)
Bachelor’s Thesis: Open Source Security Token for Linux (2017)
Consensus in the Presence of Byzantine and Transient Faults (2019)
Verifiable Operating System (2019)
© 2021 Eliot Roxbergh All Rights Reserved