Copyright and Software

As part of our discussions on responding to the EU Copyright Consultation, Benjamin Smedberg made an interesting proposal about how copyright should apply to software. With Chris Riley’s help, I expanded that proposal into the text below. Mozilla’s final submission, after review by various parties, argued for a reduced term of copyright for software of 5-10 years, but did not include this full proposal. So I publish it here for comment.

I think the innovation, which came from Benjamin, is the idea that the spirit of copyright law means that proprietary software should not be eligible for copyright protections unless the source code is made freely available to the public by the time the copyright term expires.

We believe copyright terms should be much shorter for software, and that there should be a public benefit tradeoff for receiving legal protection, comparable to other areas of IP.

We start with the premise that the purpose of copyright is to promote new creation by giving to their authors an exclusive right, but that this right is necessary time-limited because the public as a whole benefits from the public domain and the free sharing and reproduction of works. Given this premise, copyright policy has failed in the domain of software. All software has a much, much shorter life than the standard copyright term; by the end of the period, there is no longer any public benefit to be gained from the software entering the public domain, unlike virtually all other categories of copyrighted works. There is already more obsolete software out there than anyone can enumerate, and software as a concept is barely even 50 years old, so none is in the public domain. Any which did fall into the public domain after 50 or 70 years would be useful to no-one, as it would have been written for systems long obsolete.

We suggest two ideas to help the spirit of copyright be more effectively realized in the software domain.

Proprietary software (that is, software for which the source code is not immediately available for reuse anyway) should not be eligible for copyright protections unless the source code is made freely available to the public by the time the copyright term expires. Unlike a book, which can be read and copied by anyone at any stage before or after its copyright expires, software is often distributed as binary code which is intelligible to computers but very hard for humans to understand. Therefore, in order for software to properly fall into the public domain at the end of the copyright term, the source code (the human-readable form) needs to be made available at that time – otherwise, the spirit of copyright law is not achieved, because the public cannot truly benefit from the copyrighted material. An escrow system would be ideal to implement this.

This is also similar to the tradeoff between patent law and trade secret protection; you receive a legal protection for your activity in exchange for making it available to be used effectively by the broader public at the end of that period. Failing to take that tradeoff risks the possibility that someone will reverse engineer your methods, at which point they are unprotected.

Separately, the term of software copyright protection should be made much shorter (through international processes as relevant), and fixed for software products. We suggest that 14 years is the most appropriate length. This would mean that, for example, Windows XP would enter the public domain in August 2015, which is a year after Microsoft ceases to support it (and so presumably no longer considers it commercially viable). Members of the public who wish to continue to run Windows XP therefore have an interest in the source code being available so technically-capable companies can support them.

Adventures On The Silk Road

A man, Ross William Ulbricht, has been arrested and charged with being the operator of the “Silk Road” Tor hidden service, which was a marketplace dealing mostly in illegal objects and substances.

The court document is absolutely fascinating, and gives many interesting details of Silk Road’s operation. One tale in particular caught my eye, detailed on pages 21-23. The FBI agent who wrote this document knows how to tell a good story.

A user called FriendlyChemist on Silk Road threatened to reveal the identities of thousands of Silk Road users (which he had obtained by hacking a vendor), unless he was paid $500,000, which he needed to pay off his drugs suppliers.

DPR asked FriendlyChemist to get those suppliers to contact him. A user called redandwhite appeared, saying he was representing the people concerned. DPR first tried to recruit him as a Silk Road vendor, and then (when FriendlyChemist persisted in his threats) hired redandwhite to kill FriendlyChemist for a sum of $150,000, passing on his name and address (in White Rock, British Columbia, Canada). Later, redandwhite messaged back to say “Rest easy, though, because he won’t be blackmailing anyone again. Ever.” He even provided a photo as proof.

The end of FriendlyChemist? Perhaps not. The court document goes on to say: “Canadian law enforcement authorities … have no record of there being any Canadian resident with the name DPR passed to redandwhite as the target of the solicited murder-for-hire. Nor do they have any record of a homicide occurring in White Rock, BC, on or about March 31, 2013.”

