Posts Tagged gpl

Naughton, Android, the GPL and why I’m fuzzy minded.

Edward Naughton latest attack (pdf) on Android/Bionic and his claims that the GPL license has been violated are bordering on ridiculous. First of all, to simply claim that dissenters are “fuzzy minded” because we don’t supinely believe that Google is evil incarnate, that the GPL has been eviscerated, and that we are all going to die in a proprietary/parasitic world is, well, bogus. Brian Proffitt made an excellent response, that calmly provides a reasonable background and some doubts – may it be possible that the author has some motives? Say, like the suspicions previously raised around Florian Mueller? The real problem of the article is that… it’s lame, weak and takes innuendo and unrelated comments to weave them into a “proof”. I hate this kind of FUD. I hated it when Stallman did it, I hated it when Microsoft did it (“see? all those companies that licensed patents from us? It’s the proof Linux infringes!”) and now we have to endure another similar effort.

Let’s start with the biggest problem: “As I explained in detail in my first paper, Google’s approach works only if the cleaning process removes all of the copyrightable material from every one of the headers” and then goes on to show that in his opinion there are still parts that are not “pure headers”. He makes a quite simple logical error: to claim that macros are by default copyrightable. The problem is that some macros are implemented like that for technical reasons-in fact, there are no alternative, equally efficient ways to implement them in the same way. “The court explains that elements dictated by efficiency are removed from consideration based on the merger doctrine which states that a form of expression that is incidental to the idea can not be protected by copyright. In computer programs, concerns for efficiency may limit the possible ways to achieve a particular function, making a particular expression necessary to achieving the idea. In this case, the expression is not protected by copyright” (from: Computer Associates International, Inc. v. Altai, Inc.)
So, macros like those dangerously incriminating ones that Naughton believes it saw in Google indiscriminate attitude towards copyright – well, they are still unprotected, or at least (as Brian Proffitt cleary wrote in his piece) no judge expressed his views on this.

Just this point defuses most of the damning argumentation rised in the white paper – like the fact that “Google optimized the scripts for convenience and not copyright compliance”. Some other points: “Google’s decision to remove some functions and variables but to retain others depending on how it affected performance shows that they were playing fast and loose with copyright.” – no, it shows that you have an axe to grind.

“Some who criticized my analysis relied on cases in which an abstraction-filtration-comparison analysis was used, but, as Judge Alsup’s order recognized, that approach is used when the issue is the copying of non-literal elements. It doesn’t generally apply to instances of literal copying like this one. See Lotus Development Corp. v. Borland International Inc., 49 F.3d 807, 814-15 (1st Cir.
1995).”
First of all, Judge Alsup had not ordered something like “Google copied”. It just refused to grant a preliminary injunction on the copyrightability of APIs, and this is due largely to the problem of conflicting presentation of APIs from Oracle and Google (inclusive versus exclusive). And the Lotus v. Borland was not considering the AFC test because… it regarded USER INTERFACES. Not Application Programmer Interfaces. Naughton kindly sweeps the issue under the carpet, as it would remove the filtration test… and filter out much of his white paper.
In fact, all the rest is unnecessary drivel designed to demonstrate the strength of his analysis: “To be sure, the WordPress situation involved different technical details than the kernel headers, but…” (but what?)

“I have practical concerns as well: Google’s approach, if it works, provides a roadmap for bypassing the GPL, as well as a relatively simple set of customizable scripts that could allow easier exploitation of GPL components by proprietary programs. An easy bypass of GPL protections runs contrary to what FOSS advocates stand for, and I certainly would not have expected such an uncritical defense of Google.” Where, oh where, is this kind of thing possible? The author takes something that is possible for headers only, takes his own view of Google as a dastardly stealer of code, and takes it to the next level: “see! If we don’t stop them now, they will find a way to clean GPL code as well as headers! We’re doomed, like Tivo!”

I tried to write down a response that did not involve biological paraphrases, but I failed. Let’s say that the argument is not his strongest point.

(footnote: I don’t care particularly for Google, I have no financial interest for them, but I respect the contributions they made to OSS.)

, ,

No Comments

The neverending quest to prove Google evilness. Why?

Ah, my favorite online nemesis (in a good sense, as we have always a respectful and fun way of having a disagreement) Florian Mueller is working full-time to demonstrate, in his own words, “a clear pattern of extensive GPL laundering by Google, which should worry any manufacturer or developer who cares about the IP integrity of Android and its effect on their proprietary extensions or applications. It should also be of significant concern to those who advocate software freedom.” Wow. Harsh words, at that, despite the fact that Linus Torvalds himself dismissed the whole thing with “It seems totally bogus. We’ve always made it very clear that the kernel system call interfaces do not in any way result in a derived work as per the GPL, and the kernel details are exported through the kernel headers to all the normal glibc interfaces too” (he also, amusingly, suggested that “If it’s some desperate cry for attention by somebody, I just wish those people would release their own sex tapes or something, rather than drag the Linux kernel into their sordid world”. Ah, I love him.)

In fact, I expressed the same point to Florian directly (both in email and in a few tweets), but it seems very clear that the man is on a crusade, given how he describes Google actions: “the very suspect copying of Linux headers and now these most recent discoveries, it’s hard not to see an attitude. There’s more to this than just nonchalance. Is it hubris? Or recklessness? A lack of managerial diligence?” or “It reduces the GPL to a farce — like a piece of fence in front of which only fools will stop, while “smart” people simply walk around it.”

