Open Source Licenses

It is possible to write and distribute software, with no license whatsoever, but in the past decade it has become popular to attach to any released software some sort of license, defining the obligations of the person who downloads or modifies the software.

Software (or any other creative work) released with no strings whatsoever (and, in particular, with an irrevocable termination of any creator rights under copyright law) is said to be in the public domain. One large category of public-domain works are those for which copyright has lapsed; this category does not include any working software as copyright has a substantial lifetime (70 years from the author's death, in the United States). Perhaps some of Ada Lovelace's work for the Difference Engine (in the 1840's) can be considered software (though it never ran on anything); it is certainly now in the public domain. Alan Turing died in 1954; his work on programming does not enter the public domain until 2024. There is some legal question whether an author even has the legal ability to place his or her work irrevocably in the public domain, on the theory that potential rights under copyright can never be terminated.

The GNU public license is the earliest, perhaps mostly because the GPL tries to accomplish something legally tricky: it requires that any modifications must remain as open source. When the GPL was first written, people not concerned about this sort of thing would most likely use no license at all.

MIT

We will, however, start with the MIT license, which is perhaps the simplest. Here it is, from opensource.org/licenses/MIT:

Copyright <YEAR> <COPYRIGHT HOLDER>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), 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, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The only restrictions are the inclusion of the copyright notice and the waiver of liability. There is no rule that the source must be distributed; the copyright notice can be included in the executable. This is not spelled out explicitly however.

The waiver of liability might not be legally binding (though I am aware of no cases where this has been contested, if the software was distributed for free). You might think this odd, but the legal theory is that no creator of a product can escape negligence liability simply with a waiver. Were this not the case, nothing would stop vehicle manufacturers from claiming they were not liable for poor design. It is easy to claim in court that software errors are due to "negligence".

In 2009 the European Union proposed new laws on software that were intended to make it harder for companies to escape liability for software problems. The way the draft was worded, it appeared to make it impossible for Open Source to escape such liability. However, the laws were ultimately not adopted. Ironically, one version of the laws would have made it possible for software vendors to require that customers waive liability at the time the software was sold. Free software, not being sold, could not benefit from such waivers.

The X Consortium added to the MIT license a paragraph restricting use of the X Consortium name.

Software released under the MIT license can be:

People who see their open-source work as a contribution to society sometimes have an issue with one or more of these. On the other hand, if you want your software to be used, you may find that GPL-style licenses are too restrictive.

Daniel Haxx wrote the cURL package and released it under the MIT license. As a result, Haxx's email address appears in the license terms in odd places. In-car sound systems, in particular, often incorporate cURL, and so desperate users occasionally contact Haxx for help (daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola):

Hello sir
I have Avalon 2016
Regarding the audio player, why there delay between audio and video when connect throw Bluetooth and how to fix it.

Haxx appears to find this mildly entertaining. Sometimes it can be a nuisance.

There's a good in-depth analysis of the MIT license and common variants at writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html. Note the "limitation of liability" section.

BSD

The original Berkeley Software Distribution of Unix came with the original "four-clause" BSD license. The most common BSD license version today is the following "three-clause" version (opensource.org/licenses/BSD-3-Clause):

Copyright <YEAR> <COPYRIGHT HOLDER>

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The waiver of liability is more elaborate. Binary distribution is explicitly permitted, as is redistribution. The new clause is that the names of the copyright holders (any of them, as each new contributor may add his or her name) may not be used to promote the program.

It is not clear if the BSD license was originally understood to apply cleanly to improvements added by others; the BSD group likely thought that clause 3 above would apply only to them.

The original BSD license included a fourth clause:

All advertising materials mentioning features or use of this software must display the following acknowledgement:
   This product includes software developed by the <organization>.

That actually is a fairly intrusive requirement, which is why it went away.

Wind River sells an operating system -- VxWorks -- for embedded systems that is based on BSD Unix. In basic terms, Wind River can do this because the BSD license allows the creation of proprietary derivative works. Wind River has argued that basing their OS on Linux would not be an option, presumably because they'd have to open-source all their changes and that would cut into their market. (In slightly more complex terms, in 2001 Wind River bought BSDi, the owner of the core of BSD Unix from which OpenBSD, FreeBSD and NetBSD were forked. But they didn't need to buy BSDi for licensing rights; this purchase was more about getting employees and software tools.)

Apache

The license from the Apache Software Foundation is a bit long to paste in; here's the link: www.apache.org/licenses/LICENSE-2.0. The part you paste in to the source files is shorter:

Copyright [yyyy] [name of copyright owner]

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

The first section of the actual license includes a definition of multiple terms.

The second section includes an authorization under copyright. This authorization allows the creation of derivative works; that is, you can modify the software.

Section three includes a new feature: each contributor must waive any patent rights, or, more specifically, grant a free license to any users of the software. The idea here is that if you have a patent, and release or modify software under the Apache license, you cannot sue other users for patent infringement. Even if those other users make further modifications to the software. Here is the clause:

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

