Copyleft Currents

A “Software Freedom Day” is scheduled for September 1, by The Linux Professional Association of Kenya at Strathmore University.

Please celebrate responsibly!

Richard Fontana started a project called “GPL.next,” in which he is writing — in true open source style, via GITHUB — a new version of GPL based on v3.  He stresses that it is not an official FSF version.  The open source community will likely be watching this process, to see how the different drafting approach might make a difference.  Fontana worked extensively at SFLC during the GPLv3 drafting process.

GPLv3 has has less penetration into the world than its authors may have hoped, and many private companies still have policies against using GPLv3 code — primarily due to concern (or confusion) over the complex patent provisions and User Product provisions.  

For some insight into the reasons behind the project, this presentation is interesting, but may be obscure to anyone who is not steeped in open source. 

Articles on the topic here:  http://www.theregister.co.uk/2012/07/07/gnu_gpl_forked/, http://www.infoworld.com/d/open-source-software/the-next-gpl-why-its-being-shaped-github-197025.  As Simon Phipps points out, GPLv3 is percieved as too complex, and was a compromise between the strongest free software advocates (who favored a license more like AGPL) and corporate interests (who favored a license that was more clear and concise). 

An update: the original GITHUB page is now a broken link, perhaps due to controversy over using the acronym GPL, which Fontana explained referred only to “General Public License” and not the GNU GPL — which is what is commonly referred to as GPL.  

Another update: It has been moved to Gitorious.

I thought I had seen the weirdest appropriation of the term “open source” when I first heard about open source yoga.  But with this latest development, “open source” seems to be going the way of “green” — being assimilated from a moderately useful term into a pure marketing buzzword with no meaning whatsoever except for the promotional value people choose to make of it.

The article says, “Berlin-based filmmaker Sam Muirhead is abandoning all copyrighted products and switching to Open Source software, hardware, and services for one year, as the subject of his own series of online documentary videos.”  (I am now pondering what open source services are — but perhaps they include some forms of yoga.)

It may be possible to avoid all use of proprietary software.  There are many people who make it a point to do this already, of course.  I think it would be interesting to see a film — or at least a white paper — about that.  It would be interesting to see what proprietary software is still clearly the cheaper/better/faster choice, in this age of LAMP stacks and Sourceforge.  I also like the idea that we should all be willing to eat our own dog food.  

Admittedly, Mr. Muirhead seems to recognize that his use of “open source” is broad, and describes what he is doing as using “the shariest option.”  He will reportedly be “avoiding food grown from copyrighted seed strains.”   Before he tries “DIY dentistry, for example, or Open Source contraception” I would like to point out that engaging in DIY dentistry may very well obviate the need for open source contraception.

Some of the reporting on this is particularly amusing due to its high bizarre-o world factor.  For instance, “Open source housing is one of the problems, he noted, adding that he already found an open source house made by someone in Berlin. However, the house is only one cubic meter in size.” Not scalable, I guess.  And “‘Berlin is the perfect city for a project such as this,’ he said. ‘This would not be possible in New Zealand.'” I had no idea New Zealanders were so…proprietary?  Or of physical proportions incapable of fitting in a house of one cubic meter?

Presumably he will be releasing his documentary under CC-BY-SA.

You can contribute to the crowd-sourcing of his documentary here.  I have to confess I was tempted to contribute when lured with the promise of an “open source swimsuit calendar” for a $25 donation.  It will include drawings of “open source heroes and heroines.”  On on the other hand, perhaps not. 

The fine folks at nexB have put together a treasure trove of information about open source licenses, which they call DejaCode Enterprise License Library.  You can easily search for a license and quickly see its obligations and restrictions, as well as other interesting license characteristics.  So if you ever wondered “Is this a copyleft license?” wonder no more — you can look it up in the DejaCode library.

