SCALE 8x: Free software legal issues

The casual view of open source software is that the code always comes first: releases are made when the code is ready, new contributors prove their chops by the quality of their code, and so forth. But in reality the FLOSS ecosystem relies on a complex legal framework in order to run smoothly and to stand up to proprietary software competition: the various software licenses, contribution agreements, copyright and other "intellectual property" law. Every once in a while, a good status check on the legal dimension is healthy for the typical developer, and SCALE 8x offered just that in a series of talks.

Red Hat's licensing and patent attorney Richard Fontana spoke about improving the intra-community open source legal system, Bradley Kuhn of the Software Freedom Conservancy and Software Freedom Law Center (SFLC) spoke about the nuts-and-bolts of bringing GPL violators into compliance, and SFLC counsel Karen Sandler presented a primer on the often misunderstood realm of trademark law.

Brave New World

Fontana's talk "Improving the Open Source Legal System" began by exploring how the real-world practices of the open source software community diverge from the legal realities on which the community depends. He then questioned what the differences reveal about the structure of the community, and suggested steps that major players like Linux distributions and large software projects could take to shore up some of the common misunderstandings and loopholes.

The conventional view of the software licenses that define FLOSS is that they are exotic variants of the licenses that govern the proprietary software market, Fontana said. They impose restrictions, albeit strange ones, and although there are peculiarities, similar peculiarities are found in contracts in the proprietary world, too. Ultimately, as in the proprietary world, participants comply with the licenses to minimize their own risk (in particular, the risk of litigation).

But in actuality, he continued, the FLOSS community acts according to a very different set of rules that are unique to the community. For example, the territoriality of licenses is almost universally ignored: developers act as if there is one, worldwide interpretation of the GPL, which is simply not true. The governing law of different countries can impose different restrictions, such as what constitutes software "distribution" (an example that the Free Software Foundation worked hard to correct for GPLv3 by using different language, such as "convey"). Proprietary companies take full advantage of the differences in local law, but virtually no one in most open source projects knows or cares what the governing law is in their case.

Similarly, there appears to be a set of widely-accepted functional rules for interpreting licenses that has arisen in practice outside of copyright law itself. For example, Fontana said, it is accepted universally that one can add BSD-licensed code to a GPL-licensed project, but in many jurisdictions the law states that a license (in this example, the BSD license) must explicitly address sublicensing or such sublicensing is not allowed.

Rather than strictly conforming to the legal system, Fontana continued, FLOSS functions on its own set of customs. They seem to be rational, but there is no formal description of them (which makes educating newcomers a problem), there are no institutions to handle dispute resolution, and some of the rules may not reflect real consensus. In the long term, this poses a problem for the legitimacy and rationality of FLOSS, he concluded. If we believe in free software ideals, we should strive to make FLOSS law meaningful and rational.

Fontana proposed several steps that vendors, projects, and distributions could take to better rationalize the system. These players should discuss and hopefully come to broad agreement on the boundaries between free and non-free behavior — acts such as nominally free projects shipping non-free code, putting portions of their code under non-free licenses, or applying anti-free interpretations to the licenses. They should also address murky "outbound licensing" issues such as how GPL and non-GPL code can coexist when shipped by the same project, and "inbound licensing" issues such as accepting code contributions without explicit copyrights and licenses attached.

The actual steps that Fontana recommends projects, distributions, and license stewards take come down to documentation and policing. Projects should publicly document their interpretations of licenses and definitions (something that some, like Debian and Fedora, already do). Distributions should document policies for code contributions and carefully police the licenses of the code they include. It is legally acceptable for the FLOSS community to have its own set of governing customs and traditions, but by and large, those customs are not yet documented and assembled — and they should be, for the long-term health of open source.

Lawyers, Code, and Money

Kuhn's talk "Demystifying GPL Enforcement" illuminated one of those traditions: what actually happens when a company is accused of violating the GPL by not the providing source code to a GPL-licensed upstream project (such as the kernel or the BusyBox utility) incorporated in its product. Kuhn works in GPL enforcement both for the SFLC, and as president of the Software Freedom Conservancy, the nonprofit group legally authorized by BusyBox (among other projects) to act on its behalf in enforcement.

Kuhn outlined best practices for doing compliance-friendly development, explained the different compliance options and the pros and cons of each, an outlined what SFLC does when it finds a GPL violation.

For the clueful, he said, avoiding violations in simple — many companies just don't take the steps. Violating companies, for example, never use version control, much less pull in GPL code from upstream as a "vendor branch." They also tend not to tag their releases, document or version their build process, or other common practices in free software projects. The result is that when someone makes a request for source code, it is impossible for the company to comply.

On top of that, he said, the companies he encounters in enforcement actions always make compliance more difficult for themselves by choosing the most arduous source code distribution options. The GPL allows several choices: include the source alongside the binary, make an offer to send the source code to anyone who requests it, and (in version 3), make it available through a peer-to-peer system.

