Open Software Licensing Primer

This is a short, practical guide to open software licensing. If you deal with software on the job and wonder how open software licensing works, why you can use some kinds and not others, or what you have to do to get away with it, this guide’s for you. Feedback is welcome at feedback@blueoakcouncil.org.

Spoiler Alert: If your company or contract client has an open software policy, do what that policy says. After reading through this guide, you will probably feel better equipped to understand, talk about, and perhaps improve that policy.

Either way, know going in that this guide abstracts away some details, exceptions, and edge cases to make the whole package more accessible. It also takes the topic from just the point of view of United States law. As with everything, the Internet offers tons more information—some good, some bad. We hope this introduction will help you learn to tell the difference.

Do not extrapolate from the breezy generalizations you find here to specific, business-critical decisions without further research. In other words, don’t make this guide the last thing you read before taking a big decision. Educate yourself further, look at what others have done and got away with, and if at all possible, talk to the experts—specialist lawyers and compliance pros—available to your company. That should be easier once you’ve read this guide.

In Brief

1. Open software licenses override legal defaults to make using, changing, and giving away software safe and easy.

2. To enjoy that convenience as a user, you have to follow a few license requirements, like preserving notes about copyright ownership and license terms.

3. Some open licenses have more requirements, often called “copyleft”. These require you to give users access to code that builds on the original, under a similar license.

4. Some open licenses take permission away from those who sue other users or contributors under patents.

5. Contributor license agreements, assignments, and developer certificates create records showing that all those who have intellectual property in a project override the legal defaults to make the project open.

Legal Defaults

Software doesn’t start out open. People who own rights in closed software have to turn it into open software with legal tools called open licenses. Open licenses override legal defaults that fit the traditional, proprietary model of software developed behind closed doors and licensed to customers for a fee under negotiated contracts. Open licenses replace those defaults with written terms that make publishing, distributing, and using open software relatively simple and low-risk.

When open licenses work correctly, users and distributors, like your company, needn’t worry about the proprietary-style legal defaults. But you can’t understand how open licenses work, or decide whether a license overrides all the defaults your company should worry about, if you don’t understand the defaults in the first place.

Defaults and Overrides

Not all open licenses override every default listed here. Some open licenses do a better job of overriding specific defaults than others. Some open licenses address more legal rules, either to override defaults or make clarifications.

Intellectual Property Law

Intellectual property laws give monopolies over many kinds of techniques, ideas, symbols, and products of thinking work. The strongest core idea behind these laws—the primary policy behind them—is to reward those risking and investing with the right to control the benefits of their results, so they can charge others to use them, earning a just reward.

Using intellectual property without permission is infringement. The law allows intellectual property owners to sue infringers to get court orders to stop infringement—injunctions—pay money to the owners—damages—or both. Owners give permission, as licenses, to do what would otherwise count as infringement. Owners can also sell or assign intellectual property to others, making them the new owners.

The key intellectual property laws for open software are copyright and patent laws.

Copyright Law

Copyright law rewards authors of creative works with rights to stop others from making copies of their work or using it as a starting point for new work. The archetype of a copyright owner is the writer who sells a publisher exclusive license to print and sell their novel as a book.

If code, documentation, configuration, or data—almost anything you can store in files—is even a tiny bit creative, copyright applies automatically, from the moment it’s typed out. There’s no requirement to file with the government or pay any fees, at least until you want to sue for infringement. Since copyright damages for even small infringement can be very large, and making sure a piece of work utterly lacks legal “creativity” is hard and takes legal expertise, most companies and projects treat every bit of software and documentation as though someone owns copyright in it.

Lawyers read nearly all common open licenses to grant everyone a copyright license. By default, nobody has a license, and the copyright owner can sue them if they infringe. Giving everyone a license—a public license—overrides the default, so everyone gets a license.

Professionally drafted license agreements make clear when a license is a copyright license by using the word “copyright”. For example, the copyright license in section 2 of the Apache License, Version 2.0 reads:

Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a…copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

