You have an idea for software that can make a cumbersome task easier. Perhaps it's an entirely new JavaScript framework or a .NET component delivered via package management systems such as NuGet or MyGet. To implement this solution, you've chosen to go the Open Source route, meaning that you intend there to be a community that will both use the software and make contributions to your project.

You know and understand the technical issues. How do you encourage uptake, especially from commercial entities? How do you encourage contributions? The legal issues that address these questions are as important as the software's functionality. This article demystifies the legal issues with licensing so that you can make the right choice for your project.

DISCLAIMER: This and future columns should not be construed as specific legal advice. Although I'm a lawyer, I'm not your lawyer. The column presented here is for informational purposes only. Whenever you're are seeking legal advice, your best course of action is to always seek advice from an experienced attorney licensed in your jurisdiction.

What's a License?

A license is legal permission to do something. In everyday life, the most common license is a driver's license. A driver's license grants permission, subject to specific rules and regulations to operate a motor vehicle. Another common license is a ticket to a public event or venue such as a sporting event, music concert, a museum, or the zoo. These other licenses are also subject to specific rules and regulations. In the event that you fail to follow those stated rules and regulations, the license can be revoked.

Often, licenses are confused with being a type of contract. A contract is a wholly different legal concept. A contract is a bargained-for exchange with some consideration. That consideration may be a promise or an action. With a license, there is no bargained for exchange. Rather, you typically need to accept the conditions of such license as is and go from there. Essentially, it's a take-it-or-leave-it scenario. You typically don't get to negotiate specific license terms. That's not to say that negotiating never happens and also happens that a license can precede a contract.

A license and a contract are wholly different legal concepts.

A common license is a software license. A software license is a permission granting use of software owned by another entity. The ownership interest in intellectual property terminology is known as a copyright.

Copyright vests exclusive rights to use, copy, and distribute some tangible and original creative work. In the previous article in this series, I discussed how these exclusive rights are not always absolute. There are times when a use is deemed to be Fair Use such that there is no copyright infringement. Most of the time, Fair Use is in the context of music, prose, and visual arts. In the software context, fair use is less common. That's not to say that fair use with software doesn't exist. For more on fair use and software, please refer to the case Sega Enterprises, Ltd. v. Accolade, Inc. 977 F.2d. 1510 (1992).

With respect to software licenses, there are two flavors: closed source or what is often referred to as an End-User License Agreement (EULA), and Open Source Software (OSS) licenses. Now that the basics of what licenses are covered, , let's tackle what open source is and what differentiates it from closed source before getting into picking the right OSS License.

What is Open Source?

In the context of OSS licensing, the best guidance to consult on whether your project qualifies as open source is the Open Source Initiative (OSI) and specifically, its definition of open source: http://opensource.org/osd. Put another way, if you distribute your software subject to the requirements, your software is deemed to be open source. This implies that closed source code can be converted to open source, provided that the open source requirements are met. As this article was being written, Microsoft announced that its WorkFlow Foundations (WFF) was made open source

The requirements (abbreviated) for distributing your software as open source are as follows:

The OSI has an additional link that provides an annotated explanation of these ten requirements: http://opensource.org/osd-annotated.

One thing you may have noticed in these factors is that there is no mention of other aspects of Intellectual Property (i.e., patents and trademarks). This is where picking the right license becomes very important because different constituencies place different values on those items. In some cases, patent rights, whether potential or existing, may matter. In other cases, patents may not be an issue at all. The key is in finding the right license that addresses those concerns.

Choosing an OSS License

Now that you have a good understanding of what a license is and what the requirements for OSS are, the next question to tackle is which type is the best license for your project. Fortunately, there is a great site from GitHub called http://www.choosealicense.com. Before this site offered this service, you had to choose from dozens of license options. The one area that choosealicense.com doesn't address is the notion of a Contributor License Agreement (CLA), which I will address later in this article.

