Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/18/bionic-debate.html

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 Sandler
or read
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 isn’t 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-GPL’d 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.

Post Syndicated from Oglaf! -- Comics. Often dirty. original https://www.oglaf.com/blank-page/

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2011/03/11/linux-red-hat-gpl.html

Today, I
was interviewed
by Sam Varghese about whether Red Hat’s current distribution policies
for the kernel named Linux are GPL-compliant. You can read there
that
AFAICT they are, and have been presented with no evidence to the
contrary.

Last week, when the original
story broke, I happened to be at
the Linux
Foundation‘s End
User Summit, and I had a rather extensive discussion with
attendees there about this issue,
including Jon
Corbet, who wrote an article about it. In my mind, the issue was
settled after that discussion, and I had actually put out of my mind,
until I realized (when Varghese contacted me for an interview) that
people had
conflated my
previous blog post from last weekend as being a comment
specifically on the kernel distribution issue. (I’d been otherwise
busy this week, and thus hadn’t yet
seen Jake
Edge’s follow-up article on LWN (to which I respond to in detail
below).)

(BTW, on this issue please note that my analysis below is purely a
GPLv2 analysis.
GPLv3 analysis may be
slightly different here, but since, for the moment, the issue relates to
the kernel named Linux which is currently licensed GPLv2-only,
discussing GPLv3 in this context is a bit off-topic.)

Preferred Form For Modification

I have been a bit amazed to watch that so much debate on this has
happened around the words of preferred form of the work for making
modifications to it
from GPLv2§3.
In particularly, I can’t help chuckling at the esoteric level to which
many people believe they can read these words. I laugh to myself and
think: not a one of these people commenting on this has ever tried in
their life to actually enforce the GPL.

To be a bit less sardonic, I agree with those who are saying
that the preferred form of modification should be the exact
organization of the bytes as we would all like to have them to make our
further work on the software as easy as possible. But I always look at
GPL with an enforcers’ eye, and have to say this wish is one that won’t
be fulfilled all the time.

The way preferred form for modification ends up working out in
GPLv2 enforcement is something more like: you must provide complete
sources that a sufficiently skilled software developer can actually make
use of it without any reverse engineering. Thus, it does clearly
prohibit things like source on
cuneiform tablet that Branden mentions. (BTW, I wonder if Branden
knows we GPL geeks started using that as an example circa 2001.) GPLv2
also certainly prohibits source obfuscation tools that Jake Edge
mentions. But, suppose you give me a nice .tar.bz2 file with all the
sources organized neatly in mundane ASCII files, which I can open up
with tar xvf, cd in, type make and get a
binary out of those sources that’s functional and feature-equivalent to
your binaries, and then I can type make install and that binary
is put into the right place on the device where your binary runs. I
reboot the device, and I’m up and running with my newly compiled version
rather than the binary you gave me. I’d call that scenario easily GPLv2
compliant.

Specifically, ease of upstream contribution has almost nothing to do
with GPL compliance. Whether you get some software in a form the
upstream likes (or can easily use) is more or less irrelevant to the
letter of the license. The compliance question always is: did their
distribution meet the terms required by the GPL?

Now, I’m talking above about the letter of the license. The spirit of
the license is something different. GPL exists (in part) to promote
collaboration, and if you make it difficult for those receiving your
distributions to easily share and improve the work with a larger
community, it’s still a fail (in a moral sense), but not a failure to
comply with the GPL. It’s a failure to treat the community well.
Frankly, no software license can effectively prevent annoying and
uncooperative behavior from those who seek to only follow the exact
letter of the rules.

Prominent Notices of Changes

Meanwhile, what people
are actually complaining
about is
that Red
Hat RHEL customers have access to better meta-information about why
various patches were applied.
Some have argued (quite reasonably) that this information is required
under GPLv2§2(a), but usually that section has been interpreted to
allow a very terse changelog. Corbet’s original article mentioned that
the
Red
Hat distribution of the kernel named Linux contains no changelog. I
see why he said that, because it took me some time to find it myself
(and an earlier version of this very blog post was therefore incorrect on that
point), but the src.rpm file does have what appears to be a
changelog embedded in the kernel.spec file. There’s also a
simple summary as well
that in
release notes found in a separate src.rpm (in the file called
kernel.xml). This material seems sufficient to me to meet the
letter-of-the-license compliance for GPLv2§2(a) requirements. I,
too, wish the log were a bit more readable and organized, but, again,
the debate isn’t about whether there’s optimal community cooperation
going on, but rather whether this distribution complies with the
GPL.