Looks like DPR may have been the subject of a beautifully-executed sting…

MPL 2 Upgrade Process Complete

With the closure of the bug for Hackasaurus, we have now finished the 19-month MPL 2 upgrade project :-) All Mozilla software which used to use the tri-licence now uses the MPL 2.

Particular thanks go to Francesco “flod” Lodolo, who was the driving force behind the last big push to get the outstanding l10n repos relicensed.

(A post like this one is, of course, begging for someone to point out some files I may have missed. There are still a few tri-licensed files in the tree because they come from upstream projects that still use that licence. If you still think I’ve missed something, please file a licensing bug.)

Copying Permissively-Licensed Code Into MPL 2 Files

Mozilla has always used some permissively-licensed (MIT/BSD) code, and more recently started using and now creating (most prominently in Gaia) Apache 2-licensed code. This has made some questions about what to do when copying code between files of different licenses more pressing.

To help, the licensing team have produced a document on what to do when you want to copy permissively-licensed code into files which are under the MPL 2.

Using MPL Code In An (L)GPL-Licensed Project

One new feature of the MPL 2.0 is that it allows you (without dual-licensing) to incorporate MPL 2.0 files into a larger project licensed under the GNU GPL or LGPL.

We’ve written a document to help developers who want to incorporate MPL 2.0 code into (L)GPL-licensed projects. It explains what to do with the boilerplate, and how best to respect the intention of upstream developers.

Niche, but useful if you’re in that niche :-)

An Introduction to Modern Open Source Licence Patent Clauses

I bet that title sent shivers of pure pleasure up and down your spine, didn’t it? :-) This post explains why all modern open source licences have patent clauses, what they do (and don’t do), and why you should use and recommend licences which contain them. This question is relevant to discussions of licence choice.

I am not a lawyer, although I do sometimes play one in real life. If in doubt, consult the real deal.

This analysis will focus on the 3 most popular modern licences with patent clauses – the Apache License 2.0 (“APL”), the Mozilla Public License 2.0 (“MPL”), and the GNU General Public License 3.0 (“GPL”).

What Do They Do?

The APL (section 3) and the MPL (section 2.1, 1.11, 1.2, 1.3) say that if you make a contribution to the code, you have to grant all users a licence to any patent you hold which is infringed by your contribution, or by the whole thing as a result of adding your contribution. In the case of the GPL (Section 11, para 2), you have to grant a licence to any patent you hold which is infringed by any part of the modified work, at the time you contributed to it, whether you wrote or changed that part or not. So the GPL’s grant is wider in scope than the other two.

The above affects contributors. There are also clauses which relate to users. In the case of the MPL (section 5.2) and the GPL (section 10, para 3), you lose your right to use the software at all if you launch a patent suit against someone else regarding that software. In the case of the APL (section 3), you lose any patent licences you might have got to the code (which may be none), but you don’t lose your copyright rights.

What Don’t They Do?

In the case of the APL and MPL, they don’t make a contributor grant a licence to patents which the code already implemented before they came along, or which someone else made the code implement while they were contributing. In all cases, if the code is changed in the future by someone else to implement a patent, the licences don’t make the contributor grant a licence to that patent. (I.e. if BigCorp has a patent on the Bar algorithm, and they contribute some non-Bar-related code to project Foo, you can’t get a free license to the Bar patent by changing Foo to implement it.) And they don’t protect you at all from the patents of people who are neither contributors nor users, including patent trolls.

Why Are They Good?

  • They provide some protection to stop one member of the community suing another one. This particularly applies to the MPL and GPL, which rescind all rights (including copyright rights) to the code when a suit is filed, thereby giving the small, patentless guy some power when this happens.
  • Relatedly, they make big companies much more comfortable about collaborating on a codebase together. Without a patent licence, the first big company you recruit to work on your code will scare off any additional ones, because they are concerned about the first company’s patents.
  • If your code is widely-enough used, it provides some protection from third parties who would not want to lose their rights to use it.