This style is pretty modern by lawyer standards, and consistent with what most professional licensing lawyers expect in proprietary software licenses. But many open licenses use a less structured style. These licenses give “permission” or say that users “may” do things with the software that would otherwise infringe copyright, without saying “copyright”. For example, the first paragraph of The MIT License begins:

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…

Without this language, copying, modifying, publishing, or distributing would infringe any copyrighted work in the software. Using and selling, on the other hand, might infringe patents.

Patent

Patent law rewards inventors who publish their findings through the government with twenty-year rights to stop others from making, using, selling, or importing goods and services that implement them. The archetype of a patent owner invents a better mousetrap in their garage, secures a patent, sues a company that makes their trap without permission, and settles the lawsuit for a big check and a royalty.

Teaching a computer to do something useful, instead of a person or some other machine, does not, in itself, entitle the programmer to a patent. But new inventions that happen to be implemented in software, and new inventions in the art of making software, can be patented. Algorithms, data structures, protocols, and other methods of achieving useful results with software have all been covered by patents. It used to be easier to patent ideas in software, and the government issued a lot of bad patents. It’s harder now, but still possible.

Unlike copyright, patents don’t happen automatically. To receive a patent, an inventor has to apply to the United States Patent and Trademark Office. The process is technical, complex, and takes years, even for applications the office ultimately denies. It’s possible to apply for and receive a patent without professional help, but well practiced experts—patent attorneys and patent agents registered with the Patent Office—speak the language, know the rules, and markedly increase chances of approval for a patent that’s worded for strength and strategic value. Good professional time and government fees during a long application process often add up to many thousands of dollars, in the ballpark of a new luxury car.

A patent lawsuit often costs even more than getting a patent in the first place, on the order of a new supercar. This is often just as true for the side being sued as for the side with the patent. Many companies simply can’t afford to put up a patent fight. Many that can put a lot of people and process on avoiding, slipping out of, and winning as many suits as they can. Some companies exist solely to purchase patents and abuse economics of scale, suing as many companies as possible and scaring them into pricey license agreements to settle court fights they can’t afford even to win.

Lawyers make sure that commercial software agreements make clear if and when they grant patent licenses, by saying the word “patent” and listing the specific patents licensed whenever possible. Section 3 of the Apache License, Version 2.0 follows the prevailing legal style:

Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a…patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work…

Again, many open licenses use shorter, more general grants of permission. Many of these licenses are so short and general that lawyers aren’t sure whether they grant patent licenses at all, or what those licenses cover. For example, the preamble of The Two-Clause BSD License reads:

Redistribution and use in source and binary forms, with or without modification, are permitted…

Permission to “use” software covered by a patent might be a license under that patent. It’s not clear.

Ideally, drafters of open licenses would like to completely override the default rules that allow patent owners to sue users and distributors of open software. The fact that patenting requires application and approval means there may not be any relevant patents to worry about.

Unfortunately, a key legal difference makes a complete override impossible. Independent reinvention of patented technology doesn’t stop an inventor with a patent from suing. If Ivan patents a new search algorithm and six months later Carol independently comes up with the same approach and uses it in code for a database, Ivan can sue Carol and users of Carol’s software. This can happen even if Carol uses an open license with a very clear patent license, and worse, even if Carol came up with the algorithm on her own, knowing nothing of Ivan or his patent. Ivan owns the relevant patent. It isn’t Carol’s to give away—to license for free on open terms.

That’s the opposite of how copyright works. If Ivan writes a limerick and Carol just so happens to come up with the same limerick later, Ivan can’t sue Carol for publishing “his” limerick unless he can prove she copied him, rather than wrote it herself. Because copyright applies to code, a copyright license that properly covers all the material in a project code gets rid of copyright risk for users. But a patent works more like a category or pattern—it does or does not cover specific code. If some piece of code implements, or embodies, a patented invention, the patent owner can sue.

