Copyright

Copyright

a wrong idea that really flourished.

Copyright in FOSS Consulting

You know what the General Public License (GPL) is , because you are a Linux hacker, web developer, or other consultant who lives and breathes free software. You consult for clients, doing DevOps using Software Engineering tools such as Subversion, and Git or build automation like Jenkins. You work with database engines like MySQL, Postgres, and MongoDB. You do System Administration on RedHat, Ubuntu, and Debian. You build web services, proxies, reporting systems and more on Apache and Nginx web servers. You build extensions for MediaWiki, modules for Drupal, or plugins for WordPress. You do User Interface based on jQuery and JavaScript. You extend, improve or integrate GPL software and systems, that is to say 50,000 market leading, state of the art software products. You consult for companies, universities, governments, other organizations large and small and they all use boilerplate contract language that is completely oblivious of the software they are using, and the work that you are doing for them in a proper legal context. To a certain degree, this is understandable - technology changes rapidly while legal systems and bureaucracies evolve slowly.

In the definition of Copyright , the word software never appears. The phrase 'digital transmission' is the only hint of technology that was to come in the ensuing decades. In fact, section 102 on the Subject matter of copyright expressly excludes software in concept:

In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.

But in order to create an expansive copyright regime, this was interpreted to mean that the "expression" of the idea is copyrightable, while the actual methods or processes adopted by the programmer are not within the scope of the copyright law. While you chew on that for a bit, we'll get back to the point here: contract language that is GPL-aware.

It's time to have "boilerplate" contract language that understands the world we live in and is helpful to the client and contractor in clear terms.

Old-School Boilerplate

ContractStandards.com is a pretty useful website setup by Lambert & Associates (Boston, MA and Nashua, NH) that illustrates and explains in plain language the various clauses of a contract. For example, they have a page about Intellectual Property (Representation); calling it "one of the most heavily negotiated representations". (Note: you have to click on the "Clause Elements" section heading to actually view the contents.)

Unfortunately, they offer no example that would pertain specifically to a client using GPL software, and hiring a consultant with expertise in that software. If you look at their example Independent Contractor Agreement ownership is conferred 100% to the client. As in the boilerplate example, you'll likely see language from your clients about the contractor providing a "work made for hire" under the Copyright Act . This is old-school, pre-Internet mentality and legal framework (This section of the U.S. Copyright Act was updated in 1979).

So, where can we get an idea of the language to use for a client wishing to hire a consultant who would employ GPL software and intend to publish and share that intellectual property for the benefit of the client, the contractor and the world at large?

Not Viral

A lot of people seem to bury their head in the sand as the issue gets complicated. For a long time (and it still continues), the GPL was viewed as bad and labelled "viral" because if you let GPL code touch your proprietary code, you'll be forced to share your proprietary code. That's only half true. Articles like this one talk about this viral nature, but don't even touch on the other half of the story: what triggers the license. You have to "distribute" software to trigger the GPL, so if all you ever do is use the software (plus GPL additions) for your own internal purposes, then you have all the right in the world to use GPL software without having to publish your software to the world. Of course some people recognized that they could skirt the line by making "services" out of predominantly free software (e.g. an online logo generator that uses the GIMP as a backend.) Thus, the Free Software Foundation drafted the GPLv3 as a way to define network transmission of services tantamount to distributing the software. The GPLv3 license has not been as popular as the GPLv2, but at least it's there for software developers to use when they want to prevent their creations from getting boxed up in the cloud. Ultimately, using GPL software in your (commercially available and distributed) product is not different than using some other (proprietary) software -- you need the right to do it. GPL says you don't have that right unless you're willing to share. You don't want to share, then build it yourself. In-house counsel was often focused exclusively on this viral aspect and the "FOSS governance" policies that grew out of it were focused on restricting what could come in-bound to an organization. Their contracts still had the mindset that they weren't using GPL software anywhere in their organizations, including the mundane and operations related areas of the business that would never cross the "distribution" threshold. To be clear, you can -- and millions of companies do -- use Drupal for an internal website, or MediaWiki for a knowledgebase. You can even modify or extend that code to do things you need it to do. And you don't have to share your code if you don't want to.

The issue we're trying to focus on here and that very few address, is that a majority of companies not only use free software, but need commercial support for that software. They frequently want to build that extra feature or just need help deploying, integrating, upgrading and documenting it. It's not a core product. It's just some internal thing to get work done. Take for example a simple PHP application used for keeping track of Time Off, using a MySQL database backend. Should a company "own" the intellectual property associated with upgrading MySQL? It may actually be counter to the law. An author only has rights to the specific pieces of expression that they've contributed to a collaborative work so they can't claim ownership over the whole thing.

Good Examples

It was only after extensive research for this topic that I discovered the Civic Commons' Best Practices Around Procuring or Deploying OSS in Your Organization

http://teleogistic.net/2013/04/gpl-and-free-software-language-for-government-contracts/ shows a clause that was used in a University setting.

Legal explanation

The Gift that Keeps on Giving - Distrubution and Copyleft in Open Source by Heather Meeker

Contribution Agreements

• Drupal
• OpenStack
• Karl Fogel in his book "Producing Open Source Software" discusses exactly that, from soup to nuts. In it, he includes a discussion of Copyright License Agreements as well as Copyright Assignment Agreements. This is a good read for anyone producing open source software of course, but it's also a great way for a corporate attorney to get the perspective of the FOSS developer.
• Google Individual Contributor License Agreement
• Project Harmony offers not only a "harmonizing" view of Contributor Agreements, but also the inter-company contributor agreements so that employees of one organization can effectively collaborate on external FOSS projects that the company uses.
• The Civic Commons Wiki offers a complete run down of CLA and CAA examples

Further Resources

• Legal Information Institute - a project started in 1992 by the Cornell University Law School that publishes the law online, for free. See the U.S. Constitution and U.S. Code, etc.
• Copyfree, offers a collection of interesting articles, essays etc. about the problems of Copyright and offers an alternative copyright regime.
• International Free and Open Source Software Law Review is a collaborative legal publication aiming to increase knowledge and understanding among lawyers about Free and Open Source Software issues. Topics covered include copyright, licence implementation, licence interpretation, software patents, open standards, case law and statutory changes.
• Traditional treatment of the subject comes from the perspective of protecting against risks that the software is perceived to create. The Association of Corporate Counsel has this primer http://www.acc.com/legalresources/quickcounsel/quickcounsel_open_source_software.cfm While it does discuss many of the valid concerns that you would have as a corporation, it does nothing to address the proactive and beneficial things you can and should do to address the needs and benefits created by the collaboration economy.

Disclaimer

IANAL (That means I am not a lawyer.) I'm just a free software expert.

This information is here to educate, inform, and hopefully spread best practice information to other consultants and their clients alike who wish to operate in the real world that is completely full of interconnected "Intellectual Property". It is not legal advice. It should not be construed as legal advice. It does not create an attorney-client relationship. If you're an attorney reading this, I'd love to get your feedback and I hope that this information is useful to the representation you provide to your clients.