The penalty for suing over patents, though (in the final sentence), is that you lose any patent rights granted to you by other contributors. You do not lose the right to use the software itself. And if a later user adds a feature that causes the entire package to infringe on your patents, you can sue.

In this post, hodlerlaw.com/2013/12/02/the-apache-license-version-2-0-and-the-anti-patent-treachery-clause, J Hodler suggests that the Apache patent clause has symbolic significance only. The real risks of patent litigation are from so-called non-practicing entities -- companies that don't actually create anything, and so don't use the Apache-licensed software in question, and large companies (think IBM and Microsoft), who usually (though not always) also avoid Apache-licensed software.

Section four spells out the requirements for redistributing the software. This clause lets you redistribute for sale, but you must attach the original license terms.

Section five says that any contributions by default have the same license, but you are allowed to negotiate different terms.

The MIT, BSD and Apache licenses (and also many others) are collectively the permissive licenses. You many release a proprietary modification. The GNU licenses prevent this.

The GNU General Public License

This is the one that says that if you make changes, and you distribute them, then they too must be open source.

Richard Stallman wrote the first version of the GPL in 1989. This was followed in 1991 by GP v2. To allow the use of GPL libraries in non-free projects, it was accompanied by the "Library GPL", or LGPLv2. GPLv3 was released in 2007.

The actual texts of the licenses are here:

Here is the important GPL2 clause, that defines the copyleft feature [here and elsewhere, all bold emphasis is added]

  2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

    c) If the modified program normally reads commands interactively
    when run, you must cause it, when started running for such
    interactive use in the most ordinary way, to print or display an
    announcement including an appropriate copyright notice and a
    notice that there is no warranty (or else, saying that you provide
    a warranty) and that users may redistribute the program under
    these conditions, and telling the user how to view a copy of this
    License.  (Exception: if the Program itself is interactive but
    does not normally print such an announcement, your work based on
    the Program is not required to print an announcement.)

By way of explanation, the following clause also appears:

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

And this, which defines the legal nature of "copyleft":

  5. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

As far as patents are concerned, GPLv2 states:

  7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.

This clause means that, if for some external reason you cannot legally distribute the source code (either due to patents or copyright or some other reason), then you cannot distribute the binary either. Rms called this the "liberty or death" clause.

How murky is the GPL?

Some people feel the GPL is quite clear, and in some ways it is. But consider the following question:

Is a Linux kernel module covered by the GPL?

That is, if I write and distribute a Linux kernel module, which is sort of a "plug-in" to the standard Linux kernel, perhaps a driver, do I have to distribute the source?

[Kernel modules might be device drivers, but they also might add functionality. They might implement a different TCP congestion-control mechanism, or an alternative network transport layer like SCTP, or a disk interface for a database, or an alternative file-system interface.]

According to the GPL, your module is covered by the GPL if it is a "derivative work", which is a legal term in copyright law. But is a kernel module a derivative work?

If your module is a driver, that basically means it implements functions open(), close(), read(), and perhaps write() and ioctl(). That's a pretty limited interface. Even if your driver is written specifically for Linux, it is arguably a freestanding set of functions. Except that the driver probably uses Linux locks and memory allocation, which means it (a) links to the rest of the kernel, and (b) uses some Linux include files.

If you're writing an arbitrary module, you almost certainly include, say, module.h, and likely others. And, again, you probably use kernel locks, kernel time functions, kernel memory allocation, and other things. So that's looking more like a derivative work.

But then there's NDISwrapper, a Linux wrapper to support the use of Windows device drivers (particularly Wi-Fi drivers) on Linux. NDISwrapper is completely open source, but the Windows drivers it allows linking to are not open source. And clearly using them in Linux without the developer's consent doesn't bring them under the GPL.

Finally, the Linux licensing page (kernel.org/doc/html/v4.16/process/license-rules.html) spells out explicitly that user-space programs that use the Linux kernel interface and Linux include files are not to be considered derivative works:

The User-space API (UAPI) header files, which describe the interface of user-space programs to the kernel are a special case. According to the note in the kernel COPYING file, the syscall interface is a clear boundary, which does not extend the GPL requirements to any software which uses it to communicate with the kernel.

Legally, this is might not be considered automatic: user-space programs are dependent on Linux, and often on special Linux features. But if this rule is made explicit for user-space programs, and not for kernel modules, might that imply that the latter are derivative works?

Linus Torvalds has long tacitly accepted proprietary, binary-only Linux loadable modules.

For an email chain on this including Torvalds, see yarchive.net/comp/linux/gpl_modules.html.

Nvidia

At one point, around 2020, the understanding was that proprietary kernel modules were ok if they did not use any "GPL symbols", that is, names of functions (or data) that were covered by the GPL. Linux has a symbol_get() function that looks up kernel symbols, and a macro EXPORT_SYMBOL_GPL. The latter is used to mark symbols in kernel code that are part of GPL-covered code. The idea had been that a proprietary module was legit as long as it did not link to any symbols flagged with EXPORT_SYMBOL_GPL.

