Sunday, June 30, 2013

Permissive Licenses and Richard Stallman's Blindspot on the Rails Community

Recently, I had to go through a very, very difficult contract negotiation that hinged largely upon the inclusion of open source software in client deliverables. Suffice it to say, that at this point, I'm fairly convinced that L/GPL licensed software simply cannot be included in software deliverables if the client intends to a) distribute that software and b) include trade secrets or confidential information in that software. It may be technically possible, but it is a huge nightmare-headache. 

As a result, I took a second look at this essay, by Richard Stallman, arguing that LGPL is, in fact, too lenient in its requirements, and that people releasing open source libraries should really think about releasing them under GPL. The gravamen of his argument is this:

If we amass a collection of powerful GPL-covered libraries that have no parallel available to proprietary software, they will provide a range of useful modules to serve as building blocks in new free programs. This will be a significant advantage for further free software development, and some projects will decide to make software free in order to use these libraries. University projects can easily be influenced; nowadays, as companies begin to consider making software free, even some commercial projects can be influenced in this way. 
Proprietary software developers, seeking to deny the free competition an important advantage, will try to convince authors not to contribute libraries to the GPL-covered collection. For example, they may appeal to the ego, promising “more users for this library” if we let them use the code in proprietary software products. Popularity is tempting, and it is easy for a library developer to rationalize the idea that boosting the popularity of that one library is what the community needs above all.
In other words, Stallman is concerned that unless software is GPL licensed, then:

1. The free software movement will be left behind.
2. Proprietary software developers actively seek to crush the software industry, and won't contribute to free software.

Both of these statements, in practice, have turned out to be false, and the proof is in the pudding:

The entire Ruby on Rails community is based on free software - either under the Ruby license, the MIT license or the BSD license, and almost never on the GPL license, probably for the reasons I explained above. Node.js is MIT Licensed. So is JQuery. Stackoverflow is brimming to the rafters with employees of the 'proprietary' software industry. These are the tools of choice for many of your favorite web services, and their users are very much in the for-profit business.

Richard Stallman's fears have simply failed to materialize. The modern web uses permissively licensed software as its lifeblood, and, quite frankly, copyleft licenses are often directly in tension with the perfectly reasonable goals of both public and private interests.

So, in the end, I believe the very mechanisms that Mr. Stallman envisioned would result in GPL licensed software becoming the norm for best coding practices and the gold standard for quality software, have in fact relegated GPL software to the domain of academics and those who do not have to deal in trade secrets or deal with covered information (note/update: however, that Linux is in fact GPL licensed - I should say specifically that we are talking about the world of commercially developed and provided SaaS). The upside is that the community of sharing that Mr. Stallman had envisioned has come to exist - it just so happens that it exists under permissive licenses, not copyleft licenses, and the community is populated by a whole lot of people who develop proprietary software.

Friday, June 21, 2013

Legalese or Plain English? Either Way, TechCrunch has it Wrong

There was a post today on TechCrunch about a VC that uses a plain english term sheet, as if this were some earth-shattering innovation. Well, first, it isn't, and, secondly, TechCrunch seems to really miss the larger point: This term sheet is a summary of a larger, totally standard contract. In other words, the whole goal that TechCrunch seems to be excited about - a contract that is in plain english, hooray! - is false. This is a memorandum of understanding, a letter, a summary, that precedes the formal agreement itself. So, basically, this is a non-story.

However, it does lead to the more interesting question of contract drafting in general, and whether it is a better practice to use plain english or stick to the legalese. As with all things, I argue that it depends highly on context, and the intended audience for a contract.

For instance, when drafting a Terms of Service, or End User License Agreement, it is probably the right thing to draft so that a normal human being can understand what you are writing. However, if you think for a moment that I am going to draft a funding instrument or insurance policy in plain english, you need your head examined. If for no other reason - and there are many - this is because it is the language written on the contract that gets tested in court, and you want to have predictable outcomes when drafting contracts. This means you use language that has already been reviewed and tested by courts, even if it is cumbersome and bulky. So, even in the example of a TOS or EULA, when it comes to HIPAA compliance, I'm going to stick with the language I know won't get me in trouble.

A good analogy is to code: why don't engineers just write their code so it is really easy to understand? Well, to anyone who knows anything about coding, this question should appear somewhat clueless: programming is a functional activity. Code is written so that it works, first and foremost. Good code is often - and sometimes must be - easy to understand, but there is plenty good code out there that is very difficult to understand, even for very experienced programmers. Of course, it is always good practice to try to make your code easy to understand, but the reality is that function must dominate over lay-person readability.

The same is true for contracts: when a complex deal is memorialized, the documents about that deal will also necessarily be complex. The problem is that most people assume that because contracts are written in english, and that they understand english, that a contract must be faulty if it is not easy to understand. Well, this is a huge misconception.

In the end, the term sheet that TechCrunch has talked about is basically something like very good documentation, or comments that are in code. And that is great - we should all endeavor to document and explain our agreements much more thoroughly. However, as any software developer knows, writing good documentation is in no way a replacement for writing software that works, and writing a good term sheet is in no way a replacement for writing a bullet-proof contract.

Monday, June 17, 2013