Since the early 2000s, drafters of new open software licenses have tried to address this problem with patent-termination clauses. Suing users, distributors, or contributors under a patent triggers these clauses, which take back the patent owner’s license for the software.

Lawyers often use the last sentence of section 3 of the Apache License, Version 2.0 as the canonical example of open software patent termination:

If You institute patent litigation…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.

Losing their license puts the patent owner at risk of infringement lawsuits if they use or distribute the software. But those with relevant patents may or may not use or distribute the software at all. For patent owners that don’t, including companies that only exist to sue for patent infringement, the termination clause doesn’t have teeth. They don’t need a license for the software to begin with, so they can’t be countersued for infringement.

Whenever patents and open software cross, lawyers look very carefully at the language of the relevant patent licenses and any patent-termination clauses. Companies may also look into whether contributors to the project are likely to own or apply for patents.

Lack of clear patent language in a license for software that implements old, patent-free inventions, or software published by contributors who aren’t likely to own or apply for patents, may not pose any risk. Conversely, even very clear, predictable patent language may not be enough for software that’s likely covered by patents belonging to a competitor or well-known patent bully.

Companies considering whether or not to contribute code to an open project also scrutinize patent terms, to make sure they understand what patents they’d be licensing and how. This often involves lawyers with roles and responsibilities that create even less familiarity and friendliness to open software than usual.

Patents make software law hard, and the anti-defaults of open software make it even harder. If you find yourself staring down the double-barreled shotgun of open software patent law, make no fast moves and get the best advice you can. Not just from lawyers. Talk to engineers who know your company and what’s going on in your industry.

Contract Law

Contract laws let private people and organizations use the public courts to enforce private agreements, with rules for interpreting terms and deciding who bears what risk when the agreement doesn’t say. The prime directive of contract laws is to hold all sides accountable for the promises they made.

Warranties

Warranties law is a part of contract law. Warranties are promises about products and services covered by contracts. The archetypal warranty gives the purchaser of a new television the right to a repair, replacement, or refund if it quits working a week after purchase, due to shoddy materials or design.

Many warranties are written out, but the law implies some by default, as well. An implied warranty of merchantability says, essentially, that goods licensed or sold by someone in the business of selling that kind of thing will be up to usual standards, and not shoddy knock-offs. A default warranty of fitness for a particular purpose says that goods an industry player sells to a customer to meet a specific need will do the job. A default warranty of noninfringement says that using what you’re buying as expected won’t immediately land you in an infringement lawsuit. These defaults are read into a contract, or implied, unless explicit terms clearly get rid of, or disclaim, them.

Implied warranties from sales-contracts law may or may not apply to terms for open software, but in some circumstances, they clearly will. The implied warranties would then translate into promises about the quality and functionality of the software. Promises the one giving the software away could get sued for failing to keep.

Open licenses disclaim all warranties, among them implied warranties. Typically the words that do this appear in ALL CAPS. Their structure is twofold, layering general disclaimer language on top of specific disclaimers of merchantability and fitness, for redundancy.

Contract law expects contracts to look like sales, and for those selling to get something in return. Owners of software may indeed get some reward for opening their projects, like patches or interest in other products or services they otherwise wouldn’t. But they don’t receive payment, as they would for proprietary software. Without payment coming in, they don’t want to risk paying out on warranties. Even if the warranties arguably make sense.

Liability

The law gives each side of a contract the right to sue the other side for money, called damages, when they fail to hold up their end of a bargain.

Courts usually limit damages to those they think the side at fault could have foreseen when they made their deal. If a software company licenses a badly flawed backup tool that corrupts a customer’s financial data, the customer might collect the costs of digitizing its records again. If the tool wrecks the control system for the customer’s top secret satellite project, crashing it into a chicken farm, the customer probably can’t get the cost of launching a new satellite, of replacing the chickens, or of the chicken farmer’s anguished grief.

