Thinking About Open Source, Part Two

In the first part of this Open Source blog series, I talked about the core meaning of what it is to be open source software. That post covered the Open Source Initiative and its definition of the requirement for certified Open Source licenses.

This time—after an admittedly lengthy delay—I am going to briefly consider the differences between the primary classifications of licenese: copyleft and permissive. While every license is unique in its own way, these two broad categories tell you a great deal about your rights and obligations as a consumer. In particular, knowing the classification alone often will be enough to determine whether incoprorating a piece of open source software into your project is acceptable.

OPEN SOURCE SERIES

Part 1: The Open Source Definition
Part 2: Copyleft vs. Permissive Licenses

Copyleft & Copyright

Many people learning about open source ideas are probably hearing the term "copyleft" for the first time. Shortly after thinking, "That's a funny-sounding term," their next thought is usually an assumption that it represents the opposite of a copyright.

The two terms are somewhat related. Certainly copyleft, as a concept, arose from the principles of copyright and intellectual property. However, I would not necessarily say that they are opposites. In a future post, I will talk more about copyright, trademarks, and patents. For now, simply be aware that a copyright is an assertion of ownership over authorship of works. When you hold the copyright over some intellectual property—a novel, a painting, or your code—you own the authorship rights. Nobody else can legally use or reproduce the work without your express permission.

Hence the purpose of Open Source licenses in the first place. They are copyright licenses, granting the recipient permission to use, modify, and reproduce the code produced by the original author. Without that license, even if you have the copyrighted code in hand, you have no right to use or distribute it, any more than you can rebroadcast, reproduce, or use the pictures or accounts of a baseball game without the express written consent of Major League Baseball.

Copyleft as a Condition of Use

Open Source licenses generally provide a good deal of latitude to the downstream user of code, but they rarely provide carte blanche permission for you to do whatsoever you please. Some (e.g., the MIT license) come close. Most, however, place conditions or requirements on the user of the software to satisfy the terms of the license.

The so-called copyleft provisions constitute one such set of conditions. The most prominent of the copyleft licenses is the GNU General Public License (GPL), along with all of its associated colors, flavors, and versions. They are still Open Source under the OSI's definition. You may take GPL-licensed software and incorporate, link, modify, and redistribute it with your own projects.

But there is a catch. Any redistribution of the GPL-covered code, in its original form or as part of a derivative work, must be released under the same license, or a compatible open license. In other words, among other things, you cannot take GPL-licensed code and roll it into a closed-code, proprietary solution.

1
2
3
4
5
6
7
8
9
10
11
Except from the GNU General Public License, Version 3  
Copyright © 2007 Free Software Foundation, Inc.

Section 5. Conveying Modified Source Versions.

You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code...provided that
you also meet all of these conditions:  
...  
c) You must license the entire work, as a whole, under this
License to anyone who comes into a possession of a copy.

That is copyleft.

Inherently, this is neither a good nor a bad thing. It is simply a quality of the category of Open Source license. These are licenses where the driving purpose is to ensure that the software remains open and free (Speech, not Beer). In the right scenarios, this is quite valuable. In others (e.g., use for commercial products in the enterprise setting), it can be extremely problematic.

Even among the different versions of copyleft licenses, there are subtle variances. Some are less draconian than others. However, across the board, the same general principles hold.

Permissive == !Copyleft

Effectively, a permissive license is any license that does not contain the copyleft restrictions seen in licenses such as the GPL. There are many examples, which contain a wide array of provisions. Among these are the MIT, BSD, and Apache licenses.

At their simplest, a permissive copyright license may grant nearly universal and unrestricted rights for a downstream user to use, modify, redistribte, and otherwise consume the covered code as the downstream user sees fit. Take, for example, the "Expat" version of the MIT License—currently the most popular software license in common circulation—which reads:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Copyright (c) <year> <copyright holders>

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.

That's it. There are no express attribution or advertising requirements. There is nothing covering patents or other (non-copyright) forms of intellectual property. Effectively, this license grants the consumer broad rights to incorporate, improve, and distribute the licensed software freely.

And, importantly, there is no requirement to redistribute under the same license, or even to keep it open in downstream use. This is what distinguishes a traditional permissive license from a copyleft.

Permissive licenses need not be as simple and all-encompassing as the MIT License. Others, such as the Apache License, Version 2.0 or the Mozilla Public License, contain much more "legalese," warranting closer review. These two, in particular, provide a license not only for copyright material, but also for patents or patentable content. (NB: the patent protection comes with strings attached; more on that in a future post!)

So What Does This Mean for Me?

The impact of open source software on your own development projects depends upon the nature of what you are doing. And it depends upon your goals.

For authors looking to release their own free or open software, a major consideration are your hopes and dreams for the future of the project. Do you want to ensure that, no matter what, your software remains free and subject to copyleft-like restrictions? If so, the GPL (or one of its variants) may be for you. Prefer to offer maximum flexibility and, potentially, encourage a higher rate of community contribution to the project? Then some kind of permissive license might be more appropriate.

Many organizations dual-license their software. Consumers may use the software under a no-cost open license, which is subject to copyleft restritions. Alternatively, those same consumers may pay a fee for a commercial license, allowing the licensee to incorporate and release proprietary (i.e., closed) software derived from the open source component. This approach has gained in popularity as a means of supporting free software models within a business or commercial environment.

If you are working in an enterprise environment, or if you are hoping to implement proprietary software, then you absolutely must be aware of the copyleft distinction. It doesn't matter whether you are cloning an open component from its git repository, grabbing a package from npm, or "checking the box" in a package manager like nuget. The key is always to check the license and make educated decisions about whether a given piece of software can be incorporated in your project without compromising your goals.

In a future post in this series, I will give my basic suggestions for how development teams—particularly in the enterprise—can implement sensible policies to manage the incorporation of open source to minimize risk. Don't forget to write me if there is a specific topic you want to see covered.

Disclaimer

If you have seen my talks in the past, you will have heard me say this countless times. But as always, remember, "I may be a lawyer, but I am not your lawyer." Arana Software LLC is not a law firm and does not engage, in any context or jurisdiction, in the practice of law. These blog posts are for infomational purposes only and should never be construed as legal advice. If you think you, your company, or your work requires specific advice with respect to any particular issue or problem, you should contact (or retain) an attorney who represents you and understands your needs. My ramblings on this blog are nothing more than a guide for some things you may wish to discuss with your own counsel.