Open Source Licenses: When to Use Permissive v. Copyleft

If you work in any industry that heavily relies on software (read: all of them) you will eventually run into open source licenses. So let's take a look at a broad and growing divide between the two main types of open source licenses - copyleft v. permissive. Spoiler: if you are going to be including open source software in client deliverables, it is far easier to stick with permissive licenses, where copyleft licenses should are best used for academic projects, for developer tools or projects that are dedicated to some non-commercial, public good.

Open source licenses were first used in the mid-1980s, under the mantra that "information wants to be free" - not necessarily free in price, but in that it should be freely adaptable to different people's desires. Unsurprisingly, some of the earliest licenses came out of Berkeley and MIT, including the GNU Project, under Richard Stallman. The whole idea was to distribute software that was the result of - and useful for - academic activities, and to do so in such a way that guaranteed no downstream user would be able to co-opt the software and claim ownership over it. Rather, such software would remain available for people anywhere to implement, study, contribute to, etc. As a result, the the idea was to create a recursive license, so that any software built upon software licensed in this way would also be subject to that license. This license would further require that the original software, as well as all derivatives of the original software, would have to be freely distributable and usable without restriction. The license would also provide mechanisms for submitting improvements back to the original software codebase, potentially to be included with later releases. The first such license was the GNU GPL license, which set the whole open source phenomenon.

The requirements described above - that all derivative software and contributions be licensed under the original license, that source code be freely available, that there be a mechanism for contributing improvements back to the original codebase - form what is generally termed a "copyleft" license - so called for its difference from copyright, which typically locks up ownership and use.

The outcome of the combination of the above features is often (derogatorily) called the "viral effect": an entire code base may get 'infected' if a single LGPL component is included - meaning that all software that ships with an LGPL component may be subject to the above terms.

As a result, it shouldn't be that hard to see why using a true copyleft license in commercial software is sometimes untenable: granting access to source code necessarily means giving up claims to trade secrets embodied in that source code. Additionally, the right to re-distribute covered software is automatically granted to any recipient of copyleft licensed software. This can make commercialization tricky - not impossible, but tricky - because any recipient of copyleft licensed software can turn around and resell that software, or even give it away for free. Finally, there are still gray areas in interpretations of the L/GPL regarding how it applies differently to interpreted code as opposed to compiled code.

Contrast these licenses with the so-called "permissive," such as the MIT and BSD: these licenses essentially only require that any software licensed under their terms includes an acknowledgment of prior authors, and they otherwise disclaim all warranties, restrictions and obligations. In addition, they are far, far simpler licenses: the MIT license is literally three sentences long, while the LGPL runs more than a few pages. To be fair, there are still unresolved issues about permissive licenses, such as how BSD interacts with hardware licensing, but by and large, the interpretation and use cases of permissive licenses are far less complicated than copyleft licenses.

The upshot of all this is that as more and more open source code gets built into commercial applications, we are seeing more and more open source code released on BSD and MIT licenses, and less on GPL and LGPL. Say what you will about the philosophy of the movement itself: I believe this is the inevitable outcome of the way that copyleft was originally designed.

Conclusion: If you are going to be integrating open source components into code that you intend to commercialize, it's probably safest to stick with permissively licensed components. If you are contributing to developer tools, utilities, mathematical libraries, projects for the public good, academic work, or the like, L/GPL may be more appropriate. Either way, you should probably consult your attorney.

Thursday, June 6, 2013

Followup on Console Gaming

I recently posted about how a Wired opinion piece seemed to really miss the boat on console gaming. Well, apparently, Sony agrees:

Kaz Hirai says the PS4 is 'first and foremost' a game console, more features to be revealed.

"The most important thing we need to do is agree and understand that the PS4 is a great video game console that appeals to video gamers," he said. "If we miss that part, I don't think we get the initial establishment of the console. That formula has worked for us with all our consoles, including the PS3."
Additionally, this just in from Reddit:

It was posted under the title "A concise list of all the problems with the PS4 (directly from the hardware architect Mark Cerny" and it's a list of features that gamers consider to be positive. In addition to this, the internet is currently exploding with reviews of The Last of Us, a PS3 exclusive, which is being haled as a "masterpiece." So we will see how that goes for Sony - but I think it's safe to say that Wired's critique is somewhat off the mark.

NSA and Your Digital Life

Right now the internet is on fire with the news that the NSA, through a project called PRISM, apparently has been tapping into a whole bunch of very large internet services for the better part of a decade.

I just wanted to note that we are going to have to wait a few days to get a clear look at this, because within about 90 minutes of each other, these two posts went up on Techcrunch:

Report: NSA Collects Data Directly From Servers Of Google, Apple, Microsoft, Facebook And More 

Google, Facebook, Yahoo, Microsoft And Apple Deny Participation In NSA PRISM Surveillance Program

You can read more at the NYTimes, its Editorial Board,  Guardian, Washington Post - the last two seem to have been the original source of this information.

Also, this is particularly great: NSA chief, two weeks ago: ‘We’re the only ones not spying on the American people.’

I'd encourage everyone to take the chance to read this essay, written by former Supreme Court Justices Brandeis and Warren about the Right to Privacy.