Copyleft Currents

TrueCrypt, an open source encryption software project that was particularly popular with individuals and developers, was recently abandoned.  In May 2014, the TrueCrypt website posted a warning that “TrueCrypt is not secure as it may contain unfixed security issues.” Users were encouraged to migrate to BitLocker. Despite the developers’ abandonment, an audit of the code will continue into Phase II.

Reasons for the abandonment are not entirely clear, in part because the developers of TrueCrypt were mostly anonymous.  Some speculators suggested the abandonment was due to an NSA-backed takedown, perhaps tied to Edward Snowden’s use of the software in his leak of NSA documents. Others say a campaign to audit the code made the developers skittish, due to concerns that an audit would reveal security flaws.

Coming on the heels of the Heartbleed problems with OpenSSL earlier this year, the TrueCrypt abandonment underscores the importance of popular open source projects being organized and transparent, and tethered to a legal entity that can continue the project beyond the participation of the original developers. 

The community is responding accordingly. In an effort to salvage TrueCrypt,  Thomas Bruderer and Jos Doekbrijder established truecrypt.ch,  a Switzerland-based collaboration with a mission to “organize a future” for TrueCrypt.  That site allows users to download versions of TrueCrypt previously made unavailable.  Last month, Bruderer and Doekbrijder also  launched the pure-privacy association, to provide a legal framework for handling open-source project development in the privacy area.  The TrueCrypt reboot is pure-privacy’s first project. 

A true reboot of TrueCrypt may involve auditing and forking the code, normalizing the licensing of the code, and re-launching the project under a different name. The goal is to provide an open source cross-platform encryption option to succeed TrueCrypt.  The new project is tentatively called “CipherShed.”

More information about the TrueCrypt revival can be found by following the @TrueCryptNext Twitter feed and by checking the website https://truecrypt.ch.

The Linux Foundation announced a release of a flavor of Linux especially designed for automotive systems, such as HVAC, media playback, and Bluetooth phone.  Another step in the inevitable integration of Linux into vehicles — though it is still in ancillary systems rather than drivetrain.

 

Simon Phipps wrote a particularly interesting article on project governance in the “GITHUB generation.”  The article is very good reading, and thought-provoking.

In it, he articulates, among other things, the case against contribution agreements.  He observes that it is becoming more common to use he outbound license as an inbound contribution agreement.  (“license in = license out”)  This has long been the approach of free software purists, and of course the Linux project, and it does have the virtue of transparency.  When the license in equals the license out, the project does not enjoy superior rights to the rest of the world.  Projects that use contribution agreements are sometimes not transparent about the consistency with which CLAs have been required, or whether special exceptions have been granted for some contributors, and that can cause disenchantment with the project management — at least among those attuned to IP diligence issues.  From time to time I have been set the task to figure out who has contributed to a project on what terms, and it can be difficult and disappointing to try to do this.

The question of the use of contribution agreements — to use or not to use — is in part a matter of semantics.  Of course, not having a contribution agreement works well when the license is a permissive one.  In fact, most contribution agreements are very similar in scope to permissive licenses — or a bit more restrictive.  For instance, a common term in CLAs is that the contributor promises the contribution is original code.  For “license in= license out” paradigms, that is handled by a separate document called a “developer certificate of origin.”  Some CLAs require the project to re-license only on open source terms.  This is a very mild sort of copyleft requirement, that is intended to reassure contributors that their contributions are not merely being assimilated into the Borg of a proprietary development project.  But if the project is, for instance, a not-for-profit foundation, this issue would be addressed by limitations in the scope of the organization’s charter.  The IRS is likely to be far more effective in preventing privitization of foundation-run projects than any contribution agreement could be.  After all, the contribution agreement only has the force of copyright (and contract) law, and the IRS can send agents to your door.  So in sum, using a permissive license as “license in = license out” is probably just as effective as a contribution agreement, if your goal is to maximize the flexibility and transparency of the project.  (Except for the question of retaining individual contributor notices, which is a topic best left for another day.)

