A little while back, I wrote a piece outlining the case for the total abolition (or non-introduction) of software patents, as seen through the lens of “promoting innovation”. Few of the arguments are new, but the “Narrow Road to Patent Goodness” presentation of the information is quite novel as far as I know, and may form a good basis for anyone trying to explain all the possible problems with software (or other) patents.
You can find it on my website.
I found this when going through old documents. It looks like I wrote it and never posted it. Perhaps I didn’t consider it finished at the time. But looking at it now, I think it’s good enough to share. It’s a redrafting of the BSD licence, in poetic form. Maybe I had plans to do other licences one day; I can’t remember.
I’ve interleaved it with the original license text so you can see how true, or otherwise, I’ve been to it. Enjoy :-)
Copyright (c) <YEAR>, <OWNER> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
You may redistribute and use –
as source or binary, as you choose,
and with some changes or without –
this software; let there be no doubt.
But you must meet conditions three,
if in compliance you wish to be.
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
The first is obvious, of course –
To keep this text within the source.
The second is for binaries
Place in the docs a copy, please.
A moral lesson from this ode –
Don’t strip the copyright on code.
The third applies when you promote:
You must not take, from us who wrote,
our names and make it seem as true
we like or love your version too.
(Unless, of course, you contact us
And get our written assensus.)
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
One final point to be laid out
(You must forgive my need to shout):
THERE IS NO WARRANTY FOR THIS
WHATEVER THING MAY GO AMISS.
EXPRESS, IMPLIED, IT’S ALL THE SAME –
RESPONSIBILITY DISCLAIMED.
WE ARE NOT LIABLE FOR LOSS
NO MATTER HOW INCURRED THE COST
THE TYPE OR STYLE OF DAMAGE DONE
WHATE’ER THE LEGAL THEORY SPUN.
THIS STILL REMAINS AS TRUE IF YOU
INFORM US WHAT YOU PLAN TO DO.
When all is told, we sum up thus –
Do what you like, just don’t sue us.
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.
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:
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.
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.
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 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.
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:
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 blockchain.info, 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!’
– Пришло время, – говорил Он, – Божье Царство уже близко! Покайтесь и верьте в Радостную Весть!
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.
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.
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.
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…
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.)
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.
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 :-)
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”).
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.
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.
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.