In order to get damages, you have to bring a lawsuit and get the court to order the other side to pay. Or you can credibly threaten to bring a lawsuit and convince the other side to agree to pay, or settle, to make your lawsuit go away. Bringing a lawsuit means filing a document that makes claims—references to laws you say apply to your situation and entitle you to protection from the court or compensation from someone responsible. Those laws might be the contract laws that say a party has to do what it promised, claims for torts like physical harm, property damage, or fraud, and so on.

Commercial software licenses usually set a limit on the total amount of money the one selling the software can owe as damages. Often that limit on liability is the same as, or a multiple of, what the customer pays for the software. If the limit is high, the seller might buy insurance to offset their risk.

Open software licenses almost all limit damages, too—to zero, the same as contributors get paid. They also exclude all the kinds of legal claims—contract, tort, whatever. Liability under a license agreement makes a lot more sense when the one giving the license gets paid in return. Giving software away for free and keeping the risk of liability would not make sense for many contributors, especially individuals.

Formation

The law requires two sides to take some kind of intentional action to create an enforceable contract. Lawyers usually talk about this process in terms of one side offering terms and the other side accepting that offer.

If Able offers Bob terms for an agreement, and Bob accepts, Able and Bob have a contract. If they intended some of their terms to benefit Candice, as well, Candice may be able enforce the parts of the Able-and-Bob deal that are supposed to benefit her. But Able and Bob can’t make enforceable promises on behalf of Candice. If Able wants an enforceable promise from Candice, he needs to make a contract with Candice.

If Bob and Candice both contributed to an open software project, Able will want licenses from both of them to know he’s free to use all the code in that project. Lawyers disagree about whether open licenses are contracts, technically speaking. But they agree that users need everyone with intellectual property in the project to override the legal defaults to make it open. Everyone with copyright in code in the project should give a copyright license. Ideally, everyone with a patent covering the software should give a patent license, too.

Open software projects try to achieve this in different ways. Some projects require each contributor to license their contributions to the public under an open license, such as MIT or the GPL. Some of these projects also use additional terms, like the Developers Certificate of Origin, to help shore up evidence that everyone licenses appropriately. Other projects use special-purpose contributor agreements to license intellectual property in their contributions. Often these agreements involve a single person or organization, the project steward, often a company or foundation, which licenses all the rights in the project to the public in turn. Some project stewards, like the Free Software Foundation, ask contributors to go further, assigning, or transferring ownership of, their rights in contributions, rather than just licensing them. The important point, from a user’s point of view, is that each contributor creates a written record of overriding the proprietary software defaults that the user can find and point to later, if they’re sued.

Terms and processes for contribution licensing tend to pay special attention to who owns the intellectual property in code that developers write. In typical employment and contractor relationships, copyrights and patent rights in job-related work belong to employers and clients, not the coders. That means the employers or clients, not the coders, need to give the licenses. Because of this, careful open software foundations usually require contributor agreements or assignments from both individuals and companies, to make sure they’re no covered no matter who the intellectual property belongs to. They don’t want to take in and distribute code under terms with an individual when it’s really their company’s agreement they need.

In the proprietary software world, nearly all software comes with a warranty that the seller has all the rights they need to license the customer. With very rare exception, open licenses don’t. That means it’s up to users and distributors, the consumers of open software, to do their own research and come to their own conclusions about risk. As a result, a company may need to look past what open license a project uses to who has contributed and how the project managed rights in their contributions. Again, the key is whether users can find written records that show everyone relevant overrode the legal defaults.

Specifics matter. If the software implements patented inventions, uses an open license with clear patent permission, received contributor license agreements from patent holding contributors—all good news—but used a form contributor license agreement with no patent language, then using that software might put a company at patent risk. If programmers contributed code they wrote at work, but signed only individual contributor license agreements, no one may have stopped to ask whether the rights were theirs to license. The public records a software project keeps, like revision control data, often matter just as much as the notice of license terms in deciding whether a project is safe to use.

Real-World Risk