But Nvidia found a sneaky workaround: according to Christoph Hellwig, Nvidia got around the EXPORT_SYMBOL_GPL block "by importing exports from their proprietary modules into an allegedly GPL licensed module and then re-exporting them". This means that a very small GPL module can access both the Nvidia symbols and the GPL symbols, and thus "connect" the Nvidia module to the kernel. Ultimately this gave the proprietary Nvidia module some access to kernel names that were covered by the GPL.

See www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-Change.

LGPL

Then there is the Library GPLv2. In the preamble it states:

  The reason we have a separate public license for some libraries is that
they blur the distinction we usually make between modifying or adding to a
program and simply using it.  Linking a program with a library, without
changing the library, is in some sense simply using the library, and is
analogous to running a utility program or application program.  However, in
a textual and legal sense, the linked executable is a combined work, a
derivative of the original library, and the ordinary General Public License
treats it as such.

  Because of this blurred distinction, using the ordinary General
Public License for libraries did not effectively promote software
sharing, because most developers did not use the libraries.  We
concluded that weaker conditions might promote sharing better.

Here is the LGPL's Section 2 (left), side-by-side with the GPLv2 Section 2 (right).

LGPL GPL 
  2. You may modify your copy or copies of the Library or any portion
of it, thus forming a work based on the Library, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) The modified work must itself be a software library.

    b) You must cause the files modified to carry prominent notices
    stating that you changed the files and the date of any change.

    c) You must cause the whole of the work to be licensed at no
    charge to all third parties under the terms of this License.

    d) If a facility in the modified Library refers to a function or a
    table of data to be supplied by an application program that uses
    the facility, other than as an argument passed when the facility
    is invoked, then you must make a good faith effort to ensure that,
    in the event an application does not supply such function or
    table, the facility still operates, and performs whatever part of
    its purpose remains meaningful.
   2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.

    c) If the modified program normally reads commands interactively
    when run, you must cause it, when started running for such
    interactive use in the most ordinary way, to print or display an
    announcement including an appropriate copyright notice and a
    notice that there is no warranty (or else, saying that you provide
    a warranty) and that users may redistribute the program under
    these conditions, and telling the user how to view a copy of this
    License.  (Exception: if the Program itself is interactive but
    does not normally print such an announcement, your work based on
    the Program is not required to print an announcement.)

Clause (d) appears to be an effort to ensure that the LGPL can only in fact be used for libraries.

More specific library-related clauses are the following:

  5. 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, is called a "work that uses the Library".  Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

  However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".  The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

...

  6. As an exception to the Sections above, you may also compile or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.

A MySQL library libmysqlclient.so was originally licensed under the LGPL, but then changed to the GPL with MySQL v4. This means that linking to it brings your code under the GPL. Apparenly Oracle did this (or maybe Sun), to encourage the sale of commercial MySQL licenses.

GPLv3

In version 3 of the GPL, the language is, overall, more readable. The following clause is new:

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

In other words, you cannot use GPL-covered software as a basis for DRM.

Section 5 contains the copyleft feature:

Section 6 addresses distribution of binary code:

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

Section 6 also addresses another issue, which Stallman calls "Tivoization". TiVo built their DVR device with GNU/linux, and you can get their source code modifications, but their hardware does not allow you to install software with any further modifications made by you or others. The license includes a definition of "User Product" that excludes, say, medical systems.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information....

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed.

The apparent reason TiVo included this hardware lockdown was to prevent users from grabbing and saving the recorded content in raw digital form.

Section 11 addresses patent claims by contributors:

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.

Also this, in order to address the apparent licensing by Microsoft of some of its patents to Novell only:

You [Novell -- pld] may not convey a covered work if you are a party to an arrangement with a third party [MS -- pld] that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license....

GPL Enforceability

In 2005, Fortinet apparently used GPL-licensed code in ways that violated the license. Ultimately they had to release source code for their FortiOS system.

In 2006 a German court upheld the validity of the GPL in a lawsuit against D-Link.

In 2007, developers of the GPL BusyBox package sued Monsoon, which incorporated BusyBox but refused to release their modified source code. Monsoon eventually settled, opening their source and paying unspecified damages.

In 2013 a Hamburg court found that Fantec GmbH had violated the GPL in the distribution of a game module that made use of netfilter.

In 2016 a German court dismissed kernel dev Christoph Hellwig's lawsuit against VMware for GPL violation. Ultimately the court dismissed the case, on the grounds that Hellwig could not identify the specific code sections written by Hellwig that VMware had used.

In April 2017, California federal judge Jacqueline Corley ruled, in the case Artifex v Hancom, that the GPL was binding even though Hancom never signed anything. Artifex offered its Ghostscript pdf-rendering software on both GPL and commercial licensing terms. Hancom used the GPL version, modified it, violated the GPL, and tried to claim the GPL was non-binding.