By far the simplest option is including the source alongside the binary, said Kuhn, because the company's obligation ends immediately. In contrast, the offer to send source code upon request must be honored for three years after the last ship date of the project, applies to anyone (not just customers) and is considerably more logistically arduous. But most violators choose the "offer" option, he said, because they want to gamble that no one will actually request the code. They should assume otherwise, he said, since even if no one else ever requests the source code, Kuhn himself will.

That request is how an enforcement action begins; if the company does not comply, the SFLC sends a formal letter directed to the legal counsel or CEO, and attempts to open up active discussions on how to bring the vendor into compliance. Most of the time, the channel of communication is opened. The SFLC makes a series of standard requests, and works with the company to come into compliance on all FLOSS-copyrighted software incorporated in their products. The requests include putting the proper processes into place (including not just the development processes mentioned above, but keeping appropriate records and appointing someone in the company to be in charge of GPL compliance), notifying past recipients of the violating product that source code is now available, and for a financial settlement.

The settlement money is at times controversial, but Kuhn explained that it has several purposes. First, if there was no penalty to GPL violation other than coming into compliance, no one would proactively comply. Second, given that there must be a deterrent, the SFLC feels that GPL violators should bear the cost of defending GPL-licensed software projects — not companies who uphold the GPL, and not individual free software developers. SFLC is a nonprofit, he added, and does not get rich from settlement money. In fact, its status as a nonprofit entity enforces a degree of transparency on the entire enforcement process, with records on file with the IRS.

Only in rare cases does a GPL enforcement action result in a lawsuit, Kuhn said. It has happened in the past, but only after a complete breakdown in communication, and after considerable effort to bring the company into compliance. Kuhn prefers to to think of every GPL violator as a potential new contributor to the FLOSS community, and tells himself that every time he picks up the phone to make a request for source code.

GPL enforcement clarifies that there is one community, with one set of rules — not one set for those who choose to participate, and one for those who choose to remain ignorant. Enforcement itself shows that the community's rules are meaningful, he said, and doing it through a nonprofit group like the SFLC takes the burden off of the individual developers, who don't have the time to pursue violations themselves.

On your mark, get set...

Sandler's talk "What You Need to Know About Trademarks" addressed the legal concept of trademark, the understanding of which (like copyright) is vital to the health of free software projects. A trademark lets a small project protect and defend its identity even against well-funded competitors, but it is a very different animal than a copyright, which forms the foundation of FLOSS software licenses.

Copyright is granted automatically when a work (including software) is created. In contrast, a trademark is created automatically when it is used. The mark, whether a logo or a name, does not need to be registered; instead it is earned and strengthened by its usage. The more one uses a trademark, the stronger it is when challenged in court. Trademarks are also not subject to expiration terms like copyrights; as long as they are continually used, they do not ever expire and enter the public domain.

The legal test for trademark violation is in "the eye of the beholder" — almost literally. The test, Sandler said, is whether or not there is an identity associated with the mark in the public eye. In other words, when a person sees the mark, do they associate it with a particular product. Trademarks are limited by political geography, with different laws in different countries, and are only applicable to the industry or field-of-use in which the trademark is used.

Trademark law does have parallels to more familiar copyright law concepts, though. Where copyright has the doctrine of "fair use" protecting citation, commentary, and parody, trademark has "nominative use" which protects the use of marks to refer factually to the actual trademarked product. In other words, stores can use trademarked names and logos to advertise that the products mentioned are for sale, without seeking permission.

Sandler also addressed two trademark uses of interest to FLOSS software projects: developing a trademark for a project, and responding to "nastygrams" from hostile trademark holders.

Choosing a good trademark involves picking a distinctive name or logo. Commonly-used terms associated with the product cannot be trademarked, and choosing a good mark can be difficult. Sandler recommends doing a trademark search; unlike patents there is no doctrine of "willful infringement" in trademark — trademark infringers are just ordered to stop using the mark. But projects should be careful about their trademarks; registering a trademark is not required, but if it is done, she recommends having the group apply for it collectively, not leaving it up to an individual. An individual holding the mark could leave or fork the project later, thus making it very difficult for the group to regain control. Projects should also create a trademark policy, stating acceptable uses, naming conventions, and merchandising policy — not doing so could create confusion later, ultimately diluting the mark.

Finally, Sandler addressed what to do if a trademark holder accuses a software project of infringing on its mark. The principle question to ask is if the accused usage is genuinely likely to create confusion in consumers. Are the marks similar? Are they in the same field-of-use? Do they give the overall impression of being related products? And, most importantly, does the accuser know of actual cases of consumer confusion? If the answer is no, then there is likely no real infringement. A project should begin by asking those questions, and only needs to worry or seek legal advice (including from SFLC) if the accuser continues.

I learned the law, and we all won

All three talks touched on one common problem: that free software developers are not lawyers, and often prefer not to dwell on potentially thorny legal issues. But the law should not be intimidating to FLOSS software projects; it protects them from abuse by well-heeled enemies, and although it is a different domain, it is certainly well within the grasp of anyone capable of writing device drivers, 3-D animation studios, or any of the other top-notch projects produced by the open source community.