The choosealicense.com site presents three simple yet complete considerations:

  • If your primary concern is to use a permissive license so that people can do as much or as little with your code as they want, use the MIT License (http://opensource.org/licenses/MIT). The term permissive is in bold because it's an important term with OSS licensing and is a term used to differentiate copy-left licenses such as the General Public License (GPL). If you're looking for something very simple with the goal of getting your code out there and leaving its fate in the hands of others, the MIT license is a great choice.
  • If your primary concern is that all improvements are shared with others, the General Public License (GPL) is a good choice. GPL is known as a strong copy-left license. While successful businesses can be built around GPL code, commercial enterprises that look to adopt OSS as part of their supporting technology infrastructure tend to steer clear of GPL code.
  • If your primary concern is patents and commercial uptake, your best choice is the Apache v2 License. The Apache license, unlike other licenses, has two important components. First, the license addresses patents in the form of a patent grant to users of the project as well as contributors. Second, in the event that there isn't a separate Contributor License Agreement (CLA), the Apache license has a de-facto CLA in the license.

If your primary concern is patents and commercial uptake, your best choice is the Apache v2 License.

In the event that you have work not based on software code but rather prose or visual art, an OSS license isn't the correct choice. Rather, the correct choice is something like Creative Commons (http://creativecommons.org). Where your software code may be licensed under Apache, your documentation and other collateral could be licensed under Creative Commons.

Contributor License Agreements (CLAs)

In addition to selecting a licensing scheme, you also want to make sure that a Contributor License Agreement covers any contributions to your project.

Companies like Microsoft require a signed CLA before they take contributions. In other cases, the project can use a license like the Apache v2's license that has a CLA baked in or one that's included in the repository itself, with terms and conditions around contributions. If you're using the Apache v2 license, a separate CLA isn't required. The same is true with a strong copy-left license like the GPL. If, however, you're using a permissive license like the MIT license that doesn't speak to patents, a CLA is a good idea. An example to follow is NodeJS. NodeJS is released under the MIT license. In addition to the MIT license, the NodeJS Project also has a CLA located here: http://nodejs.org/cla.org. (Editor's note: Link no longer works. NodeJS licensing is here: https://raw.githubusercontent.com/nodejs/node/master/LICENSE but there is no mention of a CLA license.)

Dual Licensing

It's perfectly acceptable to have multiple licenses associated with a project. Often, a project may employ an OSI-approved license as well as propriety commercial EULA. A good example of dual licensing is the popular MySQL Database: http://www.mysql.com/about/legal/licensing/oem/.

Perhaps you have a product that isn't open source and you'd like to distribute a database engine with your product. As part of that distribution, you may have some modifications to MySQL. MySQL's GPL license requires you to make those improvements available to the world. Most likely, this wouldn't be acceptable for your project. The solution to the problem is to acquire MySQL under a commercial license.

In the News

There's some interesting activity between a company called Global Music Rights (GMR) (globalmusicrights.com) and Google's YouTube. In a nutshell, GMR has demanded that YouTube remove all infringing material of GMR's clients. GMR's clients range from the estate of John Lennon to current superstar Pharrell Williams. The interesting part of GMR's demands is the lack of specificity as to which material was deemed to be infringing. Rather, the demand is for Google to use its technology to effectively sniff out the infringing material via the digital footprints of such work.

Typically, a rights holder is required to be specific about the material it finds objectionable. Recently, legislation known as the Stop Online Piracy Act (SOPA) was contemplated. This was extremely controversial legislation due to the lack of due process that would be afforded to website owners. In other words, the mere allegation from a rights holder would be enough to effectively shut down a site. Despite the fact that the legislation failed, it hasn't stopped GMR from making demands as if SOPA had passed. The irony is that GMR may have a good case because often, if you upload a video to YouTube that has copyrighted material, quite often, YouTube won't publish that material. Clearly, YouTube not only has the ability to detect such material, but it has used that ability to prevent publication. That may be YouTube's undoing. It could be difficult for YouTube to argue on one hand that it's too difficult to search through its material and on the other hand, selectively use that same technology to not publish videos.

The key take away is that even though SOPA didn't pass, rights holders will continue to be more vigilant in enforcing their rights using the same arguments in court that SOPA contemplated through legislation. In my opinion, there's nothing wrong with legitimate rights owners asking for a court order demanding that Google do what Google is already doing voluntarily. Of course, to the extent that Google has license agreements with authors, the issue is moot. The question is how much material is on Google that's copyright infringement already and how much advertising revenue is earned from the views of such material.