Bradley M. Kühn  [RSS of Whole Site]




Contact

Fediverse / Mastodon / Microblog  

Blog     [RSS of Blog]
Interviews / Articles     [RSS of Articles]
Software

Résumé
 


Tag Cloud


(一)accounting

(二)advocacy

(三)agpl

(四)ai
(五)android

(六)apache

(七)apple

(八)apt

(九)artistic

(十)asterisk

(11)automotive

(12)autonomous

(13)award

(14)bilski

(15)canonical

(16)capitalism

(17)centos

(18)cla

(19)community

(20)compliance

(21)conferences

(22)conservancy

(23)copyleft

(24)copyright

(25)cow-orking

(26)cpp

(27)debian

(28)denounce

(29)development

(30)diversity

(31)emacs

(32)encryption

(33)enforcement

(34)exceptions

(35)faif

(36)fdl

(37)for-profit

(38)fosdem

(39)foss

(40)fsf

(41)gcc

(42)git

(43)gnome

(44)gnu

(45)google

(46)GPL

(47)gpl

(48)gpl-compatibility

(49)gpl-enforcement

(50)gplv3

(51)guadec

(52)ibm

(53)identica

(54)infringement

(55)java

(56)javascript

(57)jvm

(58)launchpad

(59)ldap

(60)lgpl

(61)libreoffice

(62)libreplanet

(63)licensing

(64)lindows

(65)linux

(66)llm

(67)maemo

(68)mail

(69)meego

(70)microsoft

(71)mobile

(72)moblin

(73)mono

(74)motorola

(75)mta

(76)murder

(77)mysql

(78)net-services

(79)nlp

(80)nokia

(81)non-profit

(82)np-complete

(83)open-core

(84)open-foam

(85)open-source

(86)oracle

(87)osi

(88)parrot

(89)patents

(90)perl

(91)perljvm

(92)permissive-license

(93)piracy

(94)podcast

(95)podjango

(96)poker

(97)politics

(98)postfix

(99)proprietary

(100)qt
(101)red-hat

(102)replicant

(103)requiem

(104)rhel

(105)rtlinux

(106)SCALE

(107)sco

(108)scotus

(109)security

(110)sexism

(111)sflc

(112)slicing

(113)social-justice

(114)software

(115)software-freedom

(116)speeches

(117)stet

(118)talks

(119)tcl

(120)teaching

(121)tech-press

(122)technology

(123)thesis

(124)tivoization

(125)trademarks

(126)trump

(127)ubuntu

(128)vizio

(129)voip

(130)xen

Powered by

 A Very Old Fork of Jekyll  "Source Code" for this site  


Questioning The Original Analysis On The Bionic Debate


Friday 18 March 2011 by Bradley M. Kühn  


I was hoping to avoid having to comment further on this problematic  story. I figured a comment  as a brief identi.ca statement was enough when it  was just  a story on the Register. But, it's now  hit a  major tech news outlet, and I feel that, given that I'm typically  the first person everyone in the Free Software world comes to ask if  something is a GPL violation, I'm going to get asked about this soon, so  I might as well preempt the questions with a blog post, so I can answer  any questions about it with this URL.

In short, the question is: Does Bionic (the Android/Linux default C  library developed by Google) violate the GPL by importing  scrubbed headers from Linux? For those of you seeking  TL;DR version: You can  stop now if you expect me to answer this question; I'm not going to. I'm  just going to show that the apparent original analysis material that started  this brouhaha is a speculative hypothesis which would require much more  research to amount to anything of note.

Indeed, the kind of work needed to answer these questions typically  requires the painstaking work of a talented developer working very  closely with legal counsel. I've done analysis like this before for  other projects. The only one I can easily talk about publicly is the  ath5k situation. (If you want to hear more on that, you can listen to  an old  oggcast where I discussed this with Karen Sandlerorread  papers  that were written on the subject back where I used to work.)

Anyway, most of what's been written about this subject of the Linux  headers in Bionic has been poorly drafted speculation. I  suppose some will say this blog post is no better, since I am not  answering any questions, but my primary goal here is to draw attention  that absolutely no one, as near as I can tell, has done the incredibly  time consuming work to figure out anything approaching a definitive  answer! Furthermore, the original article that launched this debate  (Naughton's  paper, The Bionic Library: Did Google Work Around the  GPL?) is merely a position paper for a research project yet  to be done.

Naughton's full paper gives some examples that would make a good  starting point for a complete analysis. It's disturbing, however, that  his paper is presented as if it's a complete analysis. At best, his  paper is a position statement of a hypothesis that then needs the actual  experiment to figure things out. That rigorous research (as I keep  reiterating) is still undone.

To his credit, Naughton does admit that only the kind of analysis I'm  talking about would yield a definitive answer. You have to get almost  all the way through his paper to get to:  
Determining copyrightability is thus a fact-specific, case-by-case  exercise.  Certainly, sorting out what is and isnt subject to  GPLv2 in Bionic would require at least a file-by-file, and most likely  line-by-line, analysis of Bionic  a daunting task[.]  
Of course, in that statement, Naughton makes the mistake of subtly  including an assumption in the hypothesis: he fails to acknowledge clearly  that it's entirely possible the set of GPLv2-covered work found in Bionic  could be the empty set; he hasn't shown it's not the empty set (even  notwithstanding his very cursory analysis of a few files).