Few private companies can match the legal and process rigor of the large, enterprise-focused open software foundations, even for proprietary software they sell for lots of money. At the same time, it’s easy to meet an open software contributor who believes all code pushed to public repositories automatically becomes open and does nothing in particular to manage rights in contributions to their own projects. Very, very few open software projects do licensing completely right. But plenty of big, important companies—the best targets for lawsuits—use lots of open software, under a variety of licenses.

Enforcement of license rules remains relatively lax in some areas of software, like web application programming. In other areas, like embedded systems, more developers understand the issue and manage it proactively. Some foundations strongly favor enforcing licenses only to gain compliance—getting license notices fixed, getting source code released, getting staff trained to avoid more violations—rather than to sue for money. On the other hand, companies relying on rules of open licenses for their business models have taken violators to court and got settlements. Outside the courts, naming-and-shaming violators increasingly happens in the open, on social media, where it can take an immediate, serious toll on reputation. Especially for companies that compete to recruit computer programmers who identify with open software.

Most lawsuits begin in private, with demand letters, rather than in public, with filings in court. But overall, lawsuits in open software seem rare. For individuals and many small companies, there would be little point in suing anyway, since there is no significant money to be won. Conversely, community goodwill and reputation remain very valuable for users and creators of open software. More valuable, in many cases, than insisting on their legal rights.

This general picture hides a lot of project- and case-specific variation. It’s not a safe rule to say that open license rules don’t matter in practice. Nor does it make sense to pretend that every violation gets punished under the strictest possible interpretation. We have to look through the general category of open software to the specific projects, companies, institutions, and people involved in the open software we want to use or contribute to.

Implementations

The phrase “open source” was coined in the late 1990s to rebrand what had been called “free software” for a stronger pitch to the business world. A string of headline-grabbing conversion stories—Netscape’s release of their Mozilla web browser in 1998, a handful of successful IPOs in 1999, IBM’s coming out for the Linux kernel that same year—cemented open source as a business phenom. New interest in open software led to a flurry of new open licenses, often specific to a single project or company. But over time, the open software community standardized on a few licenses reused for many projects. Reusing a well known license meant one less license for potential users to read and understand.

The popular licenses can be grouped into a few classes.

Permissive Licenses

Permissive licenses come with minimal rules. They almost always require attribution: including a copy of the copyright notice and license terms that came with the software with all new copies of the software. They may also impose other obligations, often annoying but procedural chores like listing any changes made to an official version of the software. Conditions satisfied, all are free to use permissively licensed open software, redistribute it, make changes, and combine with other, even proprietary software in new programs and products.

The MIT-style family of licenses, including The MIT License and ISC License, are permissive licenses, popular in a variety of software communities. Much the same is true of the BSD family of licenses, in two- and three-clause variants. The Artistic licenses, versions 1.0 and 2.0, hail from the Perl programming language community, but apply to a few important projects in other areas, as well. The Apache License, Version 2.0 applies to many Apache Foundation and other projects. The more recent Blue Oak Model License set a higher bar for approachable, professional drafting in permissive open licensing.

Permissively licensed open software is often the easiest for companies to approve for use as published, for reuse with changes, and for inclusion in binary or source-obfuscated programs. It’s usually legally straightforward to incorporate permissively licensed open software into other software, even proprietary software, and to combine it with other open software. With older permissive licenses, like MIT- or BSD-style licenses, there may be stronger concerns about patent risk, since it isn’t clear if or how those licenses cover patent rights.

Blue Oak Council publishes a reference list of permissive open software licenses, ranked by quality and legal strength.

Copyleft Licenses

Copyleft licenses work like permissive licenses with additional rules. Those additional rules require those who distribute copies of software to provide source code and the same license terms for that code to recipients, for the original code as well as some or all changes, enhancements, and other code combined with the copyleft code. Many in the copyleft licensing community consider these rules necessary to preserve users’ abilities to run, understand, and improve software. In other words, they rely on copyleft rules to keep open software open.