Patent clauses do not solve the software patent problem. But they do mitigate it and, in the presence of the problem, they do help build collaborating communities. That is why all modern open source licences have a patent clause, and why you should only use and promote licences which have them, and encourage others to do the same.

Relicensing: When Do You Have To Ask?

When an open source project or codebase is considering a move from one licence to another, one question which may affect whether they go ahead or not is whether they have to track down and ask permission of all the contributors. (Another question is how many people will be upset by the change; that is out of scope here. This post is about what is possible, not about what is wise.)

By “relicensing”, I mean “make it so that the code can only be used by following the terms of the new licence”. This is distinct from dual-licensing, where the code can be used under either set of terms. For example, jQuery is dual-licensed MIT/GPL, and so it can be used and redistributed under MIT, or GPL, or both.

When you relicense, you may have to continue following the terms of the old license as well, or you may not – it depends on the exact licences concerned. If a project moves from the MIT licence to the GPL licence, users would need to obey both sets of terms – although the MIT requirements are a tiny subset of the GPL ones; the only relevant term in the MIT licence is “preserve this notice”. By contrast, if a project moves from LGPL 2.1 to GPL, as permitted by LGPL section 3, then you delete the LGPL boilerplate and replace it with the GPL one, and only GPL terms apply from then on.

So when do you have to ask in order to relicense? You don’t have to ask if:

  • The project has formally aggregated copyright (e.g. each contributor has signed a CLA), and the aggregate copyright holder agrees; or
  • The move is to a later version of the same licence, and either the license allows that (e.g. the MPL), or the license boilerplate on the files permits it (e.g. the standard GPL boilerplate); or
  • The move is to a “compatible” license.

The last bullet is a tricky one; what makes two licenses, A and B, compatible? “Compatible” is a word used with regard to licences in a number of senses. Here, I mean that it’s possible to migrate from users/distributors being required to obey License A to users/distributors being required to obey License B (and possibly A as well; see above). The first thing to note is that compatibility of this sort is not symmetric – A → B does not imply B → A. To be certain in any case requires an analysis of the two texts, but in general:

  • Two permissive licenses are compatible if the terms of A are a subset of, or can be complied with at the same time as, the terms of B.
  • Permissive licenses are usually compatible with copyleft licenses, with the notable exception (according to the FSF) of Apache Public License 2.0 → GNU General Public License 2.0.
  • Two copyleft licenses are not compatible unless A has a specific provision which allows relicensing under B.
  • Copyleft licenses are never compatible with permissive licenses (that would destroy the copyleft).

Being specific, the following compatibility diagram, while incomplete, may help with the most common open source licenses. “+” means “or later” where such a clause is optional.

MIT/BSD → Apache 2.0 → MPL 2.0 → LGPL 2.1+ → GPL 2.0+
                                      ↓         ↓
                                 LGPL 3.0+ → GPL 3.0+ → AGPL 3.0+

This diagram is meant as a guide only, and does not cover some particular twists; for example, it does not reflect the Apache 2.0/GPL 2.0 incompatibility, and you can only relicense from the MPL to a GPL license if you combine with existing GPLed code and dual-license the MPLed part. But it gives the general idea.

A separate question is: what boilerplate headers do I put on the relicensed files? A big part of that question is whether you end up having to obey both licences or just the new one, and that depends on the two licences concerned. So this question is complicated enough that it’s best to ask for advice for any specific case. (But implementing the answer is probably a lot easier than chasing down hundreds of contributors!)

Mozilla and Non-Copyleft Licensing

[tl;dr: starting a discussion in mozilla.legal about the appropriate role of non-copyleft licenses with respect to Mozilla-originated projects.]

For a long time now, the Mozilla License Policy has said, paraphrasing, that new codebases written by Mozilla should use the MPL. (When we contribute to projects created by others, we have a policy of using the licence which that project uses.)

Reality does not entirely agree. Over the last few years, some new codebases have been created under various non-copyleft licences, such the BSD licence and Apache License 2.0. Examples include many of our websites, shumway, and Gaia.