But it’s hard ot read an argument against contribution agreements while I am, coincidentally, embarking on yet another relicensing project.  When the project uses a copyleft license, eschewing a contribution license means the project only has one chance to get its licensing right.  Using a copyleft license as a contribution agreement means the outbound license can never be changed.  Phipps suggests that the “version plus” approach solves this problem — e.g. contributing under GPL v2 or any later version allows one to change to a later version of the same license.  But of course, that doesn’t help if the project community wants to move to a more permissive license, like LGPL or even BSD or Apache.  Many projects tend to move to more permissive licenses over time, for two reasons.  First, the trend over the last decade has been to prefer more permissive licenses.  This is one of the characteristics of the “GITHUB generaltion,” as I mention below.  Second, as code becomes outdated over time, there may come a point when there is no longer any compelling reason to keep licensing it under restrictive terms, as no one will be interested in enforcing the conditions anymore.  When that happens, the conditions become economic dead weight that no longer serve anyone.   Projects can only change to a less restrictive license if they have used a contribution agreement.

If they have not, and want to move to more permissive terms, they need to undergo a relicensing effort — going back to all the contributors to get permission to use the new terms. Relicensing projects are a chore, as anyone who has executed one can attest.  There is always a point where one is looking at 20 lines of code, for which the author is unavailable (or never admitted to his identity in the first place), and wondering whether humanity is really best served by re-writing that code to avoid copyright infringement claims that are, in all likelihood, more theoretical than real.

The need for relicensing crops up sometimes, in particular, whether the initial license chosen by the project is idiosyncratic, or simply one of those open source licenses that is not a sterling example of the craft of license drafting.  (They shall be nameless here, but are easy to pick out — just see what relicensing efforts have been mounted and you will find out which of these mystical creeds people are trying to forget they ever used.)

Another interesting implication of the article is the notion that the latest generation of developers has little patience for licensing issues.  I think this is true in spades.  The average coder who puts code up on GITHUB couldn’t care less about open source conditions, contribution agreements, copyleft, and the like.  I am not sure that dispensing with contribution agreements is the answer, but it’s a good argument for moving to CC0 (the Creative Commons public domain dedication).  These days, I am more and more inclined to tell clients that if they really want code used as broadly as possible, and don’t honestly have any plans or budget for license enforcement, they should consider public domain instead of permissive licenses.   I guess that advice is against my interest, seeing as I have spent a lot of time advising clients on license compatibility issues and re-licensing efforts.  But so be it.  We should remember that license conditions are forever (or at least as long as copyright protection, which seems to be on a slippery slope into forever these days), and we need to consider whether we really need to bind the two generations beyond us to license conditions that may, in the year 2100 or so, seems like relics of a lost era.

Starting June 3, 2014, I will be joining O’Melveny & Myers as a partner in the M&A group.  I will be continuing my technology licensing practice (including open source software licensing).  I am very excited about this new step in my practice.  O’Melveny is a highly regarded firm with premiere practices in California, Asia-Pacific, and Europe, and I am joining a top-notch technology law team in Northern California.

The Heartbleed crisis that resulted from a security flaw in OpenSSL cryptographic software library (see my blog post on April 15, 2014)  raised questions about the funding and viability of popular of open source projects.  Despite the importance of OpenSSL to Internet security, the project was operating on limited budget and with minimal development resources, which may have contributed to the accidental introduction of the bug.  

In response, on April 24, 2014, the Linux Foundation announced a three-year multi-million dollar “Core Infrastructure Initiative”.  The Initiative will help “technology companies to collaboratively identify and fund open source projects that are in need of assistance, while allowing the developers to continue their work under the community norms that have made open source so successful.”  Industry giants Amazon Web Services, Cisco, Dell, Facebook, Fujitsu, Google, IBM, Intel, Microsoft, NetApp, Rackspace and VMware are the founding members of the Initiative and have each pledged at least $100,000 a year; the total initial funding is around $3.9 million dollars, according to Ars Technica.  The Initiative’s funds will be administered by the Linux Foundation and “backers of the project as well as key open source developers and other industry stakeholders.”

While the money will go to various open source projects, the first project under consideration to receive funds will be OpenSSL, which may receive “fellowship funding for key developers as well as other resources to assist the project in improving its security, enabling outside reviews, and improving responsiveness to patch requests.”  

 

On Monday, April 7, 2014, a four-byte flaw in the widely used OpenSSL encryption library was made public.  The bug, dubbed Heartbleed, lies within the OpenSSL implementation of the TLS heartbeat extension and may allow the extraction of sensitive in-memory data (login cookies, passwords, crypto-keys) from systems that rely on OpenSSL versions 1.0.1 and 1.0.1f. 