Copyleft licenses are often compared in the strengths of their rules that require sharing alike. Strong copyleft licenses trigger source code and license terms requirements in more situations, for more code. Those requirements may themselves demand more by way of compliance. Weaker copyleft licenses give clear ways to avoid source and license-terms requirements by separating new code from that of the project, less stringent requirements when copyleft is triggered, or both.

Blue Oak Council publishes a guide to copyleft licenses that includes a list of “families”, clustering copyleft licenses together by strength and approach.

Combining open software with other software and sharing the results usually triggers rules of all the open licenses involved. Copyleft license rules especially can clash with the rules of other licenses: permissive, copyleft, or proprietary. When combined software triggers more than one set of rules that can’t be satisfied at the same time—such as when the licenses of two copyleft libraries require different sets of terms for the combined program as a whole—that combination prevents distributing the combined software. Licenses that clash this way are called incompatible.

Continuing the example, one or both libraries with conflicting copyleft licenses might relicense, or change their license terms, to avoid incompatibility. This can be very difficult or impossible to coordinate for projects with many contributors who can’t be reached for agreement to offer the new terms. Some projects have chosen to dual license—offer a choice of two or more open licenses—in hopes that users will be able to pick at least one that avoids a compatibility problem with other software. Other projects have adopted variations on standard open licenses adding license exceptions that allow their copyleft rules to yield to the copyleft rules of other, more popular copyleft licenses.

The best-known copyleft licenses are the GNU General Public Licenses, maintained by the Free Software Foundation, home of the GNU Project. The Linux Kernel uses GPL version 2.0. Both GPL version 2.0 and GPL version 3.0 apply to a great deal of software frequently used with Linux. Linus Torvalds and the FSF have published clarifications of some of the more vague terms of the GPL for their software.

The FSF also maintains the weaker LGPL family of licenses, used for many linked libraries, to require source and licensing only of changes to the library, not programs builds with it. On the other hand, the Affero variants of the GPL, or AGPL licenses, strengthen copyleft to trigger source and license-terms requirements when software is made available to use over a network.

The Mozilla and Eclipse foundations maintain the Mozilla Public License and Eclipse Public License for the projects they host. These are considered weaker copyleft licenses than the GPL, and use a drafting style more familiar to professional licensing lawyers, akin to that of The Apache License, Version 2.0.

Most companies that use open software use significant amounts of copyleft software, often with GNU/Linux as a base system. Using copyleft software internally, without changes, can be just as simple as using permissively licensed software. But it’s often a trick to stay within those lines, operationally, over time.

When a company needs to make changes to copyleft software, wants to make copyleft software part of its own software or services, or both, license compliance gets more complicated. Whenever possible, companies like to avoid questions about whether their plans will trigger copyleft rules, and what they will have to do to comply. Relatively new, strong-copyleft licenses like Affero GPL breed the most anxiety and confusion. Companies can find and hire both lawyers and compliance professionals familiar with copyleft to help manage copyleft complexity, but many prefer to avoid the problem altogether by avoiding code under those terms.

Copyleft licenses are harder to comply with, reliably, than permissive licenses. Wise company counsel have reason to scrutinize copyleft code coming into their domains more carefully than permissively licensed code. But much ill-founded fear, uncertainty, and doubt around copyleft—especially about “viral” licenses “infecting” proprietary code—continues to waft off early public relations efforts to scare customers away from open software competing with proprietary products.

Overall, deciding whether to work with copyleft software is neither trivially easy nor impossibly hard. From a typical business point of view, assessing copyleft software is akin to assessing whether to accept a give-and-take deal, while assessing permissive software feels more like deciding whether to accept a free gift. Weighing a give-and-take proposition usually means considering more specifics and long-term goals, but gifts can also be welcome or burdensome.

You might like a good deal on pizza delivery better than the generous gift of a puppy dog you’re not keen to care for. A great piece of copyleft software, even with complex copyleft conditions, might work out better for a company than permissively licensed code when all manner of intellectual property, usability, or maintenance issues are considered.

Applying Licenses to Code

