Many in the open source community have expressed concern about the activities of Patrick McHardy in enforcing the GNU General Public License (GPL) against Linux distributors. Below are answers to common questions, based on public information related to his activities, and some of the legal principles that underlie open source compliance enforcement.

Who is Patrick McHardy? McHardy is the former chair of the Netfilter core development team. Netfilter is a utility in the Linux kernel that performs various network functions, such as facilitating Network Address Translation (NAT)—the process of converting an Internet protocol address into another IP address. Controlling network traffic is important to maintain the security of a Linux system.

How much has McHardy contributed to Linux? This is not an easy question to answer. First, it’s not easy to assess the importance of contributions; all we can do is look at number and size of commits. And second, even if one tracks commits, the tracking mechanisms are not perfect. Git has a blame feature that tracks who nominally commits certain lines of code to the git repository. Tools like cregit can be used with git blame to report commits at a more granular level of a code token, producing a more accurate picture of contributions at a file level. Git blame and cregit are useful because they both use publicly available information—the information just needs to be interpreted properly.

An analysis of blame with cregit can help assess McHardy’s potential contributions. For example:

The bulk of his contributions appear to be concentrated during the period 2006-08 and 2012.
Of approximately 135 files in which McHardy included his copyright notice, only 1/3 are files to which McHardy contributed 50% or more of the file’s code.
His contributions appear to constitute well under .25% of the code in the kernel.
Most of McHardy’s contributions appear to be to Netfilter; however, blame might not always tell the whole story. For example, a committer can check in many lines of code having made only minor changes, or can check in code written or owned by others. For these reasons, the authorship of a committer can be under- or over-reported.

Records of contributions to the kernel prior to 2002 are not useful to identify contributors, because at that time, Linus Torvalds checked in all code. Patrick McHardy’s contributions did not begin until 2004.

The difficulty of establishing copyright ownership using development repository metadata arose in the Hellwig v. VMware case. Courts may be reluctant to accept such information as evidence of authorship.

What copyright rights does McHardy have in the Linux kernel? Copyright ownership in large projects such as the Linux kernel is complicated. It’s like a patchwork quilt. When developers contribute to the kernel, they don’t sign any contribution agreement or assignment of copyright. The GPL covers their contributions, and the recipient of a copy of the software gets a license, under GPL, directly from all the authors. (The kernel project uses a document called a Developer Certificate of Origin, which does not grant any copyright license.) The contributors’ individual rights exist side-by-side with rights in the project as a whole. So, an author like McHardy would generally own the copyright in the contributions he created, but not in the whole kernel.

What is “community enforcement”? Because the ownership of large projects like the Linux kernel is often spread out among many authors, individual owners can take enforcement actions that are inconsistent with the objectives of the community. While the community may have a range of views on how best to encourage adherence to the GPL’s terms, most agree that enforcement should be informal (not via lawsuits) and that the primary goal should be compliance (rather than penalties). Software Freedom Conservancy, for example, has issued certain principles of community enforcement, which prioritize compliance over the pursuit of lawsuits or money damages. There is no bright-line rule for when informal actions should become lawsuits, or how much money an enforcer should request. Most developers in the Linux community, however, consider lawsuits only the last resort, and are willing to refrain from legal action and work with users who sincerely wish to comply.

Why have so many open source lawsuits been filed in Germany? Some plaintiffs seeking to enforce open source licenses have filed their claims in Germany’s court system. There are a few instruments for pursuing legal action in Germany that don’t have exact analogs in the U.S. or other common law countries.

Abmahnung (“warning”): The “warning” is a request from the claimant to the defendant to stop doing something. In the copyright context, it is a letter from the copyright owner requesting that an alleged infringer stop infringing. These letters are issued by lawyers, not courts, and are often the first step in a copyright enforcement action in Germany. In the U.S., the closest analog would be a cease and desist letter.

Unterlassungserklärung (“cease and desist declaration” or “declaration of injunction”): The “warnings” will often have a “cease and desist declaration” attached to them. This “declaration” is like a contract—signing it will subject the defendant to legal obligations that might not otherwise exist. In particular, the declaration may contain obligations that are not required by the GPL itself. In Germany, it is common for such a document to contain penalties for noncompliance. In the U.S., the analog would be a settlement agreement, but settlement agreements rarely specify the penalties for breach—and in fact, in the U.S., “penalties” may not be enforceable in contracts. The “declaration” is not a court order, but if the defendant signs it, it may gain the legal force of a court order. So, signing them before seeking legal advice is often not a good idea. There are other approaches to consider in dealing with a complainant who sends a cease and desist declaration, including proposing a revised declaration with lesser penalties or obligations. Further, because a cease and desist declaration may also contain a non-disclosure requirement, signing one of these documents may also create additional difficulties, such as restricting the ability to seek support from other defendants or to alert the community about the claimant’s assertions.

For details, see abmahnung.org/unterlassungserklaerung/.