OpenSSL provides a secure line for Internet communications and encrypts data so it can be decrypted only by the intended recipient.  Sometimes this requires one of the communicating computers to confirm that there is still a computer on the other end, and it will send a small packet of data known as “heartbeat.”  The code flaw allows a packet of data disguised as “heartbeat” to trick the receiving computer into sending back data stored in its memory, 64 bytes at a time.   

The Heartbleed bug compromised the security of websites, client software, email servers, and chat services.   Many popular web services have been patched following the disclosure of the security vulnerability, and a new version, OpenSSL v. 1.0.1g, has been released.  

The implications for this incident on open source software center on an old debate as to whether open source is likely to be more secure than proprietary code.  Despite the widespread use of OpenSSL, the core development team for the project consists of only four volunteers and is minimally funded by donations and sponsorships.  The open source mantra that “given enough eyeballs, all bugs are shallow” may fail when a project is not well supported by the communities that use it.  The faulty code containing Heartbleed bug was written by a contributor who did not notice the mistake, and the bug was committed by one of the core developers, causing speculation that the bug slipped through because the core team was spread too thin. 

The “debate” over whether open source or proprietary code is more secure is, of course, a red herring: there is no one answer.  Open source advocates often point out that proprietary code can be more vulnerable to the extent it relies on “security by obscurity,” and relies on a single vendor to correct flaws.  However, proprietary software champions claim that open source code may be more likely to suffer from inadequate quality control if it is not properly supported, because no one vendor has the economic incentive to provide support.  This debate will, of course, never be resolved.  But the Heartbleed incident is certainly a wake-up call, and a reminder that any company using software has to know where its support is coming from — whether that be the community or a private source.

 

Egypt’s Ministry of Communication and Information Technology has adopted a policy to support open source software. The Ministry hopes to promote the technology sector in Egypt. MCIT assigned the task of developing the policy and related strategy to the Software Engineering Competence Centre (SECC).

 

Bitpay, the company behind Bitcoin, the virtual currency, released an open source library called Bitcore to help developers develop applications enabled to use payments with Bitcoin.  It is a Javascript library, released under an MIT-style license, and a fork of Bitcoin.js, a library developed by a user/developer group called Weusecoins. 

According to TechCrunch, at Defrag Conference 2013, 3Scale Founder Steven Willmott and API Evangelist Kin Lane launched a service called API Commons, which aims to provide a simple and transparent tool for developers to freely design, share, and use application program interface (API) specifications and data models under Creative Commons licenses. This effort seeks to address the uncertainty of copyright interests in APIs, and the uneven licensing practices that apply to them.

The district court order in the recent Oracle v. Google case, issued on May 31, 2012, spoke to the protectability under copyright of certain APIs. However, the case is currently on appeal to the Federal Circuit, which may offer further guidance on copyright protection for APIs.  It has long been understood that copyright protection of schema, APIs and similar program specifications is thin.  Courts have not expressly and categorically opined that they are unprotectable, but that has been the working assumption of many in the software industry based on the teachings of Computer Assoc. V. Altai and Lotus v. Borland, the seminal software copyright cases of the 1990s.  (Lotus involved the copyright interest — or lack thereof — in a menuing heirarchy.)  If the API issue remains unclear, developers who use others’ API operate in a gray zone, uncertain as to whether licenses are necessary. Similarly, developers of the APIs may offer no express license to use them, assuming that it might not be necessary to do so.  

As if widespread and high-profile technical problems were not enough, an open source licensing controversy has added some heat to the already heavily criticized launch of Healthcare.gov, the US government’s website facilitating signups for the Affordable Care Act, a.k.a. Obamacare. The Weekly Standard reports that the creators of the website apparently used portions of the DataTables script (dual licensed under GPL v.2 and the BSD license) without properly retaining copyright notices, in violation of the license terms. The software, written by Allan Jardine of SpryMedia, allegedly appear in the Healthcare.gov website script without any references to its author.

The Weekly Standard posting contains a comparison of code snippets that illustrate similarities between the script from Healthcare.gov and SpryMedia script. A SpryMedia representative expressed the intent to bring this violation of licensing terms to the attention of the Department of Health and Human Services, the agency in charge of Healthcare.org.  

While this incident is topical, it is also endemic of older and larger problems with non-compliance for open source client-side scripts (like Javascript), much of which is licensed under the (logically odd) GPL/BSD dual approach.  Because these scripts execute on the client side, they are distributed even when the server side code is not — leading to a commonly overlooked aspect of open source compliance.