There are all kinds of conventions, traditions, and fashions in how, exactly, open licenses get applied to code to make it open software. The good news is that they mostly boil down to putting a copy of a license, or mention of a license and where to find its text online, in files next to the code. Whatever method contributors choose to distribute their code—publicly accessible web server directory, hosted revision control repository, published archive—they make sure it comes with an easy-to-find statement, or notice, of license terms.

Probably the most common method is adding a file to the root of a project’s directory with a name like LICENSE or COPYING. A close second is mentioning a license in a header comment at the top of each source file. Some authors also mention licensing in standard documentation files, as at the bottom of README. More recently, package metadata formats—Maven’s, RubyGems’, npm’s, Cargo’s—specify a field and format to identify standard open-source license terms, often using a standardized short code of identifier for a license specified by Software Package Data eXchange (SPDX).

The good news is that these methods seem to work. There have been relatively few court cases involving open licenses in the United States, but those we’ve seen have reached decisions on the assumption that the terms in the notice are the terms for the code. The bad news is that, in practice, issues frequently crop up when code under multiple licenses, from different contributors, ends up in the same archive or distribution artifact. It’s often unclear what license from who applies applies to what code. It’s even more common to see code combined in one place without license notices being combined there, too.

The SPDX project, hosted by the Linux Foundation, publishes a standard for metadata to describe the license terms of software artifacts. This approach differs in allowing consumers, rather than maintainers and distributors, to review code for license information and annotate code with machine-readable metadata. A key motivation for the project is to enable consumers of open code to exchange licensing annotations, reducing duplication of effort. SPDX’s metadata standard has been validated by ISO and adopted by some large companies, but it remains to be seen whether it will take off industry-wide.

Contribution Management

Many open-source contributors believe that sending a patch to an existing open-source project without any mention of licensing gives permission to use their contribution under the same terms that apply to the existing code. This idea, which Richard Fontana calls “inbound=outbound”, is very common. But it is not the law.

To date, the lawyer-pleasing approach to contributor licensing has been the Apache Foundation’s layered use of a section about contributions in its license form and contributor license agreements between contributors and the Apache Foundation, which in turn licenses the public to use Apache software. For contributors with a company affiliation, Apache also signs a contributor agreement with the company, covering contributors by company personnel. Other institutional stewards of open-source projects, foundations and private companies, have made do with just individual contributor license agreements.

Unfortunately, contributor license agreements are imposing legal documents—almost universally longer and denser than The MIT License or even GPL version 2—especially for contributors starting from the false assumption that no license document from them at all is plenty clear enough. Ensuring that signed contracts precede accepted patches is also a drag, even with bots or scripts to help automate the process. The cost is particularly high for small and relatively informal projects, which can otherwise attract a lot of small commits, rapid fire, for which nobody wants wants to spend more time reading, signing, and filing a contract than making the commits.

Shaken by the SCO lawsuits, but unwilling to impose the inconvenience of a centralized CLA service on a sprawling network of contributors, Linux Kernel developers developed the Developer Certificate of Origin. The DCO, a short statement from the coder’s point of view that they’re sure they have all the permission they need to contribute the code they’re offering, isn’t a license, nor is it a guarantee that the contributing coder has the rights they claim. But even when referenced shorthand, via Signed-Off-By tags in Git commit messages, it arguably creates a relevant and permanent written record of attribution and licensing diligence for all contributors. Those kinds of records might have been enough to stave off claims, like those from SCO, that code in the Linux codebase came not from open software contributors, but from their own, copyrighted code. The Eclipse Foundation has since approved this mechanism, in lieu of its prior, Apache-esque contributor license agreements.

