When Licenses Discriminate

A long time ago, well-meaning people at the University of California, Berkeley created a license for their SPICE electronic simulation software that prohibited use by the Police of South Africa. This was, of course, during Apartheid.

Years later, Apartheid ended. The Police of South Africa now included Blacks and Whites with the same duties and powers. And they were still prohibited from using Berkeley SPICE. Getting the University of California to change the license, so that the software could be carried in Debian as “Free Software”, was impossible at the time.

I took this example (among others) and wrote into the Open Source Definition (then the Debian Free Software Guidelines) that licenses could not discriminate against persons or groups, or against fields of endeavor.

This implements a major principle of Free Software. Freedom means Freedom for Everyone, not Freedom For People I Approve Of. Even when those folks abuse the freedom of others.

Someone recently created a license that discriminates against companies that have contracts with the U.S. Immigration and Customs Enforcement (ICE), a division of the Department of Homeland Security. Ironically, this is called “Moral Programming” or “Moral Licensing”. I have to object to it on moral grounds.

I don’t approve of the recent conduct of ICE under the direction of Donald Trump and his gang. Far, far from it. I am happy to say so, to participate in protests, and most importantly, I will not vote Republican in upcoming elections.

But if you insist on denying them the right to run your software in your license, please be careful not to call it Open Source or Free Software. Because your license will not comply with the Open Source Definition or the Four Freedoms of the Free Software Foundation. Which protect Freedom for everyone.

Redis, The Commons Clause, and Adding Clauses To Open Source Licenses

Redis has recently created something called the “Commons Clause”, which takes the Apache license and makes it a non-Open-Source license. And they still call it the Apache license. This is a problem. Someone creating yet another non-Open-Source paradigm is not a problem, if they do it correctly.

Redis doesn’t deny that it’s not an Open Source license any longer once their clause is added.

It’s a bad idea to add a any text whatsoever to an Open Source license, and still call that license by it’s old name. Once the Commons Clause is added, it’s no longer the Apache license, and calling it so confuses people about what is Open Source and what isn’t. Hopefully that’s not meant deliberately. Now stop it. Take the license and the clause together, and title it the Redis license or another name of your choice that doesn’t confuse people that it’s an Open Source license. “Commons” is the name of an Apache project, so that is probably a bad choice for the name of the overall license.

You’ll note that I worked on the Business Source License with MariaDB. They paid a day’s consulting fee. I made it very clear that they were not to tell people it was Open Source, and I made changes that made the license less ambiguous and confusing than their previous version. Please follow that example.

About Steve Jobs and Lisa Brennan-Jobs

I never met Lisa Brennan-Jobs, and I only met with Steve Jobs at Pixar. When Reed Jobs was born, in 1991, Ed Catmull (then president of Pixar and now CTO of Disney) showed me the email from Steve, on his NeXT workstation, announcing Reed’s birth. Steve used a then-new feature of NeXT email to put a photo and background music in the email.

We all knew about Lisa and that Steve didn’t acknowledge her. There was a sour note as we viewed the announcement, as Steve was treating Reed’s birth with a joy that he clearly didn’t have for his relationship with Lisa.

Intel Publishes Microcode Security Patches, No Benchmarking Or Comparison Allowed!

UPDATE: Intel has resolved their microcode licensing issue which I complained about in this blog post. The new license text is here.

This was my complaint:

Intel is updating its loadable CPU microcode to handle various side-channel and timing attacks. There is a new license term applied to the new microcode:

You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results.

Since the microcode is running for every instruction, this seems to be a use restriction on the entire processor. Don’t run your benchmarker at all, not even on your own software, if you “provide” or publish the results.

The security fixes are known to significantly slow down Intel processors, which won’t just disappoint customers and reduce the public regard of Intel, it will probably lead to lawsuits (if it hasn’t already). Suddenly having processors that are perhaps 5% to 10% slower, if they are to be secure, is a significant damage to many companies that run server farms or provide cloud services. I’m not blaming Intel for this, I don’t know if Intel could have forseen the problem. Since some similar exploits have been discovered for AMD and ARM CPUs, the answer is probably “no”. But certainly customers are upset.

Another issue is whether the customer should install the fix at all. Many computer users don’t allow outside or unprivileged users to run on their CPUs the way a cloud or hosting company does. For them, these side-channel and timing attacks are mostly irrelevant, and the slowdown incurred by installing the fix is unnecessary.

So, lots of people are interested in the speed penalty incurred in the microcode fixes, and Intel has now attempted to gag anyone who would collect information for reporting about those penalties, through a restriction in their license. Bad move. The correct way to handle security problems is to own up to the damage, publish mitigations, and make it possible for your customers to get along. Hiding how they are damaged is unacceptable. Silencing free speech by those who would merely publish benchmarks? Bad business. Customers can’t trust your components when you do that.

In writing this story, I used news in this article in The Register and this copy of the license. That’s all the information I have on this issue, at this writing.

Status of Open Source Security Inc. / Bradley Spengler v. Bruce Perens lawsuit

Last year, Open Source Security and its CEO, Bradley Spengler, brought suit against me for defamation and related torts regarding this blog post and this Slashdot discussion. After the lower court ruled against themI asked for my defense costs and was awarded about $260K for them by the court. The plaintiffs brought two appeals, one on the merits of the lower court’s ruling and one on the fees charged to them for my defense. In order to bring these appeals without first paying for my defense, the plaintiffs purchased a supersedeas bond for $300,000, for the cost awarded to me plus possible interest, which will be paid to my attorneys if I win the appeals. The Electronic Frontier Foundation took on the merits appeal, pro-bono (for free, for the public good), with the pro-bono assistance of my attorneys at O’Melveny who handled the lower court case. EFF has now filed an answering brief and supplemental excerpts of the record in the merits appeal. Please join EFF and support them. You can follow the court proceedings here. I will continue to publish what’s happened in the court, but can’t comment upon the case at this time.