Einstweilige Verfügung (“interim injunction” or “preliminary injunction”):The “interim injunction” is a court order that is like a temporary restraining order in the U.S. A defendant’s non-response to a “warning” or “declaration” can encourage a plaintiff to seek an “interim injunction,” although there is no requirement that a claimant send a “warning” before requesting an “interim injunction” from a court. Interim injunctions for copyright infringement can prescribe penalties of 250,000 Euro or 6 months’ imprisonment. In the U.S., in contrast, criminal penalties for copyright infringement are extremely rare, and must be pursued by the government, not private parties. Also, in the U.S., courts do not prescribe remedies for future possible infringement—they only order defendants to stop current infringement or pay damages. In Germany, interim injunctions are also available ex parte, meaning that a plaintiff can apply to the court without the defendant being heard, and they can issue without the defendant’s participation. If you receive a “warning,” and suspect that a request for an “interim injunction” might follow, there is a possibility to file a preemptive “opposition” with the court.

For details, see Abmahnung.org.

Widerspruch (“opposition” or “contradiction”):The “opposition” is an opportunity for a defendant to file an opinion with the court that an “interim injunction” is not justified.

For an example of a case in which this process took place, see this English translation of a German court order.

How many claims has McHardy brought? Due to the lack of publicly accessible records for many German court dockets, it is difficult to determine the precise number of actions brought by McHardy. It has been stated that McHardy has approached over 50 enforcement targets. For details, see Source Code Control and 7 Notable Legal Developments in Open Source in 2016. That doesn’t necessarily mean 50 lawsuits—it probably means 50 demands threatening a lawsuit. But it is difficult to verify this claim with public sources. For details, see Litigation and Compliance in the Open Source Ecosystem.

Why hasn’t the community stopped McHardy? Various members of the community, including Software Freedom Conservancy, have reached out to try to persuade McHardy to change his strategy, but thus far they have not been successful. The Netfilter project recently published a licensing FAQ addressing concerns about McHardy’s actions.

What can we do to stop McHardy and other copyright profiteers? There is no one answer to this question, and there may be no way to completely stop them. But here are some suggestions for what might reduce the number of copyright profiteers.

Strive to comply with open source licenses. There are plenty of resources to learn how to comply with licenses, and how to set up an open source compliance program at your company. For example:

The Linux Foundation published Practical GPL Compliance.
Software Freedom Law Center published A Practical Guide to GPL Compliance (Second Edition).
The OpenChain project publishes a specification for recommended internal processes for open source management.
Don’t sign an Unterlassungserklärung before seeking legal advice. As explained above, an Unterlassungserklärung can subject you to obligations and penalties that are not found in the GPL itself. Don’t cooperate with the profiteers. You can make yourself a harder target, and enlist the help of other targets in the community.

Support open source development. Authors should not have to resort to profiteering to make a living. Companies that use open source software should not expect open source developers to develop software for free; they should chip in to support important projects.

Learn to recognize a copyright profiteer. Be aware of the general differences between community-oriented GPL enforcement and copyright profiteering. Community-oriented enforcement generally aims to achieve GPL compliance through education and assistance, while respecting users’ freedoms. Profiteering, by contrast, may focus on poorly researched scattershot claims and the threat of legal action for purposes of financial gain. Be on the lookout for assertions that prioritize financial gain and set the stage for unreasonable damages penalties.

Make claims public. If you are the target of a profiteer, and have a choice to make the claims public, doing so might help both you and others by discouraging their actions. As members of the open source community, we all share a duty to speak out against profiteers who seek to burden the community with allegations that can be resolved in more appropriate and less contentious ways.

“The Compliance Industrial Complex” is a term that evokes dystopian imagery of organizations engaging in elaborate and highly expensive processes to comply with open source license terms. As life often imitates art, many organizations engage in this practice, sadly robbing them of the many benefits of the open source model. This article presents an economically efficient approach to open source software license compliance.

Open source licenses generally impose three requirements on a distributor of code licensed from a third party:

Provide a copy of the open source license(s)
Include copyright notices
For copyleft licenses (like GPL), make the corresponding source code available to the distributees
(As with any general statement, there may be exceptions, so it is always advised to review license terms and, if necessary, seek the advice of an attorney.)

Because the source code (and any associated files, e.g. license/README) generally contains all of this information, the easiest way to comply is to simply provide the source code along with your binary/executable application.

The alternative is more difficult and expensive, because, in most situations, you are still required to provide a copy of the open source licenses and retain copyright notices. Extracting this information to accompany your binary/executable release is not trivial. You need processes, systems, and people to copy this information out of the sources and associated files and insert them into a separate text file or document.

The amount of time and expense to create this file is not to be underestimated. Although there are software tools that may be used to partially automate the process, these tools often require resources (e.g., engineers, quality managers, release managers) to prepare code for scan and to review the results for accuracy (no tool is perfect and review is almost always required). Your organization has finite resources, and diverting them to this activity leads to opportunity costs. Compounding this expense, each subsequent release—major or minor—will require a new analysis and revision.