The MPL was created as an intermediate stage between the copyleft of the GPL and the non-copyleft of licences like the BSD license. It has served us well in that role for many years.

It has been argued that copyleft, such as that in the MPL, is not particularly useful in the case of websites, because the MPL contains no source distribution requirement for network apps. The question of adding such a requirement was specifically excluded from the scope of the MPL 2 discussions. However, as we move more towards mobile “web apps”, where significant amounts of the code do live on end-user devices, copyleft has become more relevant again.

Copyleft is a tool which we use to achieve particular ends. The leadership of some Mozilla projects, such as Gaia and AMO, have decided that it is not the best route to success, as they define it, for their projects.

So, the first question is: if use of non-copyleft licenses has become a practice, is it a good practice? We should revisit why Mozilla chose copyleft of “MPL strength” in the first place and whether those reasons still apply today, and if so, in what context.

Secondly, if we decide that there is a reasonable and valid demand in the Mozilla community to allow projects to choose non-copyleft licensing, which licence(s) should we permit? Should we just allow people to choose any open source licence? Or any popular one? Or should we be more prescriptive?

One excellent feature of the MPL is that it offers a level of patent protection to contributors. Patents are rapidly becoming even more of a factor in software development, and anything we can do to protect our software ecosystems from the damage caused by patent lawsuits is worth it. This particularly applies to communities where large numbers of competing companies may be taking part – such as B2G. The licensing team is strongly of the opinion that patent protection is an essential part of a modern open source licence.

The equivalent non-copyleft licence to the MPL, in this regard, is the Apache License 2.0. It, like the BSD and MIT licences, is upwardly-compatible with the new MPL 2, but unlike those two licences features a patent protection clause to give companies contributing to a shared Apache 2.0 codebase confidence that other contributors will not turn around and sue them.

My proposal therefore is this:

  1. We should attempt (although this may be difficult) to reach consensus on what sort of projects are best served by what sort of licences, and what scope of copyleft.
  2. We should update the licence policy to permit, via consultation with the licensing team, use of either the Apache License 2.0 or the MPL 2.0 for projects. The exact decision process here would depend on the outcome of 0).
  3. We should clearly and by name forbid the use of other licences for Mozilla-originated codebases, without specific permission and in exceptional circumstances.
  4. We should talk to existing Mozilla projects which are using BSD and MIT and see if there are particular reasons for not using the Apache License. If there isn’t, we should transition; if there is, we should evaluate those reasons against our licensing goals.

Join the discussion in mozilla.legal.

Cut Off From My Own Creations

In 2005 and 2006, I wrote a fortnightly series of online-only columns for The Times newspaper. I attempted to get them to agree to a free content license for the text, but I was unsuccessful. At that time, there were far fewer precedents for that sort of thing, and I didn’t have nearly enough clout to persuade them to make an exception for me.

Still, I decided that the experience was probably worth it, and the money was useful. (Although my cousin, who is in the publishing industry, told me later that they paid me significantly under the going rate; and they also paid on 45-day terms, which I think is pretty shoddy behaviour.) I wrote a couple of pieces with which I was really quite pleased. And I was happy that, even if I didn’t have full rights, everyone could read them. I eventually stopped submitting work when my editor stopped replying to my emails.

Recently, revising my website, I came across the page where I linked to them all – but they are no longer available to read on the public web. They are behind the Times’ paywall. And, although I do have copies of the text I submitted, because I don’t own the rights, I can’t put up mirrors. So, I can no longer share my creative work with people who might want to read it.

Lesson learned: only release your creative work under free content licenses.

Another Victory: More Germans Protected

Regular readers of this blog may remember some of my chronicles, under the name “Protecting Germans”, of the efforts of our German legal team to deal with “subscription trap” websites, which are particularly a problem in that country. Such sites try and trap you into signing up for a subscription to get software which is available for free download elsewhere. Firefox is regularly abused as one of the popular software programs whose ‘availability’ prompts users to register on such websites.

