Support the Software Freedom Conservancy

The Software Freedom Conservancy is an organization which provides two useful services.

Firstly, they provide “fiscal sponsor” services for free software projects which wish to benefit from being a non-profit but which do not have the resources to set up their own Foundation. They have over 35 member projects which they support. If you use WINE, Samba, Mercurial, Inkscape, Git or any of the others, you can thank and support those projects by supporting SFC.

Secondly, if you believe that copyleft has a role (and it doesn’t even have to be an exclusive role) to play in the free software licensing ecosystem, you have an interest in making sure that copyleft licenses do not de facto become the same as permissive ones. That requires working with companies to help them understand their quid pro quo obligations to share and, rarely, taking them to court when flagrant violations are not corrected after significant time. The SFC is basically the only organization which does this valuable work, and that fact makes companies (sadly) less likely to support it.

This means that SFC greatly relies on support from individuals. I have just re-committed as a supporter for 2017 and I hope many of my readers will do the same.

GPLv2 Combination Exception for the Apache 2 License

CW: heavy open source license geekery ahead.

One unfortunate difficulty with open source licensing is that some lawyers, including the FSF, consider the Apache License 2.0 incompatible with the GPL 2.0, which is to say that you can’t combined Apache 2.0-licensed code with GPL 2.0-licensed code and distribute the result. This is annoying because when choosing a permissive licence, we want people to use the more modern Apache 2.0 over the older BSD or MIT licenses, because it provides some measure of patent protection. And this incompatibility discourages people from doing that.

This was a concern for Mozilla when determining the correct licensing for Rust, and this is why the standard Rust license is a dual license – the choice of Apache 2.0 or MIT. The idea was that Apache 2.0 would be the normal license, but people could choose MIT if they wanted to combine “Rust license” code with GPL 2.0 code.

However, the LLVM project has now had notable open source attorney Heather Meeker come up with an exception to be added to the Apache 2.0 license to enable GPL 2.0 compatibility. This exception meets a number of important criteria for a legal fix for this problem:

  • It’s an additional permission, so is unlikely to affect the open source-ness of the license;
  • It doesn’t require the organization using it to take a position on the question of whether the two licenses are actually compatible or not;
  • It’s specific to the GPL 2.0, thereby constraining its effects to solving the problem.

Here it is:

—- Exceptions to the Apache 2.0 License: —-

In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 (“Combined Software”) and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.

—- end —-

It seems very well written to me; I wish it had been around when we were licensing Rust.

Respecting the Wishes of Software Authors

Software licenses are the constitution for a community. The license a group picks for their software is indicative of how they would like their community to work. GPL-using communities have one set of norms around sharing, BSD or Apache-using communities have another way of working together. That is, of course, as long as everyone using the code plays by the rules.

Basically the only organization attempting to make sure that users of GPL code respect the wishes of the authors of that code is the Software Freedom Conservancy. As well as other excellent work like providing a financial and organizational home for projects, they enforce the GPL – most recently, after five years of fruitless negotiation, in a lawsuit against VMWare, who have taken parts of Linux and put them in their proprietary ESXi product.

Whether you are a keen user of the GPL, or of BSD, or whether you don’t much care about licensing, I hope all my readers are keen that the wishes of authors of software about what happens to it, and the obligations you have if you take advantage of their hard work, are respected. The SFC is a small charity, and corporate donations have suddenly become harder to come by now they are insisting that corporations live up to their responsibilities. (How strange…) I’m proud to say Mozilla has supported SFC in the past, and I hope we will continue to do so. But please would you also consider signing up as a supporter, at the very reasonable cost of US$10 a month.

If people don’t like the terms of the GPL, they are free to write their own software to do whatever they want done. But if they use the hard work of others to save time and effort, they need to respect the wishes of those authors. SFC makes that happen; please give them your support.

Promises: Code vs. Policy

A software organization wants to make a promise, for example about its data practices. For example, “We don’t store information on your location”. They can keep that promise in two ways: code or policy.

If they were keeping it in code, they would need to be open source, and would simply make sure the code didn’t transmit location information to the server. Anyone can review the code and confirm that the promise is being kept. (It’s sometimes technically possible for the company to publish source code that does one thing, and binaries which do another, but if that was spotted, there would be major reputational damage.)

If they were keeping it in policy, they would add “We don’t store information on your location” to their privacy policy or Terms of Service. The documents can be reviewed, but in general you have to trust the company that they are sticking to their word. This is particularly so if the policy states that it does not create a binding obligation on the company. So this is a function of your view of the company’s reputation.

Geeks like promises kept in code. They can’t be worked around using ambiguities in English, and they can’t be changed without the user’s consent (to a software upgrade). I suspect many geeks think of them as superior to promises kept in policy – “that’s what they _say_, but who knows?”. This impression is reinforced when companies are caught sticking to the letter but not the spirit of their policies.

But some promises can’t be kept in code. For example, you can’t simply not send the user’s IP address, which normally gives coarse location information, when making a web request. More complex or time-bound promises (“we will only store your information for two weeks”) also require policy by their nature. Policy is also more flexible, and using a policy promise rather than a code promise can speed time-to-market due to reduced software complexity and increased ability to iterate.

Question: is this distinction, about where to keep your promises, useful when designing new features?

Question: is it reasonable or misguided for geeks to prefer promises kept in code?

Question: if Mozilla or its partners are using promises kept in policy for e.g. a web service, how can we increase user confidence that such a policy is being followed?