There are also other costs resulting from not choosing to release sources that are not well recognized. These stem from not releasing source code back to the original authors and/or maintainers of the open source project, an activity known as upstreaming. Upstreaming alone seldom meets the requirements of most open source licenses, which is why this article advocates releasing sources along with your binary/executable; however, both upstreaming and providing the source code along with your binary/executable affords additional economic benefits. This is because your organization will no longer be required to keep a private fork of your code changes that must be internally merged with the open source bits upon every release—an increasingly costly and messy endeavor as your internal code base diverges from the community project. Upstreaming also enhances the open source ecosystem, which encourages further innovations from the community from which your organization may benefit.

So why do a significant number of organizations not release source code for their products to simplify their compliance efforts? In many cases, this is because they are under the belief that it may reveal information that gives them a competitive edge. This belief may be misplaced in many situations, considering that substantial amounts of code in these proprietary products are likely direct copies of open source code to enable functions such as WiFi or cloud services, foundational features of most contemporary products.

Even if changes are made to these open source works to adapt them for proprietary offerings, such changes are often de minimis and contain little new copyright expression or patentable content. As such, any organization should look at its code through this lens, as it may discover that an overwhelming percentage of its code base is open source, with only a small percentage truly proprietary and enabling differentiation from its competitors. So why then not distribute and upstream the source to those non-differentiating bits?

Consider rejecting the Compliance Industrial Complex mindset to lower your cost and drastically simplify compliance. Use open source the way it was intended and experience the joy of releasing your source code to benefit your bottom line and the open source ecosystem from which you will continue to reap increasing benefits.

Recently, Apache re-classified code under Facebook’s BSD+ Patents license to “Category X,” effectively banning it from future contributions to Apache Foundation projects. The move has re-ignited controversy over the patent grant, but like many events in the open source community, the controversy is more partisan than practical. In fact, it’s unlikely the move will affect adoption of React.js, and the criticisms of the BSD+Patent grant mostly don’t survive the scrutiny of reason.

The Facebook patent grant, officially called the Additional Grant of Patent Rights Version 2, has been in effect for years. It applies to the wildly popular React.js code—a JavaScript library for rendering user interfaces. The roster of major technology companies using the code is impressive, including such consumer-facing giants as Netflix—and of course, Facebook itself.

A new reaction to an old grant
The reaction to this news is surprising, given the parallel patent licensing model is nothing new. Facebook released its BSD+Patents grant in 2013 (with a revision in 2015). But a similar model was used with some fanfare by Google with its WebM codec in 2010. This licensing model involves two parallel and simultaneous grants of rights: a BSD license to the copyright in the software, and a separate grant to practice patents that read on the software. Putting the two together means there are two independent and parallel grants of rights. In this respect, it is quite similar to the Apache 2.0 license which, like BSD, is a permissive license, and which also contains a defensive termination provision that exists alongside the copyright license grant.

Much of the reaction to Apache Foundation’s announcement has just created confusion, such as this article misleadingly calling it “booby-trapped.” In fact, many open source licenses have defensive termination provisions—which are mostly considered a reasonable mechanism to discourage patent lawsuits, rather than a booby trap. They are also the rule rather than the exception; all major open source licenses with patent grants also have defensive termination provisions—each with slightly different terms. The difference between the Facebook grant, which Apache has rejected, and the Apache 2.0 license, which Apache requires for its projects, is more subtle than the controversy suggests.

Defensive termination provisions come in many flavors
Defensive termination provisions vary in two main ways: the trigger for termination and the scope of rights terminated. As to the scope of rights terminated, there are two camps: those that terminate only the patent rights grant (including Apache 2.0, Eclipse Public License, and the Facebook grant) and those that also terminate the copyright license as well (Mozilla Public License and GPL 3). In other words, for most licenses, bringing a patent infringement suit can only cause termination of one’s patent rights; for the others, bringing a patent lawsuit can result in termination of the copyright license as well—forcing one to stop using the code. Copyright license termination is a much stronger anti-patent mechanism, and more risky for private businesses, resulting in some private companies refusing to use GPL3 or MPL code.

The Facebook grant differs from most other open source licenses in its threshold for triggering termination. In Apache 2.0, for example, the termination of the patent grant is triggered by a patent claim accusing the software provided under the license. The idea is to create a “patent commons” for the software. Most other open source licenses follow roughly this calculus. The Facebook patent license also terminates if the licensee brings a claim against Facebook or any party accusing a Facebook product. In that respect, the termination trigger is similar to the one in the Common Public License 1.0, written many years ago by IBM. (“If Recipient institutes patent litigation against a Contributor with respect to a patent applicable to software…then any patent licenses granted by that Contributor to such Recipient under this Agreement shall terminate as of the date such litigation is filed.”)

Nothing new under the sun
Defensive termination provisions of the scope in the Facebook grant are common in patent licensing outside of the open source landscape. Most patent licenses terminate if the licensee brings patent claims against the licensor. The reason is that a licensor does not want to be unilaterally “disarmed” in a patent battle. Most patents are used only defensively—asserted when a competitor sues the patent owner. A sues B and then B sues A, resulting in mutually assured destruction. If B has released its software under an open source license without a broad defensive termination provision, B is potentially without recourse and has paid a high price for its open source code release. A gets to simultaneously free ride on B’s software development and sue B for patent infringement.