Yet, even though Naughton admits full analysis (that he hasn't done) is  necessary, he nevertheless later makes sweeping conclusions:  
The 750 Linux kernel header files  define a complex overarching  structure, an application programming interface, that is thoughtfully and  cleverly designed, and almost assuredly protected by copyright.  
Again, this is a hypothesis, that would have be tested and proved with  evidence generated by the careful line-by-line analysis Naughton himself  admits is necessary. Yet, he doesn't acknowledge that fact in his  conclusions, leaving his readers (and IMO he's expecting to dupe lots of  readers unsophisticated on these issues) with the impression he's shown  something he hasn't. For example, one of my first questions would be  whether or not Bionic uses only parts of Linux headers that are required  by specification to write POSIX programs, a question that Naughton doesn't  even consider.

Finally, Naughton moves from the merely shoddy analysis to completely  alarmist speculation with:
But if Google is right, if it has succeeded in removing all copyrightable  material from the Linux kernel headers, then it has unlocked the Linux  kernel from the restrictions of GPLv2. Google can now use the  clean Bionic headers to create a non-GPLd fork of the Linux  kernel, one that can be extended under proprietary license terms. Even if  Google does not do this itself, it has enabled others to do so. It also  has provided a useful roadmap for those who might want to do the same  thing with other GPLv2-licensed [sic] programs, such as databases.  

If it turns out that Google has succeeded in making sure that the GPLv2  does not apply to Bionic, then Google's success is substantially more  narrow. The success would be merely the extraction of the  non-copyrightable facts that any C library needs to know about Linux to  make a binary run when Linux happens to be the kernel underneath. Now, it  should be duly noted that there already exist two libraries under the LGPL  that have already implemented that (namely, glibc, and uClibc  the  latter of which Naughton's cursory research apparently didn't even turn  up). As it stands, anyone who wants to write user-space applications on a  Linux-based system already can; there are multiple C library choices  available under the weak copyleft license, LGPL. Google, for its  part, believes they've succeed at is to make a permissively licensed third  alternative, which is an outcome that would be no surprise to us who have  seen something like it done twice before.

In short, everyone opining here seems to be conflating a lot of issues.  There are many ways to interface with Linux. Many people, including me,  believe quite strongly that there is no way to make a subprogram in  kernel space (such as a device driver) without the terms of the GPLv2  applying to it. But writing a device driver is a specialized task  that's very different from what most Linux users do. Most developers  who use Linux  by which they typically mean write a  user space program that runs on a GNU/Linux operating system  have  (at most) weak copyleft (LGPL) terms to follow due to glibc or uClibc.  I admit that I sometimes feel chagrin that proprietary applications can  be written for GNU/Linux (and other Linux-based) systems, but that was a  strategic decision that RMS made (correctly) at the start of the GNU  project one that the Linux project, for its part, has also always  sought.

I'm quite sure no one  including hard-core copyleft advocates  like me  expects nor seeks the GPLv2 terms to apply to programs  that interface with Linux solely as user-space programs that  runs on an operating system that uses Linux as its kernel. Thus, I'd  guess that even if it turned out that Google made some mistakes  in this regard for Bionic, we'd all work together to rectify those  mistakes so that the outcome everyone intended could occur.

Moreover, to compare the specifics of this situation to other types of  so-called copyleft circumvention techniques is just  link-baiting that borders on trolling. Google wasn't seeking to  circumvent the GPL at all; they were seeking to write and/or adapt a  permissively licensed library that replaced an LGPL'd one. I'm of  course against that task on principle (I think Google should have just  used glibc and/or uClibc and required LGPL-compliance by applications).  But, to deny that it's possible to rewrite a C library for Linux under a  license that isn't GPLv2 would also imply immediately the (incorrect)  conclusion that uClibc and glibc are covered by the GPLv2, and we are  all quite sure they aren't; even Naughton himself admits that (regarding  glibc).

Google may have erred; no one actually knows for sure at this time.  But the task they sought to do has been done before and everyone  intended it to be permitted. The worst mistake of which we might ultimately accuse  Google is inadvertently taking a copyright-infringing short-cut. If  someone actually does all the research to prove that Google did so, I'd  easily offer a 1,000-to-1 bet to anyone that such a copyright  infringement could be cleared up easily, that Bionic would still work as  a permissively licensed C library for Linux, and the implications of the  whole thing wouldn't go beyond: It's possible to write your own C  library for Linux that isn't covered by the GPLv2  a fact  which we've all known for a decade and a half anyway.

Update (2011-03-20):  Many people,  including slashdot,  have been linking to  this comment  by RMS on LKML about .h files. It's important to look carefully at  what RMS is saying. Specifically, RMS says that sometimes #include'ing a  .h file creates a copyright derivative work, and sometimes it doesn't; it  depends on the details. Then, RMS goes to talk on some rules of thumb  that can help determine the outcome of the question. The details are what  matters; and those are, as I explain in the main post above, what requires  careful analysis done jointly and in close collaboration between a  developer and a lawyer. There is no general rule of thumb that always  immediately leads one to the right answer on this question.


Posted on Friday 18 March 2011 at 19:52 by Bradley M. Kühn.  

Comment on this post in this discussion forum conversation.  


 

 







Creative Commons License This website and all documents on it are licensed under a   Creative Commons Attribution-Share Alike 3.0 United States License   .  


#include <std/disclaimer.h>  
use Standard::Disclaimer;  
from standard import disclaimer  
SELECT full_text FROM standard WHERE type = 'disclaimer';  

Both previously and presently, I have been employed by and/or done work for various organizations that also have views on Free, Libre, and Open Source Software. As should be blatantly obvious, this is my website, not theirs, so please do not assume views and opinions here belong to any such organization.

 bkuhn  


ebb is a (currently) unregistered service mark of Bradley Kühn.  
Bradley M Kühn  <bkuhn@ebb.org>