An Encounter with Ransomware

An organization which I am associated with (not Mozilla) recently had its network infected with the CryptoWall 3.0 ransomware, and I thought people might be interested in my experience with it.

The vector of infection is unknown but once the software ran, it encrypted most data files (chosen by extension) on the local hard drive and all accessible shares, left little notes everywhere explaining how to get the private key, and deleted itself. The notes were placed in each directory where files were encrypted, as HTML, TXT, PNG and as a URL file which takes you directly to their website.

Their website is accessible as either a TOR hidden service or over plain HTTP – both options are given. Presumably plain HTTP is for ease for less technical victims; Tor is for if their DNS registrations get attacked. However, as of today, that hasn’t happened – the site is still accessible either way (although it was down for a while earlier in the week). Access is protected by a CAPTCHA, presumably to prevent people writing automated tools that work against it. It’s even localised into 5 languages.

CryptoWall website CAPTCHA

The price for the private key was US$500. (I wonder if they set that based on GeoIP?) However, as soon as I accessed the custom URL, it started a 7-day clock, after which the price doubled to US$1000. Just like parking tickets, they incentivise you to pay up quickly, because argument and delay will just make it cost more. If you haven’t paid after a month, they delete your secret key and personal page.

While what these thieves do is illegal, immoral and sinful, they do run a very professional operation. The website had the following features:

  • A “decrypt one file” button, which allows them to prove they have the private key and re-establish trust. It is, of course, also protected by a CAPTCHA. (I didn’t investigate to see whether it was also protected by numerical limits.)
  • A “support” button, which allows you to send a message to the thieves in case you are having technical difficulties with payment or decryption.

The organization’s last backup was a point-in-time snapshot from July 2014. “Better backups” had been on the ToDo list for a while, but never made it to the top. After discussion with the organization, we decided that recreating the data would have taken much more time than the value of the ransom, and so were were going to pay. I tried out the “Decrypt One File” function and it worked, so I had some confidence that they were able to provide what they said they were.

I created a wallet at, and used an exchange to buy exactly the right amount of Bitcoin. (The first exchange I tried had a ‘no ransomware’ policy, so I had to go elsewhere.) However, when I then went to pay, I discovered that there was a 0.0001BTC transaction fee, so I didn’t have enough to pay them the full amount! I was concerned that they had automated validation and might not release the key if the amount was even a tiny bit short. So, I had to go on IRC and talk to friends to blag a tiny fraction of Bitcoin in order to afford the transfer fee.

I made the payment, and pasted the transaction ID into the form on the ransomware site. It registered the ID and set status to “pending”. Ten or twenty minutes later, once the blockchain had moved on, it accepted the transaction and gave me a download link.

While others had suggested that there was no guarantee that we’d actually get the private key, it made sense to me. After all, word gets around – if they don’t provide the keys, people will stop paying. They have a strong incentive to provide good ‘customer’ service.

The download was a ZIP file containing a simple Windows GUI app which was a recursive decryptor, plus text files containing the public key and the private key. The app worked exactly as advertised and, after some time, we were able to decrypt all of the encrypted files. We are now putting in place a better backup solution, and better network security.

A friend who is a Bitcoin expert did do a little “following the money”, although we think it went into a mixer fairly quickly. However, before it did so, it was aggregated into an account with $80,000+ in it, so it seems that this little enterprise is fairly lucrative.

So, 10/10 for customer service, 0/10 for morality.

The last thing I did was send them a little message via the “Support” function of their website, in both English and Russian:

Such are the ways of everyone who is greedy for unjust gain; it takes away the life of its possessors.

Таковы пути всех, кто жаждет преступной добычи; она отнимает жизнь у завладевших ею.

‘The time has come,’ Jesus said. ‘The kingdom of God has come near. Repent and believe the good news!’

– Пришло время, – говорил Он, – Божье Царство уже близко! Покайтесь и верьте в Радостную Весть!

Signed Committer’s Agreements No Longer Required

For a long time, Mozilla has required people gaining commit access to our core repos to sign a Committer’s Agreement. This is not a copyright assignment or a transfer of rights; it’s basically a commitment to good behaviour, and to making sure code which gets into the tree is allowed to be there and is correctly licensed.

However, the logistics of printing it out, signing it, scanning/photographing it back in etc. were always a barrier to participation. In consultation with our legal team, we have decided that people simply assenting to the document is just as good so, as of now, people are no longer required to go through the process of signing it.

However, all people with commit access to any Mozilla repository are still expected to abide by it :-) We may be adding CONTRIBUTING files referencing the document to our Github repos to make this point more clear.

Licensing Policy Change: Tests are Now Public Domain

I’ve updated the Mozilla Foundation License Policy to state that:

PD Test Code is Test Code which is Mozilla Code, which does not carry an explicit license header, and which was either committed to the Mozilla repository on or after 10th September 2014, or was committed before that date but all contributors up to that date were Mozilla employees, contractors or interns. PD Test Code is made available under the Creative Commons Public Domain Dedication. Test Code which has not been demonstrated to be PD Test Code should be considered to be under the MPL 2.

So in other words, new tests are now CC0 (public domain) by default, and some or many old tests can be relicensed as well. (We don’t intend to do explicit relicensing of them ourselves, but people have the ability to do so in their copies if they do the necessary research.) This should help us share our tests with external standards bodies.

This was bug 788511.

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 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