Finally, the Facebook grant itself is not new. The grant was released in 2013, and React.js’s popularity has been growing since then. As with many open source licenses, the industry’s willingness to absorb a new license depends on the tastiness of the code released under it. In the case of React.js, the code was great, and the patent license terms were new but reasonable.

Is it open source?
Some have suggested that the BSD+Patents Clause violates the Open Source Definition. The OSD does not allow licenses that discriminate against persons, groups, or fields of endeavor. But the patent grant does not have license scope limitations; it terminates if the licensee misbehaves—that misbehavior having a lower threshold for actions against the code author than for others. So it seems likely that BSD+Patents does not violate the OSD, and moreover, CPL is already approved by the Open Source Initiative as compliant. CPL, like BSD+Patents, sets a lower threshold for termination based on patent suits against the code author.

What is the upshot?
The practical result of the Apache Foundation’s decision is unclear. Category X licensed code cannot be included in an Apache Foundation repository. (That category also includes licenses like GPL.) Apache’s re-classification doesn’t mean anyone is restricted from using React.js—it just can’t be committed in an Apache project. It’s not even clear that an Apache project cannot contain a dependency on BSD+Patents-licensed code.

Meanwhile, in private business, there is little controversy about using code under the BSD+Patent terms. Most companies have examined the marginal legal risk of this license compared to others (like Apache 2.0) and considered it underwhelming. Unless a company decides to sue Facebook (or accuse its products), the termination trigger has no actual effect. If you want to fling patent claims at a company that developed and released a great piece of code, removing the code from your business seems like a reasonable price to pay.

Some of the controversy seems to arise from concern that Facebook is advantaged over others in the license terms. But that is not the same as harming the open source community. The BSD+Patents grant establishes the same “patent commons” as Apache 2.0 as a baseline, but provides more protection for the contributor (Facebook) against software patent claims of licensees. It’s odd that a community so opposed to software patents would find this objectionable, particularly in light of the array of defensive termination provisions that have been used in the past.

In July 2017, the Apache Software Foundation effectively banned the license combination Facebook has been applying to all the projects it has been releasing as open source. It is using the 3-clause BSD license (BSD-3), a widely used Open Source Initiative (OSI)-approved non-reciprocal license, combined with a broad, non-reciprocal patent grant, but with equally broad termination rules to frustrate aggressors. The combination represents a new open source license, which I’ve termed the “Facebook BSD Plus Patent License” (FB+PL), and to my eyes it bears the hallmarks of an attempt to be compatible with both the GPL v2 and the Apache License v2 at the same time, in circumvention of the alleged incompatibility of those licenses.

The use of the license by Apache projects is still in play, but the reason I believe Facebook has made a mistake may not be immediately obvious to ever-pragmatic software developers. For example, lawyer-turned-coder Dennis Walsh says of the issue, “there’s no there there.” His point is that the combo affects only use of the particular software project you’re using to which it is applied, and the consequences of withdrawal of the patent grant are exceptionally unlikely to be serious for another patent holder. He concludes:

Facebook wants to make open source software and not be sued—a noble goal. To that end, they can use some harsh clauses. But in this case, for the practical and legal reasons outlined above, it’s hard to find any teeth behind the bite.

Dennis is probably right. But that’s beside the point. Facebook’s rookie mistake of inventing its own open source license is always a bad idea. There are a range of important considerations that are not about the immediate risks or the specific instance. Facebook’s license action hits pretty much all of them.

License approval matters
Use of a non-OSI-approved license means legal review is always required for corporate use, just as it would be for any proprietary license. OSI license approval matters because it provides developers with an indication that community review has verified the license and found it delivers software freedom in a way that does not create unacceptable risks. Had Facebook taken the route of seeking OSI approval, it would most likely have discovered the issue it was causing and avoided it at the outset. There is actually an OSI-approved license that achieves Facebook’s apparent goal (the BSD Plus Patent License). It was submitted and approved quite recently and looks a reasonable alternative Facebook could consider adopting.
Less permission-in-advance
It’s not just license approval that matters. Any kind of uncertainty concerning the freedom to innovate gets in the way of developers wanting to use code. An ambiguous term that relates to usage will need disambiguation before use—a step that amounts to seeking permission to proceed. For the same reasons public domain is bad for developers, using terms that require permission to be sought before proceeding chill adoption. By adding a Facebook-specific legal document to the project, every corporate developer will now need to reach out to a legal adviser before they can proceed. Even if the answer turns out to be “yes, OK,” they still had to stop and seek permission. And as Aaron Williamson points out, that may not be their reaction.
Uneven playing field
The patent grant Facebook uses gives it, and no one else in the project, special rights and protections. That makes open source developers nervous, for the same reasons as contributor agreements do. The whole value of software freedom to an open source project is it creates a safe space where everyone is equal and protected from everyone else’s motivations. Carving out extra rights for you alone is sociopathic, and sadly, the community has plenty of examples of unequal rights being eventually abused.
Implied grant voided
Many open source legal authorities believe that by granting permission to use software for any purpose, even licenses with no mention of patents grant an implied patent license. By adding any form of external patent grant, Facebook indicates it does not believe that grant is (at best) sufficient or (at worst) exists. Lawyers who specialize in open source see that as an unwarranted escalation by Facebook. That’s why approval of CC0 at OSI was abandoned, for example.
Apache rules
Although I’ve not been able to find a clear and complete rationale, Apache appears to have ruled against Facebook’s license combo because Facebook has a patent grant Apache considers more restrictive than the one in the Apache License v2. Apache is keen indeed to be a neutral source of software—a “universal donor”—so terms that militate against this are highly likely to fall afoul of its rules. For components intended to be part of its ecosystem, it seems rash to mess with Apache’s licensing.
Thus it makes no sense to argue that, because the risk is small, the matter is trivial. Behaving in a way that ignores the five community norms I’ve listed above helps no one, not even Facebook. While it is currently holding firm, I hope Facebook gets it fixed, and I am willing to help.