Relating This to the RHEL Model

My
previous blog post, which, while it was focused on answering the
question of whether or not Fedora is somehow inappropriately exploited
(via, say, proprietary relicensing) to build the RHEL business model,
also addressed the issue whether RHEL’s business model is
GPL-compliant. I didn’t think about that blog post in connection with
the distribution of the kernel named Linux issue, but even considering
that now, I still have no reason to believe RHEL’s business model is
non-compliant. (I continue to believe it’s unfriendly, of course.)

Varghese directly asked me if I felt the if you exercise GPL rights,
then your money’s no good here business model is an additional
restriction under GPLv2. I don’t think it is, and said so. Meanwhile, I was a bit
troubled by the conclusions Jake Edge came to regarding this. First
of all, I haven’t forgotten about Sveasoft (geez, who could?), but
that situation came up years after the RHEL business model started, so
Jake’s implication that Sveasoft “tried this model first” would
be wrong even if Sveasoft had an identical business
model.

However, the bigger difficulty in trying to use the Sveasoft
scenario as precedent (as Jake hints we should) is not only because of
the “link rot” Jake referenced, but also because
Sveasoft frequently modified their business model over a period of
years. There’s no way to coherently use them as an example for anything
but erratic behavior.

The RHEL model, by contrast, AFAICT, has been consistent for nearly a
decade. (It was once called the “Red Hat Advanced Server”,
but the business model seems to be the
same). Notwithstanding
Red Hat employees themselves, I’ve never talked to anyone who
particularly likes the RHEL business model or thinks it is
community-friendly, but I’ve also never received a report from
someone that showed a GPL violation there. Even the
“report” that first made me aware of the RHEL model, wherein
someone told me: I hired a guy to call Red Hat for service all day
every day for eight hours a day and those jerks at Red Hat said they
were going to cancel my contract didn’t sound like a GPL violation
to me. I’d cancel the guy’s contract, too, if his employee was calling
me for eight hours a day straight!

More importantly, though, I’m troubled that Jake indicates the RHEL
model requires people to trade their GPL rights for service,
because I don’t think that’s accurate. He goes further to say
that terminat[ing] … support contract for users that run their
own kernel … is another restriction on exercising GPL rights;
that’s very inaccurate. Refusing to support software that users have
modified is completely different from restricting their right to modify.
Given that the GPL was designed by a software developer (RMS), I find it
particularly unlikely that he would have intended GPL
to require distributors to provide support for any conceivable
modification. What software developers want a license that puts that
obligation hanging over their head?

The likely confusion here is using the word “restriction”
instead of “consequence”. It’s undeniable that your support
contractors may throw up their hands in disgust and quit if you modify
the software in some strange way and still expect support. It might
even be legitimately called a consequence of choosing to modify
your software. But, you weren’t restricted from making those
modifications — far from it.

As
I’ve written
about before, I think most work should always be paid by the hour
anyway, which is for me somewhat a matter of personal principle. I
therefore always remain skeptical of any software business model that
isn’t structured around the idea of a group of people getting paid for
the hours that they actually worked. But, it’s also clear to me that
the GPL doesn’t mandate that “hourly work contracts” are the
only possible compliant business model; there are clearly others that
are GPL compliant, too. Meanwhile, it’s also trivial to invent a
business model that isn’t GPL compliant — I see such every
day, on my ever-growing list of GPL violating companies who sell
binary software with no source (nor offer therefor) included. I do find
myself wishing that the people debating whether the exact right
number of angels are dancing on the head of this particular GPL pin
would instead spend some time helping to end the flagrant, constant, and
obvious GPL violations with which I spent much time dealing time each
week.

On that note, if you ever think that someone is violating the GPL,
(either for an esoteric reason or a mundane one), I hope that you
will attempt
to get it resolved, and report the violation to a copyright holder or
enforcement agent if you can’t. The part of this debate I find
particularly useful here is that people are considering
carefully whether or not various activities are GPL compliant. To quote
the signs all over New York City subways, If you see something, say
something. Always report suspicious activity around GPL software so
we find out together as a community if there’s really a GPL violation
going on, and correct it if there is.