Now, I am pleased to be able to tell you that a couple of months ago, in the Hamburg criminal court, sentence was passed on 7 operators of such fraudulent download websites, handing down sentences of 3 years and 9 months for the ringleader, and shorter sentences and fines for the other accused. This is the first ever criminal trial against the operators of subscription trap sites, and the judgment has been eagerly awaited by the public prosecutors in other German cities, who are building cases against other people involved in such schemes.

It is important to note that the court partly founded its judgement on the infringement of Mozilla’s trademarks. The main focus of the proceedings from the outset was on criminal fraud (vis-à-vis the consumers) and the trademark infringement claims were only given their due attention and relevance as a result of our supportive work. (Mozilla participated in the proceedings as one of the harmed rights-owners.)

Furthermore, the main proof which persuaded the court of the defendants’ intention to infringe Mozilla’s trademarks was their knowledge of the civil injunctions we had obtained as early as 2007 and 2009 against two of their websites.

We therefore feel that our support and participation in the proceedings was truly significant and worthwhile. The German press has been applauding the decision, which will hopefully set a precedent for other criminal proceedings against online fraudsters.

I personally feel that this is a vindication of our policy of maintaining and defending the Mozilla trademarks, and especially the Firefox trademark.

You can also read the official Mozilla blog post about this.

The ‘other-licenses’ Directory: Don’t Use It

This is a public service announcement. There is a top-level directory in mozilla-central (and similar repos) called “other-licenses”. Don’t put any more code in it. Really. There’s now even a README saying so.

Longer version: this directory is not for non-MPLed code, it’s for non-MPL-compatible code, of which we have very little. There is some stuff in there which shouldn’t be, but let’s not make it worse, OK? :-) Keep your code where it logically lives; don’t make your life harder than it needs to be. If you really think you are importing code which needs to be in there, you should be talking to licensing@mozilla.org first (as with any code import) and explicitly saying you think that this is where it should go, so they can tell you that you’re wrong ;-)

Lindholm’s Law

If you are a software engineer, or in fact any sort of engineer, I strongly suggest you take careful note of what I will call “Lindholm’s Law”:

Never send a recorded communication containing a statement of opinion or decision on an IP-related legal question to someone who is not a lawyer.

Tim Lindholm’s unfortunate statement, contained in an email which was the subject of heavy legal argument in Oracle vs. Google, was:

We conclude that we need to negotiate a license for Java under the terms we need.

Even though one of the addressees of the email was a lawyer, and even though the email said “Attorney Work Product” and “Google Confidential” at the top, the court ruled that it was not attorney-client privileged, and could be used by Oracle in court. Read why.

Mozilla and Patents

Harvey Anderson, Mozilla’s General Counsel (that is, chief lawyer), has written a couple of blogposts recently on Mozilla and software patents.

  • The first was about the Microsoft purchase of the AOL/Netscape patents;
  • The second contains some more general thoughts on Mozilla’s patent strategy.

Also noteworthy is Twitter’s announcement today of the “Innovator’s Patent Agreement” (IPA), a model agreement for companies to come to with their employees, such that the company can still file for patents on the employee’s inventions but those patents can only be used defensively. You can read the draft IPA on GitHub, and even fork it and submit pull requests :-)

EU is 113% Democratic

You couldn’t make it up. The vote on an amendment to some “orphan works” legislation in the EU’s Legal Affairs committee (which has the responsibility of “safeguarding the integrity and trustworthiness of the legal framework as a whole in Europe”) was lost 14 votes to 12. Nothing wrong with that, except that there were only 23 voting members. In other words, there was a 113% turnout – a figure of which Vladimir Putin or Robert Mugabe would be proud.

When it was pointed out that these 3 phantom votes could have affected the outcome, a re-vote was nevertheless denied.

Front-runner for “understatement of the year” goes to Christian Engström, Member of the European Parliament for the Swedish Pirate Party, who said:

“What can I say? There is a lot of room for improvement when it comes to democracy in the European Union.”