Finally, a special note on copyright assignments, especially for projects under copyleft licenses. Historically, both some foundations and many private-company stewards required not licenses, but assignments of copyrights in contributions for acceptance into their open-source projects. In general terms, assignments change the ownership of copyrights, while licenses merely give permission under them. Confusingly enough, organizations that required assignments often guaranteed that they would license assigned copyrights right back to the public, including the developer who assigned them to the organization to begin with. As a kind of a middle ground, the Oracle Corporation required assignments of joint ownership in contributions, so both Oracle and the contributor owned their contributions. The Clojure programming language project tweaked that model, adapting Oracle’s form, to require joint ownership of contributions with Rich Hickey, the leader of the project, personally.

Assignments work much like contributor license agreements, and sometimes have essentially the same legal effect, due to rights granted back to contributors. But assignments inevitably entail more hassle, since many countries’ laws require notarization or other formalities to assign intellectual property rights by contract. Not to mention they sound scary and unnecessary. If the corporate steward on the other side is more than willing to use open-source software under license, why does it require assignment from contributors to its own projects?

Some organizations required assignments just because that was the most they could get, and legal advice was to get as much as possible. In some cases, this produced backlash, which was often deserved for lack of good and transparent communication, if not for the legal substance of the assignment agreements themselves.

One early, rational case for assignment was relicensing. If the steward of a project anticipates that they may want to change the license terms for a project in the future, agreements to license contributions under the current license terms mean a whole lot of work hunting down old contributors later. Where there are many contributors, that may not be practically possible. Eventually, drafters of contributor license agreements turned to this problem and built rights to relicense into many forms. Often these forms limit relicensing, so that the steward can’t chose whatever terms—say, proprietary terms—they may like. A choice of licenses approved by named foundations—the Open Source Initiative, Free Software Foundation, Debian, or some combination—is also common.

A more lasting argument for assignment is to create a single legal entity with all the relevant rights needed to bring a lawsuit for infringement. For reasons of legal procedure and negotiating leverage, having a single copyright owner makes it much easier to sue someone skirting license conditions for infringement, and compel a settlement. The more license conditions the open-source license you use, and the more meaningful the objectives those conditions aim to achieve, the more valuable centralized ownership becomes. Accordingly, copyleft-focused organizations like the Free Software Foundation and Software Freedom Law Center, both active enforcers of GPL copyleft conditions, routinely require assignments for contributed code. These organizations primarily enforce license conditions to secure compliance—release of source code—but need strong claims that they can sue in court for damages, as leverage.

Additional Resources

Important Institutions

You should be aware of a number of important institutions in the open software world. These institutions are important sources of information and policy decisions. Some host important projects.

Many also publish points of view on policy, operational, and legal issues. Often enough, they disagree. You should be aware of these positions and disagreements when they affect licenses or software that interest you. A foundation’s positions often carry extra weight for software projects that the foundation hosts.

• The Open Source Initiative promotes the concept of “open source software”, publishes a definition of “open source”, and maintains a list of licenses they have approved as “open source”.

• The Free Software Foundation promotes the concept of free software, publishes a definition of free software, maintains the GPL family of copyleft licenses and related enforcement principles, and hosts many software projects.

• The Linux Foundation hosts the Linux Kernel and other projects, leads several patent-related initiatives, and supports the Software Package Data eXchange licensing metadata standards project. The Linux Foundation also serves as an umbrella organization for other open software foundations.

• The Apache Foundation, Eclipse Foundation, Mozilla Foundation, and other foundations host projects and maintain standard form licenses.

• Software Freedom Conservancy provides financial and institutional hosting for a number of projects, as well as general legal support.

• Blue Oak Council publishes this guide and other free, practical materials about software licenses, including a list of permissive licenses, guide to copyleft licenses, and example compliance policies for large and small organizations.

Further Reading

The best book on open software for business, with especially strong coverage of copyleft licenses like the GPL, is Heather Meeker’s Open (Source) for Business.

The best book on open software in the broader context of intellectual property law more generally is Van Lindberg’s Intellectual Property and Open Source. Published in 2008, it’s a bit dated now, especially on patent and trade secret law, where there have been legal changes.

Thanks

The Council thanks Kunal Marwaha and Kevin P. Fleming for feedback and proofreading.