If you’re a software developer today, you know how to use open source software, but do you know how and why open source licensing started? A little background will help you understand how and why the licenses work the way they do.

Origins of open source licensing
Technologists today, having grown up in the age of Microsoft Windows and proprietary software, may believe that open source licensing is a recent trend that began in the 1990s. Although open source licensing’s popularity has skyrocketed in the past two decades, in truth, open source was the original model for software licensing, with proprietary licensing coming later.

In fact, the two models for software licensing (open source and proprietary) trace their origins from a common source: the Unix operating system. Unix was developed by AT&T Bell Laboratories in the late 1960s and early 1970s and was the first general-purpose operating system. At that time, AT&T’s market position was so dominant that the US Justice Department issued a consent decree barring AT&T from engaging in commercial activities outside the field of its telephone service, which was AT&T’s primary business. Because of the consent decree, AT&T could not exploit Unix as a commercial product, so Bell Labs gave Unix away in source code form under terms that allowed its modification and redistribution. This led to Unix’s widespread use and popularity among computer scientists in the 1970s and 1980s.

After the US Justice Department lifted the consent decree in 1983, AT&T pivoted to commercialize Unix as a proprietary product and adopted more restrictive licensing terms that allowed Unix to be redistributed only in object code format. Meanwhile, the 1980s saw the advent of microcomputers (PCs), which led to the standardization of software. This standardization, in turn, encouraged companies to distribute their software in binary-only form because there was less need for users to investigate or troubleshoot source code. And so proprietary licensing became the dominant model for licensing software.

Interest in open source licensing reemerged in the 1990s with the development of the Linux operating system. Since the privatization of UNIX, the demand had swelled for an operating system that would be a free alternative to UNIX. To be useful, that operating system needed both an operating system kernel and the tools necessary to install, run and develop programs for it. Linus Torvalds, a teenager in Finland, developed the first Linux kernel as a school project. Meanwhile, the GNU Project has been formed to develop those tools, and when those two parts were combined, a free alternative to UNIX was available. The combined operating system—most commonly called Linux—was released under the GNU General Public License (GPL), a licensing model that was created by Richard Stallman of the GNU Project. The GPL granted recipients unfettered rights to redistribute software with the condition that the source code could not be kept secret. As Linux grew in popularity, with thousands of contributors and billions of users, the industry learned to follow and adopt GPL’s terms. By the late 1990s, GPL and the open source licensing paradigm more broadly gained traction and industry-wide acceptance. In the 2010s, it has nearly eclipsed proprietary license in importance to the technology industry.

Types of open source license
Today, the GPL license that Stallman pioneered is in its third version (GNU GPLv3) and is only one of several dozen types of open source licenses. The Open Source Initiative, an organization founded in 1998 to promote open source software and normalize the use of the term, has approved more than 80 open source licenses. These 80 licenses generally fall into one of two categories: permissive licenses and copyleft licenses.

A permissive license is simple and is the most basic type of open source license: It allows you to do whatever you want with the software as long as you abide by the notice requirements. Permissive licenses provide the software as-is, with no warranties. So permissive licenses can be summarized as follows:

Do whatever you want with the code
Use at your own risk
Acknowledge the author/contributor
Copyleft licenses add requirements to the permissive license. In addition to the requirements listed above, copyleft licenses also require that:

If you distribute binaries, you must make the source code for those binaries available
The source code must be available under the same copyleft terms under which you got the code
You cannot place additional restrictions on the licensee’s exercise of the license
The table below categorizes popular open source licenses under the permissive and copyleft frameworks. The copyleft licenses are also listed in ascending order of strength, from strongest at the top to the weakest at the bottom. “Strength” refers to the degree to which surrounding software may need to be subject to the same copyleft requirements. For example, GPL is strong because it requires that any program that contains GPL code must contain only GPL code. LGPL is weaker because it allows dynamic linking to other proprietary code without subjecting that linked code to the same GPL requirements. The weakest copyleft licenses, EPL and MPL, allow any kind of integration with other code, as long as EPL or MPL code is in its own file.

Permissive Licenses

Copyleft Licenses

BSD (Berkeley Software Distribution)
MIT
Apache 2
Affero GPL (AGPL)
GPL
Lesser GPL (LGPL)
Mozilla Public License (MPL)
Eclipse Public License (EPL)
Common Development and Distribution License (CDDL)
Top open source questions
When I advise clients on open source licensing, the four most common questions they ask are:

What is “distribution?”
How do open source licenses affect patent rights in software?
What is the “notice” requirement and how do I comply?
What is a “derivative work” and, related, does incorporating GPL code into my proprietary code cause the proprietary code to be licensed under GPL?
The short answers to these questions appear below:

What is “distribution?” In simple terms, distribution refers to transferring a copy of a copyrighted work (such as software) from one legal person to another. The concept of distribution matters because the requirements of open source licenses are triggered only when software is distributed. Thus, a person who does not distribute software cannot violate an open source license’s terms. And because “legal person” includes a corporation, there is no distribution—and therefore no risk of violating a license’s terms—if software is merely transferred between employees of the same company.
Today, distribution can be a thornier question for businesses that deploy software through the Internet, cloud, or a SaaS model. Does allowing users to interact with a software application over the Internet qualify as distribution? For most open source licenses, the answer is no. Indeed, GPLv3 uses the term “convey” rather than “distribute,” precisely to clarify that SaaS use does not trigger any license requirements. But the Affero GPL (AGPL) license is one exception that takes a different approach. AGPL’s requirements (which are the same as GPL) are triggered once software is modified and made available for use and interaction over a network.

How do open source licenses affect patent rights in software? Some open source licenses (e.g., Apache 2, GPLv3) include express patent license provisions, which grant recipients a license to any patents covering the software product. Other open source licenses (e.g., BSD, MIT, GPLv2) are mum on patent licenses. Nonetheless, for these licenses, courts may use the doctrine of “implied license” to find that recipients are still licensed and protected from any patent infringement allegation arising from using the licensed software product. By doing this, courts prevent licensors from taking “two bites at the apple” and suing for patent infringement for using the very software they have licensed. In sum, unless expressly stated otherwise, open source licenses limit the author’s ability to sue license-abiding recipients for alleged patent infringement.
What is the “notice” requirement and how do I comply? The notice requirement means that a distributor of open source software must inform recipients that certain open source software, which is available under the noticed license, is included in the software being delivered to the recipient. Open source licenses each have their own specific notice requirements. Commonly, these requirements include providing entire copies of applicable licenses and acknowledging authors and contributors. A best practice is to deliver the source code covered by the license up front because full copies of licenses are typically included as text files in the source code package. Another best practice is to follow the GPL’s notice requirements because they are considered among the most stringent. Thus, complying with GPL’s notice requirements will usually ensure compliance with other applicable open source licenses’ notice requirements.
Derivative works and the myth of viral GPL: A common concern of clients is that by incorporating code licensed under GPL (or similar copyleft license) into their proprietary code, the proprietary code will be “infected” or “contaminated” and become licensed under GPL (i.e., the proprietary code is effectively converted into GPL code) or forced into the public domain. This concern causes some to view GPL as viral and discourages them from using GPL code because they are worried that any derivative works that incorporate GPL code will also be licensed under GPL.
These concerns are largely unfounded. It is true that under GPL, all code in a single program must be either be subject to GPL or not subject to GPL. So if a developer were to combine GPL code with proprietary code and redistribute that combination, it would violate the GPL. But the likely worst-case consequence of this violation is that the author of the GPL code could exercise their right to bring a claim for copyright infringement. The remedy for copyright infringement is either damages (money) or injunction (stop using the GPL code). Critically, copyright law supports no remedy that would force the offending developer to license their proprietary code under GPL or to put that code into the public domain. Combining GPL code with proprietary code does not therefore “infect” the proprietary code or convert it into GPL code.

To learn more, attend Heather Meeker’s talk, Open source software licensing: What every technologist needs to know, at Strange Loop, which will be held September 28-30 in St. Louis, Missouri.em>

Open source software can be a double-edged sword for startups. It can be a startup’s lifeblood, because it helps you innovate rapidly without starting from scratch. But, as they say, open source software is free like a puppy is free: The true cost of open source software is obeying open source licenses.

Misuse of open source software can delay or derail investment and corporate exit opportunities. But you can easily comply with open source licenses if you follow these simple rules.

