Author: heatherjmeeker

Technology licensing lawyer, drummer

DejaCode — Everything you wanted to know about open source licenses

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.

 

At Last, an Open Source Toaster

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.)

 

Stirrings in the Kernel Module Debate

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:

“Since you’ve asked this I’m advised by my lawyer to respond to all such assumptions of legality of binary modules…For a Linux kernel containing any code I own the code is under the GNU public license v2 (in some cases or later), I have never given permission for that code to be used as part of a combined or derivative work which contains binary chunks. I have never said that modules are somehow magically outside the GPL and I am doubtful that in most cases a work containing binary modules for a Linux kernel is compatible with the licensing, although I accept there may be some cases that it is.”
This discussion string referred to whether “shims” can be used to cause proprietary modules to interface with EXPORT_SYMBOL_GPLed code.

 

 

SPDX and the Meaning of Life

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/.

Live Free or Die (Whichever is Cost-Effective)

In a precedent-setting move, New Hampshire has enacted HB 418-FN, a bill that directs administrative agencies in the state to consider open source on a level economic playing field with proprietary software, and to favor open standards.  State agencies are required to “Consider whether proprietary or open source software offers the most cost effective software solution for the agency, based on consideration of all associated acquisition, support, maintenance, and training costs” and to “Avoid the acquisition of products that do not comply with open standards for interoperability or data storage.”  
The bill contains a definition of open source software that is not dissimilar to, but not quite the same as, the Open Source Definition and the Free Software Definition: (a) Unrestricted use of the software for any purpose; (b) Unrestricted access to the respective source code; (c) Exhaustive inspection of the working mechanisms of the software; (d) Use of the internal mechanisms and arbitrary portions of the software, to adapt them to the needs of the user; (e) Freedom to make and distribute copies of the software; and (f) Modification of the software and freedom to distribute modifications of the new resulting software, under the same license as the original software.

 

Perhaps more interesting is the definition of an “open standard,” a standard that:

(a) Is free for all to implement and use in perpetuity, with no royalty or fee;

(b) Has no restrictions on the use of data stored in the format;

(c) Has no restrictions on the creation of software that stores, transmits, receives, or accesses data codified in such way;

(d) Has a specification available for all to read, in a human-readable format, written in commonly accepted technical language;

(e) Is documented, so that anyone can write software that can read and interpret the complete semantics of any data file stored in the data format;

(f) If it allows extensions, ensures that all extensions of the data format used by the state are themselves documented and have the other characteristics of an open data format;

(g) Allows any file written in that format to be identified as adhering or not adhering to the format; and

(h) If it includes any use of encryption or other means of data obfuscation, provides that the encryption or obfuscation algorithms are usable in a royalty-free, nondiscriminatory manner in perpetuity, and are documented so that anyone in possession of the appropriate encryption key or keys or other data necessary to recover the original data is able to write software to access the data.

Open standards definitions are elusive — you’ve got to admire the Granite State for trying.
The bill further mandates “principles of open government data” aimed at transparency and free availability of data.
On a personal note, I am always pleasantly surprised when anyone in government appears to be thinking about what is cost effective.
PS Thanks to Mark Radcliffe for the scoop on this.

 

 

Open Source in US Defense Acquisition

On Jan 12, 2012, the Department of Defense held a public meeting inviting comment on the use of open source software in defense contracting.   Written comments were submitted by various organizations including the Aerospace Industries Association.  Those comments lay out the questions posed by the DoD regarding risks that open source software includes proprietary software (i.e. is infringing), ability of contractors to get support for open source software, and whether the DFARs (Defense Federal Acquisition Regulations) should be revised to clarify the rights granted the government under licenses like GPL.  The AIA’s comments also raise the question of whether export restrictions are “additional restrictions” that conflict with GPL.  Another set of comments addressed the question of whether Apache 2.0, paragraph 9, which “provides that the licensee indemnifies the developer in certain circumstances,” conflicts with the Antideficiency Act (ADA) 31 USC 1341.  The ADA prevents the government from incurring of obligations in excess of appropriations or funds. 

 

Koha Trademark Dispute

An open source project in New Zealand is involved in a trademark dispute. 

If you want to see an example of the kind of reporting about open source legal matter that drives lawyers like me to distraction, take a look at this article.  It describes the dispute as just about everything except what it is — a trademark interference.  “A small New Zealand library is fighting to keep its trademark free software from the clutches of a United States corporation.”  It’s actually a dispute about the trademark, not the software copyright.  “[A]n American company named LibLime has hijacked the system and wants to use it for its own private client base.”  Hijacked?  If it’s open source, it’s free to use and modify, though there may be a separate trademark issue.  Also the URL for the article calls it “Small-library-fights-US-corporation-over-software-patent” and there are no patents in sight.

But apparently the publicity worked, as the project, according to its own blog post linked above, got many donations to a legal fund, and also pro bono representation.  A deal is reportedly being brokered to assign the trademark to a non-profit representing the Koha community.

Â