Well, there is no such thing, and I am not saying this because I am a Google fanboy (heck, I even have a Nokia phone :-) ) but because this full-blown tempest is actually useless, and potentially damaging for the OSS debate.

I will start with the core of Florian arguments:

  • Google took GPL code headers;
  • they “sanitized” it with a script to remove copyrighted information,
  • what is left is not GPL anymore (in particular, is not copyrighted).

Which Florian sees as a way to “work around” the GPL. Well, it’s not, and there are sensible reasons for saying this. Let’s look at one of the incriminated files:

#ifndef __HCI_LIB_H
#define __HCI_LIB_H

#ifdef __cplusplus
#endif
#ifdef __cplusplus
#endif
static inline int hci_test_bit(int nr, void *addr)
{
	return *((uint32_t *) addr + (nr >> 5)) & (1 << (nr & 31));
}
#endif

or, for something longer:

#ifndef __RFCOMM_H
#define __RFCOMM_H

#ifdef __cplusplus
#endif
#include <sys/socket.h>
#define RFCOMM_DEFAULT_MTU 127
#define RFCOMM_PSM 3
#define RFCOMM_CONN_TIMEOUT (HZ * 30)
#define RFCOMM_DISC_TIMEOUT (HZ * 20)
#define RFCOMM_CONNINFO 0x02
#define RFCOMM_LM 0x03
#define RFCOMM_LM_MASTER 0x0001
#define RFCOMM_LM_AUTH 0x0002
#define RFCOMM_LM_ENCRYPT 0x0004
#define RFCOMM_LM_TRUSTED 0x0008
#define RFCOMM_LM_RELIABLE 0x0010
#define RFCOMM_LM_SECURE 0x0020
#define RFCOMM_MAX_DEV 256
#define RFCOMMCREATEDEV _IOW('R', 200, int)
#define RFCOMMRELEASEDEV _IOW('R', 201, int)
#define RFCOMMGETDEVLIST _IOR('R', 210, int)
#define RFCOMMGETDEVINFO _IOR('R', 211, int)
#define RFCOMM_REUSE_DLC 0
#define RFCOMM_RELEASE_ONHUP 1
#define RFCOMM_HANGUP_NOW 2
#define RFCOMM_TTY_ATTACHED 3
#ifdef __cplusplus
#endif
struct sockaddr_rc {
	sa_family_t	rc_family;
	bdaddr_t	rc_bdaddr;
	uint8_t		rc_channel;
};
#endif

What can we say of that? They contain interfaces, definitions, constants that are imposed by compatibility or efficiency reasons. For this reason, they are not copyrightable, or more properly would be excluded in the standard test for copyright infringement, in the abstraction-filtration test. In fact, it would not be possible to guarantee compatibility without such an expression.

But – Florian guesses – the authors put a copyright notice on top! That means that it must be copyrighted! In fact, he claims “The fact that such notices are added to header files shows that the authors of the programs in question consider the headers copyrightable. Also, without copyright, there’s no way to put material under a license such as the GPL.”

Actually it’s simply not true. I can take something, add in the beginning a claim of copyright, but that does not imply that I have a real copyright on that. Let’s imagine that I write a file containing one number, and put a (c) notice on top. Do I have a copyright on that number? No, because the number is not copyrightable itself. The same for the headers included before: to test for copyright infringement, you must first remove all material that is forced for standard compatibility, then Scenes a Faire (a principle in copyright law that says that certain elements of a creative work are not protected when they are mandated by or customary for an environment), then code that cannot be alternatively expressed for performance reasons. What is left is potential copyright infringement. Now, let’s apply the test to the code I have pasted. What is left? Nothing. Which is why, up to now, most of the commentators (that are working on the kernel) mentioned that this was also just a big, large, interesting but ultimately useless debate.

In fact, in the BlueZ group the same view was presented:

“#include <bluetooth/bluetooth.h> is only an interface contract. It contains only constants and two trivial macros. Therefore there is no obligation for files that include bluetooth.h to abide by the terms of the GPL license.  We will soon replace bluetooth.h with an alternate declaration of the interface contract that does not have the GPL header, so that this confusion does not arise again.” (Nick Pelly)

It is interesting that this comes, in and out, in many projects and several times; it happened in Wine (in importing vs. recoding Windows header definitions) and I am sure in countless others. The real value of this debate would be not to claim that Google nearly certainly is an horrible, profiteering parasite that steals GPL code, but to verify that the headers used do not contain copyrighted material, because that would be an extremely negative thing. Has this happened? Up to now, I am still unable to find a single example. Another, totally different thing is asking if this is impolite – taking without explicitly asking permission on a mailing list, for example. But we are not looking at headlines like “Google is impolite”, we are looking at “Google’s Android faces a serious Linux copyright issue”, or “More evidence of Google’s habit of GPL laundering in Android”.

That’s not constructive – that’s attention seeking. I would really love to see a debate about copyrightability of header files (I am not claiming that *all* header files are not copyrightable, of course) or copyrightability of assembly work (the “Yellow Book” problem). But such a debate is not happening, or it is drowned under a deluge of “Google is evil” half proofs.

Of course, that’s my opinion.

, , , , ,

1 Comment