DejaCode Enterprise is nexB’s product suite for managing a software component supply chain. The first available product, the License Library, is an online repository of software licenses (open source and proprietary) with profile information for each license. The online read-only version is available for a free trial https://enterprise.dejacode.com/.  Companies who get the enterprise version can use the License Library to manage software license information and educate their users about company software license policies. 

The library includes not only open source licenses but also many common freeware licenses.  It’s a useful tool to get a reality check on the licenses you don’t see every day.

For many years I have been telling clients that software has become so pervasive that almost every product has potential open source compliance concerns.  My running joke is that the only thing that doesn’t have software is a toaster.  Well, there is now Net BSD toaster, “using one of its TS-7200 single-board computers housed inside the empty space of a standard 2 slice toaster.”  

I wonder where the licensing notices go.  On a “pop-up” screen?  (Sorry.)

There has been recent public comment from Alan Cox regarding whether proprietary Linux kernel modules are allowed under GPL.  Cox is a significant kernel contributor, and the commentary appears to be aimed at preventing estoppel arguments or supporting claims for willful copyright infringement (which could result in enhanced damages).  Binary modules of some types have long co-existed with the GPL kernel, but what is allowed and what is not has long been a subject of controversy — even mystery — in GPL interpretation.  Public comment on the topic has historically been rare.   

Alan Cox comments, “I’m a rights holder…. The code I provided is licensed under the GPL. Whether the symbol is EXPORT_SYMBOL or EXPORT_SYMBOL_GPL any derivative code (eg code that requires the kernel be modified to match it) cannot call it.

I’m recommended by my lawyer to always remind people of this when such a claim is made. It ensures that triple damages for wilful infringement will apply unless the other party can show it reviewed the situation carefully and its appropriately qualified legal staff reached a different conclusion.”

Also, “The GPL covers *all* derivative works. EXPORT_SYMBOL doesn’t magically make code non-derivative. If you need to modify the kernel to make your driver work *and* you want to claim it is not derivative then I hope there are good lawyers involved 😎 The kernel is GPL, all derived works of a GPL codebase are required to be GPL. There is no magic rule about modules. I’ve stated that repeatedly for anything containing a line of code I own. GregKH [Greg Kroah-Hartman] has made it very clear for his code, and so it goes on.”

Cox and Kroah-Hartman are both listed on the Linux Foundation’s list of top individual contributors in its March, 2012 paper on Linux development.

Many kernel-adjacent developers have looked to EXPORT SYMBOLs to understand the intent of kernel developers as to what interfaces can support proprietary modules. 

A previous public comment by Cox said:

The Linux Foundation is moving forward with its SPDX (Software Package Data Exchange) project, which is an industry-wide project to simplify and standardize the way suppliers and customers share bill of materials information about open source software throughout the supply chain.  Identifying, preserving, and verifying the meta-information about software components that is necessary to comply with open source licenses has emerged as the eternal question for redistributors of open source in the private sector.  In fact, the difficulty — not to mention the tedium and resource diversion — necessary to convey this information accurately, along with proper notices, is one of the biggest challenges in open source today.  In other words, laying aside all the areas of legal ambiguity surrounding open source licensing — like juicy derivative works questions or the arcane patent terms of GPLv3 — and assuming one actually knows how to comply with the license, how does one actually do it?  A sophisticated product can contain hundreds or thousands of open source components, and cataloging them is a daunting administrative task that requires both legal and technical training.  Most companies are currently reduced to creating excel spreadsheets ad hoc, extracting information from scanning utilities like the Black Duck and Palamida software tools, or throwing up their hands in frustration.  SPDX is an effort to formulate a protocol for storing and delivering the relevant information, aimed to become a standard acceptable to all links in the supply chain. 

The effort is ambitious, and may aptly compared to herding cats or solving the meaning of life, but those involved in open source compliance, across the board, understand that it must be done.  Participation in the workgroup is open to all.  For more information, see http://spdx.org/.

Based on Arduino.  For those of us who want to scare away would-be attackers with the pure force of our nerdiness.