In 2021, Stockfish, the open-source developers of a popular chess engine, sued Chessbase for GPL violations. Stockfish also terminated the GPL license (perhaps only as applied to Chessbase?). In November 2022, the parties settled, with Chessbase agreeing to open their code; see www.chess.com/news/view/chessbase-stockfish-reach-settlement.

But this isn't the complete story: chess engines are driven by large neural networks that have been trained on chess games. Suppose someone trains a newer neural network and bases their new chess-player device on that, using some GPL-licensed code. Is the trained neural network covered by the GPL? Or is this just data, not code? See fossa.com/blog/stockfish-vs-chessbase-gpl-v3, question 1, for more discussion.

In France, the situation may be different. See thehftguy.com/2021/08/30/french-appeal-court-affirms-decision-that-copyright-claims-on-gpl-are-invalid-must-be-enforced-via-contractual-dispute. French courts have traditionally regarded the GPL as a contract, that must be agreed to by both parties. It is possible that the plaintiff in the case in question, Entr'Ouvert, chose to pursue the idea that the defendant could be accused of counterfeit goods, rather than copyright infringement per se. And they lost on a technicality, and thereby lost the right to pursue other legal strategies. Or, possibly, they lost because France has less strict rules about copyright.

See also copyleft.org/guide/comprehensive-gpl-guidepa3.html.

As another observation, see Open Source Software: An Open Door to Intellectual Property Liability. It concludes with

In the end, it may be less expensive to pay more for commercial software, if only to purchase the benefit of the indemnification that typically runs with the license.

But open-source licensing is not that hard to deal with. The intent is usually very clear.

Karl Fogel, in Producing Open-Source Software, lists the following as one common management myth:

If we open source this project, then we'll have to release all our other stuff as open source too.

The roots of this myth come from misunderstandings of the GPL.

A weaker form of this myth, that is in fact a plausible if unlikely fear, is that if code covered by the GPL sneaks into a project, then the project becomes open source whether you wanted it to or not. But this has nothing to do with choosing whether to be open source. So there's nothing you can do about it, except to make it clear to your devs that all code they submit to you they must have written themselves.

Google has strict rules about allowing AGPL (below) software into their system. See opensource.google/docs/using/agpl-policy:

WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

Google does not have an absolute ban on just-plain-GPL, but they still don't like it. See opensource.google/docs/thirdparty/licenses/#restricted:

Third-party software made available under one of these licenses must not be part of Google products that are delivered to outside customers. Such prohibited distribution methods include ‘client’ (downloadable Google client software) and ‘embedded’ (such as software used inside the Google Search Appliance).

To be fair, there is a serious ambiguity in the Affero license that doesn't make it clear whether sharing code with third-party contractors constitutes "releasing" it. Google has a lot of third-party contractors.

Here is a blog post from Terminus DB: terminusdb.com/blog/2020/12/08/we-love-gplv3-but-are-switching-license-to-apache-2-0-terminusdb. Basically, this is a thoughtful discussion of the issues with GPL, leading them to switch to Apache. The GPL issues were, in brief:

  1. Cloud providers "steal" open-source packages (but if it happened to them, they would view it as a success)
  2. Lots of databases have moved away from GPL
  3. GPL is toxic at some companies

Red Hat

Red Hat distributes Red Hat Enterprise Linux, with source modifications. They have traditionally distributed their source to the public at large. But in June 2023, Red Hat decided that they will make their source available only to customers with Red Hat subscriptions: www.redhat.com/en/blog/furthering-evolution-centos-stream. As they put it, "for Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."

Is this legit? Technically, they are making the source available to everyone to whom they make the binaries available, so that part of the GPL is ok.

However, the GPL2 clearly states that anyone who receives the source code receives full rights to redistribute it. So any Red Hat customer can just go ahead and publish the Red Hat source to the world.

Except that the Red Hat customer contract appears to forbid this. Whether or not it actually does, Red Hat customers probably believe that they will lose their support contracts if they redistribute code. And they're not that motivated to rock the boat, at least not that much, so they just don't.

For further details, see opencoreventures.com/blog/2023-08-redhat-gets-around-gplv2-license-intention-with-contract-law.

Vizio

If someone takes GPL code, distributes a modified version, and refuses to release source, who has standing to sue?

Traditionally, the idea is that the perpetrator has not accepted the GPL, and is therefore violating the copyright of the original developers. Those developers can then sue for infringement. But only the developers who hold the copyright, which might be a specific contributor who contributed a specific feature. And only federal courts can hear the case.