Don’t use software without license terms. Some software on the internet doesn’t contain licensing notices, but that doesn’t mean that it can be used freely. The people posting the software may not have complied with upstream licensing terms. Or the author of the software may not yet have applied a license to the software—open source or otherwise. “No license terms” means no license: You should either avoid using the software or ask the author to apply a permissive license.
Don’t violate open source licenses. Open source software use may be difficult for a software owner to track, but that does not mean use and noncompliance go unnoticed. Violating open source licenses can expose a startup to legal liability and public embarrassment, and can even compromise investments or acquisitions. It can also cause potential customers to refuse to buy your products out of fear of downstream liability. Developers have taken great effort to make their software open source—including foregoing licensing fees. Misuse of the software is unfair to those developers and harms the innovation they hoped to facilitate.
Keep track of what software you are using. Someday you will have to provide a list of the open source software you are using. Potential investors and acquirers will ask for the list, and maintaining an up-to-date list will save you considerable time and effort when that request comes. Most open source software downloads include a “license.txt” or “copying.txt” file. Keep a copy of that license and note what software it covers. Most startups track licensed software in a simple spreadsheet.
Understand permissive and copyleft licenses. Open source licenses fall broadly into two types: permissive (BSD, MIT, and Apache) and copyleft (GPL, LGPL, Eclipse Public License, Mozilla Public License, and Common Development and Distribution License). Most companies—and their customers—have no legal concerns over using software under permissive licenses. Complying with copyleft licenses takes more care, however, and may be inconsistent with certain plans for keeping software proprietary.
Comply with notice requirements. Whether permissive or copyleft, all open source licenses have notice requirements. Typically, this means you need to include a copy of the applicable license when distributing open source software. It’s generally not sufficient to merely include a link to or short form of the license. It’s important to develop a license notice delivery strategy that complies with most open source licenses without confusing or alienating your customers.
Understand which open source licenses work with distributed software. Most open source licenses—other than the Affero GPL—have no conditions for software-as-a-service (SaaS). For distributed elements of SaaS and cloud systems (like JavaScript) or distributed software (including mobile apps and beta tests), you can use software under permissive licenses, but you will need to be especially careful before using software under copyleft licenses. Use GPL software only if it executes 100% in its own process with no linked code—don’t believe myths about compliance by dynamically linking to the GPL code or making the customer download the GPL software. Use LGPL software only as a dynamically linked library. And use other copyleft software only if you have not modified the API. Distribution in compliance with the rules of mobile app marketplaces may be incompatible with compliance with certain copyleft licenses (like the GPL or LGPL).
Do not contribute to or release open source software before consulting an attorney. Contributing to and releasing open source software can be a boon for the public, but it may not be the right choice for your business. Once you make a contribution or release, any intellectual property rights you had in the software will be unlikely to form the basis for valuation of your company. Your lawyer can help you understand your choices between degrees of proprietary and open source software and guide this important business decision.
Ensure your employees and third-party developers follow these rules. Whether an open source violation is caused by your employee or a third-party contractor, the resulting legal and publicity issues will fall in your lap. You can avoid these issues through proper training and tracking of open source software.
Plan for the future. Startup business models can change rapidly, and a SaaS model can quickly become a distributed software model. Following the rules for distributed software, regardless of your current model, can provide flexibility for shifting to a distributed software model without having to remove certain open source software and change associated functionalities.
Adopting these rules will help you leverage the benefits of open source software while limiting the risk to your startup’s viability for investments and acquisitions. Third parties interested in your startup will want to know how you handle open source software. Make sure that you are prepared and able to provide them with positive and professional answers.

Estonia has long been the digital envy of many European Union member states. An effective and open policy approach to digital government has yielded extraordinary results—from 90%+ uptake of electronic identification (E-ID) solutions to an open source e-government platform (X-Road) to meet the ever-growing expectations of IT-savvy citizens as well as other countries wanting to pool IT across borders.

jani-ruuskanen.png
Estonia’s X-Road being presented by Finland’s Jani Ruuskanen
Estonia’s X-Road being presented by Finland’s Jani Ruuskanen (Photo by James Lovegrove)

It was thus fitting that Estonia, the current EU presidency, brought together Ministers from 32 countries (under the umbrellas of the EU and European Free Trade Association) to adopt the Tallinn Declaration on E-Government, creating a renewed political dynamism coupled with legal tools to accelerate the implementation of a range of existing EU policy instruments (e.g., the e-Government Action Plan and ISA² program).

Perhaps the most significant development for open source supporters is the explicit recognition of open source software (OSS) as a key driver towards achieving ambitious governmental digitisation goals by 2020. Under the declaration, European goverments will:

“Make more use of open source solutions and/or open standards when (re)building ICT systems and solutions (among else, to avoid vendor lock-ins), including those developed and/or promoted by EU programmes for interoperability and standardisation”

European Commission vice president Andrus Ansip drew attention to other OSS drivers, such as digital, open, cross-border, and interoperability by default, included in the Tallinn Declaration’s “User-centricity principles” annex. Indeed, people at events organized around the launch were buzzing about open source technologies and approaches—from blockchain in Luxembourg and Sweden to open data portals in France. A recent European Commission Communication and a Recommendation will further educate EU procurers of digital benefits and track EU member state progress.

At the close of the various workshops and keynote speeches, there was a sense of urgency to democratize transformative technology and thereby bring government closer to its citizens. There was also a feeling of inspiration because governments had found consensus for the “public sector to lead digital transformation of our society by using public procurement,” said Prime Minister of Estonia Juri Ratas. Open digital government could well be at another inflection point, which could put some large corporations to shame. In the words of Ansip, “Digital has now to become the new normal.” I think all of the 16+ million OSS developers would agree.

The author and other delegates at the EU digital government meeting.
The author and other delegates watching an acrobatics performance at the EU digital government meeting. (Photo courtesy of Estonia’s organizer)

To further the conversation about digital transformation in government, I’ll be moderating an Open Forum Europe (OFE) event on October 11 in Brussels. We will be discussing some of the concrete steps to undertake between now and the next progress checkpoint, to be held in Vienna in September 2018 under the Austrian EU presidency.