Vizio TVs are based on Linux, and Vizio was not sharing the source. So the Software Freedom Conservancy (SFC) sued Vizio under contract law. This is a bit tricky; the argument is that the SFC has been harmed by Vizio's failure to abide by the contract. So the SFC has sued Vizio in California state court. They are suing for specific performance, that is, they are asking the court to order Vizio to release the code, rather than for pecuniary damages. So far, SFC has been doing quite well, although there are still hurdles. But the state court has agreed that this is a contract case, and that SFC has standing to sue, which is huge.

On Dec 29, 2023, the court issued an order in favor of SFC with the following language (sfconservancy.org/docs/Order_Denying_Vizio_Motion_for_Summary_Judgement_12-29-23.pdf):

Allowing third parties such as SFC to enforce their rights to receive source code is not only consistent with the GPLs’ objectives; it is both essential and necessary to achieve these objectives. Recipients of GPL-licensed software will be assured of their right to receive source code only if they have standing to enforce that right.

(By the way, the Red Hat excuse won't help Vizio: SFC actually bought a Vizio TV and asked for the source used in that TV.)

Classically, Vizio can just say there is no contract, and oops we violated copyright law. But that might get them in bigger trouble, if the Linux Foundation ever decided to sue, because then Vizio has already admitted guilt.

SFC v Vizio is tentatively scheduled for trial in September 2025.

Speaking of SFC, their former executive director Bradley Kuhn wrote an interesting article about GPL enforcement at sfconservancy.org/blog/2021/jun/30/who-should-own-foss-copyrights. One of his first points was that, if you are contributing to an open source project as an employee of a corporation, the corporation owns the copyright to your work unless some contract states otherwise. This somewhat complicates assigning copyrights -- fully or partially -- to the project.

Kuhn's second point is that, by and large, corporations oppose GPL enforcement. Partly they like to pretend that "nobody would actually violate the GPL"; partly they fear getting caught themselves. A consequence of this is that most of the actual copyright owners of open source -- the only ones who can sue for copyright infringement -- are not in fact interested in enforcement.

Finally, Kuhn goes into some detail about how GPL violations occur on a weekly basis. GPL violations are frequent even gcc and glibc, which Kuhn identifies as the two most-used open source projects (bash is probably near the top also in terms of usage, but the source seldom needs updating so there are fewer GPL violations.) GPL violations for gcc typically occur when a vendor makes modifications to support a proprietary system-on-a-chip; these gcc GPL violations usually accompany GPL violations for Linux itself as the source code for the modifications to run Linux on the new chip are also not released.

Github Copilot

Github fed more or less their entire codebase into a machine-learning system, and taught it how to generate small snippets of code, given a natural-language description. But a lot of that codebase was covered by the GNU license (GPL), which requires that any works that incorporate any part of the content have to also be licensed under the GPL. Does this count?

Other parts were covered by various Creative Commmons licenses, which sometimes forbid commercial use and usually require attribution for any use.

One theory is that this is classic "Fair Use": it's not really any different if a human read the code, and by doing so learned how to code, and then applied that knowledge to other things. The code snippets from any one source are usually quite small. Copyright law doesn't cover copying that is "Fair Use", which here means that the amount copied is small, and has negligible effect on the market for the original. But sometimes the code snippets seem a bit larger.

This Fair-Use issue with AI-generated text applies to non-code text as well; the New York Times is suing OpenAI because their back-issues database was used to train ChatGPT.

There is also an issue with open AI models. The models themselves are just large sets of neural-net numeric coefficients; do licenses cover these at all? In the case Stockfish v ChessBase, Stockfish made an open-source chess engine. Chessbase GmbH allegedly used it without making its added code public, contrary to the GPL. Stockfish sued, in Germany. The parties have now settled (https://stockfishchess.org/blog/2022/chessbase-stockfish-agreement). This kind of lawsuit is routine in the GPL world, but what makes this case interesting is that a lot of the "code" is machine-learning training models.

Clang

Why did Apple create the Clang compiler, and switch from gcc?

In 1989 NeXT computer apparently added support for Objective-C to gcc, and distributed the binaries but never released the source. But this isn't the whole story: Clang is a front-end that is part of the LLVM open-source compiler project, which is licensed under the Apache license.

Even that isn't the whole story: while at UIUC, Chris Lattner did major development work on the LLVM compiler collection, and wrote his PhD thesis about it. After he got his PhD, Apple hired him to turn LLVM from a research compiler to a robust production compiler. And the source is still open.

One issue is that, back when gcc was first developed, compilers were strictly black boxes, that converted your source code to object code. But this is no longer really true: most IDEs have extensive hooks into their compiler. This way they can show compiler error messages tied to line numbers, and show syntax errors before compilation (because the parser runs on your source as you type). Clang also supports code-analysis plugins; under the Apache license, such plugins can remain proprietary. Could the plugin issue be the real reason for Clang? Clang also has internal structural features that make it easier to tie late-compilation and even run-time issues back to a specific source location.


The Amazon Problem

The problem actually predates Amazon, or at least AWS. Way back in the last century, the so-called Application Service Provider (ASP) loophole was known in theory: an ASP could take GPL-covered software, modify it, and allow paying customers to use the modified version on the ASP's own hardware. This would not trigger the source-code-distribution requirement, because nothing has been "distributed". Today, we would say an ASP is a software-as-a-service (SaaS) provider or some other cloud provider. The idea is that AWS can take, say, MySQL, or MongoDB, modify it, not release the changes as binaries or source, but make the software available to all AWS customers on AWS nodes. The GPL doesn't prevent this, as that is only triggered by binary distribution, which means giving the software to someone else. And in fact Amazon does this all the time. There is certainly a theory that the cloud in general, and AWS in particular, has rendered the traditional GPL toothless. 

As an example of this, from stratechery.com/2019/aws-mongodb-and-the-economic-realities-of-open-source, consider the following story. In 2019, AWS announced on their blog

Today we are launching Amazon DocumentDB (with MongoDB compatibility), a fast, scalable, and highly available document database that is designed to be compatible with your existing MongoDB applications and tools. Amazon DocumentDB uses a purpose-built SSD-based storage layer, with 6x replication across 3 separate Availability Zones. The storage layer is distributed, fault-tolerant, and self-healing, giving you the the performance, scalability, and availability needed to run production-scale MongoDB workloads.

But in 2017 MongoDB had switched to the AGPL license. So DocumentDB is a rebuilt clone, perhaps based on an older GPL-licensed version of MongoDB. As a result, DocumentDB is only a clone of Mongo 3.6. Did MongoDB dodge a bullet by switching to the AGPL? Or will it ultimately not matter?

Elastic changed their license because they are really annoyed with Amazon: elastic.co/blog/why-license-change-AWS. Amazon since introduced their own version of ElasticSearch, called Amazon Elasticsearch, and later the OpenSearch project. Amazon had this to say about the license change:

Open source Elasticsearch and Kibana 7.10.2 reached their end of life on May 11th, 2022, and are no longer receiving active development, security patches, or bugfixes. Because of this, the Open Distro project is archived.

What Amazon means by "end of life" is that Amazon felt that ElasticSearch was no longer an Open-Source project once they switched to the dual Elastic License / Server-Side License. Not that the project was no longer being updated. See www.elastic.co/pricing/faq/licensing.

CockroachDB is a high-performance SQL database designed for transactions distributed among multiple servers. In 2019 they relicensed to address the Amazon problem, moving from Apache 2.0 to a form of the Business Source License (below):

Today, we’re adopting an extremely permissive version of the Business Source License (BSL). CockroachDB users can scale CockroachDB to any number of nodes. They can use CockroachDB or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license.

Take that, Amazon! But under their old Apache license, Amazon could have taken their code, renamed the product, and sold it. Nonetheless, they write

But our past outlook on the right business model relied on a crucial norm in the OSS world: that companies could build a business around a strong open source core product without a much larger technology platform company coming along and offering the same product as a service. That norm no longer holds.

Under the Apache license, another company could outright sell an updated version of the same product.

More at www.cockroachlabs.com/blog/oss-relicensing-cockroachdb.

The LXD project, recently moved to canonical.com/lxd, also changed their license, in December 2023. They describe themselves as a set of tools that "provides a unified user experience for managing system containers and virtual machines." They moved from the Apache license to the AGPL, which I interpret as pretty hard anti-Amazon move. New contributions will also require a Contributor License Agreement; some old contributed code is still covered by the Apache license. More at stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla.

LXD provides a unified user experience for managing system containers and virtual machines.

Immich has switched from the MIT license to AGPL (that is quite a jump). 

https://github.com/immich-app/immich/discussions/7023

Immich is a "self-hosted backup solution for photos and videos on mobile devices." That means it's used by individuals, not corporations.

Vaultwarden switched to AGPL3: www.reddit.com/r/selfhosted/comments/110t8ni/vaultwarden_relicenses_to_agplv3. Vaultwarden is a fork rewritten in Rust of Bitwarden, which is a password manager. The AGPL3 makes a lot of sense here: end users have a legitimate need to see the code.

There are a lot of open-source companies that have been exploring "anti-Amazon" licenses.

Kristian Köhntopp wrote an essay about open-source licensing titled A Revolution Devours Its Children, by which he meant that the originators of Open Source -- the GNU people -- were being pushed out. One reason for that is that many anti-Amazon licenses place some restrictions on the use of the software, which is not a very Open thing. Another reason is that GPL is quite a bit less popular than it used to be; many new projects choose a permissive (MIT/Apache/BSD-type) license. On the other hand, in some ways the anti-Amazon push has led to less interest in permissive licenses, and more interest in the GPL and its relatives.

The Affero GPL

In 2000, Henry Poole worked with rms to develop a response to the problem of online hosting companies modifying GPL software, and making it available to their customers but not distributing it. Poole started Affero, Inc as a web-services company in the following year; he wanted a GPL-like license that would require other ASPs modifying his code to distribute the source as well. The Affero GPL v1 (AGPLv1) was published in 2002. Along with the GPLv2 and GPLv3 were also issued corresponding licenses AGPLv2 and AGPLv3.

Here is the key clause (13) from the AGPLv3:

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

One ambiguity of the AGPL is just who is a "user". A company licensing your platform? A consultant working for that company? Or an arbitrary customer or user of that company? If the intent is to make the source code public, this doesn't really make a difference, but it can be confusing to bank customers, for example, to see a link at the bottom of the page for a source package. Perhaps a more serious problem is what happens if a company just wants to modify the software for its own use; here the issue of consultants and customers becomes an issue.

Note the comments above on the ban on AGPL software at Google.

Here's Remy van Elst's story of, well, "I enforced the AGPL on my code, here's how it went." A site copied his AGPL-licensed website. From a legal perspective, Elst's story has a successful ending: after his second email, "[f]our days later, they responded, stating that they had discussed internally and decided to take the site offline." But they never did provide their modified source code.

The Server-Side Public License

This was introduced by the MongoDB team in 2018. It is, in essence, the GPLv3 plus the following clause:

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.

The full license is at mongodb.com/licensing/server-side-public-license.

The situation was complicated by the fact that MongoDB can also be commercially licensed. So the more common reality for MongoDB modifiers is that they would be forced either to release their code or buy a commercial license. Releasing the code makes sense for companies that are modifying the MongoDB code, but some developers felt that the clause above applied even if you made a MongoDB-based app available to users. As a result, the SSPL has seen hard times, and MongoDB has backpedaled a bit.

The Commons Clause

This adds the following (from commonsclause.com):

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.

This is a very different approach to the same problem (the ASP-loophole problem): if you offer the software as a service, you cannot charge money for it. The Commons Clause, however, can be added to essentially any other license (eg the "permissive" licenses MIT, BSD and Apache), unlike the AGPL or the SSPL. If you want to sell the software, you can license that separately. If you want to sell the use of your software on a cloud platform, and don't want to get a commercial license, your other option is to relicense the software on open terms, and allow your customers to install it as an open-source product (or select it from a list of pre-installed options). Since your modified software is still free, you are not selling it.

Redis Labs was an early adopter of the Commons Clause. But, due to significant misunderstandings, they backed off, and replaced the Commons Clause with the Redis Source Available License. The core Redis is licensed with BSD, but add-on modules from Redis are license with RSAL. See redislabs.com/community/licenses. The basic RSAL feature is this:

Software protected by RSAL is designed to be used as part of an application. We want to help and encourage people to develop their own applications, but RSAL differentiates between a “database product” and all other applications. RSAL defines a database product as any of the following products or services: (a) databases, (b) caching engines, (c) stream processing engines, (d) search engines, (e) indexing engines or (f) ML/DL/AI serving engines.

If your application built with RSAL-protected software is NOT a database product, RSAL defines it as “your application,” and you can:

  1. Freely distribute the RSAL-protected software, as long as you include the following notice on any copy you distribute: “This software is subject to the terms of the Redis Source Available License Agreement.”
  2. Freely modify the RSAL-protected software, as long as your modification is covered by the RSAL license.
  3. Freely use the RSAL-protected software, as long as it is not part of a “database product” offered by a third party other than yourself or Redis Labs.

But if your application is a "database product", the RSAL license is not sufficient, and, basically, you have to pay Redis for a commercial license.

For a contrarian view, see drewdevault.com/2018/08/22/Commons-clause-will-destroy-open-source.html.

The Business Source License

This was developed by Michael Widenius of MariaDB. The Business Source License, or BSL, means that the source is available, but is proprietary for the time being. It becomes Open Source as of a specified date (known as the Change Date). While the software is in its proprietary phase, you get the source if you buy it, but that purchase comes with the usual restrictions on commercial software.

BSL incorporates at least two kinds of use restrictions into its proprietary-phase terms. First, free licenses may only allow you to use the software for testing, not for production use. Second, you might not be allowed to offer the software as a service at all; that is, Amazon couldn't make it available on AWS. Restrictions on the use of software are definitely not compatible with most understandings of Open Source.

The Functional Source License, FSL, is similar. The license reverts to the Apache or MIT license after, typically, two years. Here's the MIT version:

On the second anniversary of the date we make the Software available, the Software will become available under the MIT license. On that date, the Terms and Conditions above automatically terminate and the following terms become effective: [MIT license terms]

Before the Change Date, though, "competing uses" are forbidden:

A Competing Use means use of the Software in or for a commercial product or service that competes with the Software or any other product or service we offer using the Software as of the date we make the Software available.

That would mean that you can't fork the software, or make it available to others (like Amazon does). But you can get the source, make changes to it, and distribute those changes.

Dual Licensing

MySQL has a dual license option: you can accept the GPL, or you can get a proprietary license from Oracle. You have to pay for the latter, but then you don't have to share your code additions with others.

It turns out this strategy goes back to the original owners, MySQL AB; see business.html#mysql. The original MySQL business model was to give the product to everyone, to build market share and mind share, and then to sell the product (or an upgraded version of the product) to those who needed production-level reliability. Oracle has expanded on that, but not disproportionately.

One issue with dual licensing is that source-code contributors must sign contributor license agreements, or CLAs, that give the receiver the right to offer proprietary licenses. Usually (though not always) these CLAs do not require contributors to waive all rights; they only require that the contributor allow the project managers to sell proprietary licenses. The added code still becomes open source.

In January 2010, Richard Stallman wrote a blog post in which he comes to the conclusion that dual-licensing is not necessarily wrong, though the FSF does not license their software that way. Selling exceptions often seems like a reasonable way for companies to buy into an option to sell proprietary extensions.

However, in a January 2020 blog post by open-source activist Bradley Kuhn, Kuhn argues that dual licensing increasingly has a dark side. Commercial users of the FOSS license often feel under considerable pressure to purchase the proprietary license. Sometimes this is due to longstanding business-world anxiety about open source, and sometimes there are allegations of saber-rattling (what Kuhn calls "captious [finding petty faults] interpretations of the copyleft license") on the part of the project owner.

Kuhn is most suspicious of the Affero GPL as used to license MongoDB. The AGPL is less well understood, and there is much less legal precedent for interpreting it than for the primary GPL. And MongoDB may have suggested to some corporate users that they were violating the license terms. But he goes on to say

In theory, proprietary relicensors would only offer the proprietary license by popular demand to those who had some specific reason for wanting to proprietarize the codebase — a process that has been called “selling exceptions”. In practice, however, every company I'm aware of that sought to engage in “selling exceptions” eventually found a more aggressive and lucrative tack.

Kuhn is in favor of adding a copyleft license clause that basically says "if you offer a proprietary license, then the copyleft license switches to a BSD/MIT license", meaning the project owner loses control.

The GNU license FAQ says, of dual-licensing, that "to release a nonfree program is always ethically tainted", but that, legally, dual licensing does not violate the GPL.

On the other hand, here's a blog post by George Hosu, who writes "the 'ethically tainted' doesn't resonate with me. I think this licensing model should be encouraged." Ultimately, the rationale is that this gives Open Source another revenue model. Even better, this time it's actually realistic.

Ethical Licenses

And then there are the weird licenses. As Bruce Perens (co-founder of the Open Source Initiative, which blesses open-source licenses) writes in October 2019, once upon a time software freedom meant freedom for everyone, including those with very different perspectives. In that era, banning, say, authoritarian governments from using open source was considered a bad idea.

That was then. Today, here are three licenses cited by Perens with social strings attached:

The Vaccine License is strange. Here is the central requirement:

The Vaccine License is a software license that requires that users vaccinate their children, and themselves, and that user businesses make a similar requirement of their employees, to the greatest extent legally possible. The required vaccinations are those recommended by the user’s national administration, for example the United States Center for Disease Control. There is an exception for those who, for medical reasons, should not receive a vaccine.

Keep in mind that this predates Covid-19! The US CDC vaccination recommendations for those aged 19-26 were, in those days:

One issue Perens addresses is what happens if, say, the US government uses the software. You can't sue the US government to enforce the terms of the license; all you can sue for is pecuniary damages. Figuring out the dollar value of using open-source software without having agreed to the license terms is tricky.

Then came the Cryptographic Autonomy License. In late 2019 Perens quit the OSI over that one. Section 4.2 is entitled "Maintain User Autonomy", and basically says you may not withhold users from their data, eg by encrypting it. See also lwn.net/Articles/797065.

Another ethical license is the Katharos license: https://github.com/katharostech/katharos-license

Katharos is the Greek word for "pure" and, correspondingly, the purpose of the Katharos license is to prevent the licensed work from being used to promote destructive activities or to produce other impure or destructive works. ...

The definition of what is "good" can be considered highly subjective.... The source of "truth" for the Katharos License, and where the definition of what is "good" and "pure", come from the Word of God, The Holy Bible.

Here's a draft of the actual license: github.com/katharostech/katharos-license/blob/master/LICENSE_v0.2.0_draft.md.

There is a serious issue here with enforceability: US courts generally refuse to interpret the Bible.

One more license

I ran into this in an actual project. Here's the website for the license itself, though: www.wtfpl.net.

Does it matter that there is no disclaimer-of-liability clause?

Regulation

While regulation of open-source software is only dimly related to licensing, many licenses do contain disclaimers of liability. Sometimes governments add other forms of regulation.

For example, the EU has proposed the Cyber Resilience Act: https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act. The EU wants to make all commercial software used in the EU subject to mandatory security-compliance rules. This is an impossible burden for most smaller open-source projects.

See en.wikipedia.org/wiki/Cyber_Resilience_Act.