The GPL family of licenses is unique among open source licenses in how past, current, and future versions of the license may apply to the software program. By not fully understanding this unique license feature, open source software developers may inadvertently create ambiguity.

The GPL licenses clarify how license versions are to be applied to the program with a clause in their terms and conditions. The applicable language in GPL v2 (clause 9) reads in part:

“Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and ‘any later version,’ you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.”

The terms in GPL v3 clause 14 are very similar to those in the GPL v2.

Over the years, I’ve seen many open source projects that say they are GPL licensed without explicitly indicating a version number, while also including the text of an entire GPL license (e.g., v2 or v3). The ambiguity this potentially creates may be beneficial or detrimental to you, depending on factors such as whether you are the licensor or the licensee.

How the ambiguity plays out
For example, assume that an application’s license states: “This program is licensed under the GPL,” and includes a copy of the GPL v3 license in its entirety. Because the project did not explicitly communicate which version number of the license applies, a reasonable interpretation would be that any and all versions of the GPL published by the Free Software Foundation may apply—v3, v2, or even v1!

This interpretation may be justified by this sentence in GPL v3 clause 14:

“If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.”

On the other hand, including a complete copy of a particular version of the GPL (which may also include the GPL version number in the license title block) could be interpreted as, in essence, communicating a specific version of the license. In this example, v3 and only v3, because there is no “any later version” provision.

How to avoid ambiguity
To avoid this license ambiguity, you should be very clear. If you want only v3 to apply, explicitly say so: “The program is licensed only under the GPL v3” and provide the entire GPL v3 license. Or if you want v3 or any later version of the GPL to apply, explicitly state: “The program is licensed under the GPL v3 or any later version.” Last, if you really want any version of the GPL to apply, you could provide the v3 license and say: “This program is licensed under any version of the GPL published by the Free Software Foundation.”

No matter which licensing choice you make, be very clear so everyone understands what you actually mean.

Do you use “open source software” or “free software”? Although there are different rules for free software licenses (four freedoms) and open source licenses (Open Source Definition), what is not apparent from those two sets of rules is:

Both terms refer to essentially the same set of licenses and software, and
Each term implies different underlying values.
In other words, although the terms “free software” and “open source software” refer to essentially the same set of licenses, they arrive at that set via different routes. (The results aren’t perfectly identical, but the differences are unlikely to matter broadly.) And, even though the licenses are the same, a person’s choice of terminology may imply a different emphasis in values.

The concept of “free software” was developed by Richard Stallman in the 1980s. The focus is on what the recipient of software is permitted to do with the software: “Roughly, it means that the users have the freedom to run, copy, distribute, study, change, and improve the software.”

“Open source” focuses on the practical consequences enabled by these licenses: surprisingly effective collaboration on software development. Free software came first. Later, it became apparent that free software was leading to remarkable collaboration dynamics. In 1997, Eric Raymond’s seminal essay “The Cathedral and the Bazaar” focused attention on the implications that free software has for software development methodology.

In “Why Open Source Misses the Point of Free Software,” Stallman explains: “The two terms describe almost the same category of software, but they stand for views based on fundamentally different values. Open source is a development methodology; free software is a social movement.”

Different values? Yes. But not mutually exclusive. Rather than aligning with one or the other, many people find varying degrees of resonance with the values underlying each term.

Clearing the confusion
Rather than aligning with one or the other, many people find varying degrees of resonance with the values underlying each term.What if someone wants to refer to this type of software without specifying underlying values? Awkwardly, there is no broadly accepted term that refers to the licenses or the software that’s neutral about the values implied by each term. In other words, we lack a third term that refers to that same software and same set of licenses, but doesn’t take sides with respect to why that software and those licenses are significant. It may be that “open source” was initially expected to be a neutral term; however, it has developed its own implied values.
The closest to a neutral term would be FOSS (free and open source software) or FLOSS (free/libre/open source software), which have had limited success fulfilling that value-neutral role. Perhaps the existence of two such terms (with and without “L”) may have diluted and thus diminished the ability of either to break out as a broadly used term.

This assortment of terms has contributed to confusion. Would a neutral term be useful? Or is the attempt to separate the associated values a flawed goal? Is a neutral term inappropriate because there are significant free software projects that would not be considered open source? Or the reverse? Please share your thoughts in the comments.

In 2017, Opensource.com authors addressed the changing legal landscape in several intellectual property areas, including trademarks, open source licensing, and compliance. And copyright trolling continues to be of concern to many, so it’s no surprise that our most-read article answered some questions about Patrick McHardy and copyright profiteering.

Other widely read articles focused on nuts-and-bolts open source licensing topics, such as what every technologist should know and open source license management rules for startups. More philosophical pieces also captured readers’ attention, covering topics from economically efficient open source license compliance to the difference between free and open source software to free vs. freedom.

Finally, there we some reactions to a specific license proposed by Facebook, both criticizing its React license and arguing that we not over-React.

Looking ahead to 2018, all that is certain is that everything is uncertain. As the world continues to embrace open source, the legal issues surrounding it will no doubt continue to be interesting and complex.