What's the point of this article? [LWN.net]

You, go, Jon!

Posted Mar 21, 2011 4:14 UTC (Mon) by wahern (subscriber, #37304) [Link]

You have to admit, though, that's it's pretty galling of Google to process source files and strip copyright statements! And while it's inevitable for lawyers and legal professors who aren't also programmers to get some of their facts wrong, the arguments occurring in the legal sphere aren't "bullshit." Google is definitely rocking the boat, and you have to ask yourself which is better for the GPL--a state of legal uncertainty or of certainty. The answer is far from clear.

Here's the problem as far as I see it. While it might seem clear to us that a user-land program compiled against GPL'd kernel headers is not derivative, that will not be the question that goes to court (if this issue goes to court). The question that will go to court is, are Google's processed headers derivative of the unprocessed headers? That question is much closer, and if it comes out that they are derivative, it means that it's more likely that the first question will be answered that user-land programs are derivative. The outcome of this case would change the course of the law in an unexpected way.

And the fact that Google is running a simple program to mechanically process those headers... that's not the best case for a defendant to carry into court. It's one thing to re-create those headers by hand, it's another to mechanically transform them, the legal theory of derivative works notwithstanding.

You, go, Jon!

Posted Mar 21, 2011 4:59 UTC (Mon) by sfeam (subscriber, #2841) [Link]

If header files are not copyrightable in the first place, a position for which there is some precedent, then issues of stripping or not stripping, mechanically or manually, are moot.

You, go, Jon!

Posted Mar 21, 2011 6:00 UTC (Mon) by wahern (subscriber, #37304) [Link]

What precedent? I'm not aware of any precedent. (If you know of legal precedent, I would like to know about it. IANAL, but I intend to play one someday.)

Also, it's worth noting that Edward Naughton's description of Sega Enterprises v. Accolade (9th Cir. 1992) is totally wrong. (Atrociously wrong, in fact.) He used it as a possible defense for Google, but that case is quite the opposite. First of all, his description is totally wrong. Sega v. Accolade said that the disassembly *was* copyright infringement, but that it was a Fair Use. And it said that it was a Fair Use *not* because the copied code embodied the *idea* of interoperability (it rejected that subject-matter argument, as have most other courts), but only because it was the only way to get at otherwise uncopyrightable material.

In other words, the idea that particular source code is not copyrightable because it "merges" with the idea of interoperability or compatibility with an operating system is a bogus argument. (Rejected in Sega; rejected in Apple Computer v. Franklin Computer (3d Cir. 1983). Rejected in other cases.) The only way Google's theory holds water is if the source code at question itself is completely uncopyrightable, whether in a header file or any other file. And that means it must be bereft of any original creativity. (Under the Feist analysis, which found no copyright in a phone book because it listed residences in alphabetical order--an uncreative compilation of facts; begging the question of whether some other creative listing not in alphabetical order might be sufficient creativity to protect the phone book.)

Frankly, as a programmer I'm not so sure I want Google to be right.

Google can be wrong yet Android applications still be safe. Google could be wrong that a 10-line inline function is not copyrightable; but correct that a typedef is not copyrightable. And as long as the app only depends on the typedef and not the inline function, all is fine. Google will merely have to stop stripping copyright notices from source files--GPLv2 sec. 1 requires that the licensee "keep intact all the notices that refer to this License."

I suspect Google's legal theory is born of the abstraction/filtration/comparison test described in Computer Associates v. Altai, 982 F.2d 693 (2d Cir. 1992). Reading the case, or part III, or at least section III.A(2), is like a mini-education in copyright law as applied to computer programs. http://www.bitlaw.com/source/cases/copyright/altai.html

You, go, Jon!

Posted Mar 21, 2011 6:17 UTC (Mon) by wahern (subscriber, #37304) [Link]

I should be more clear. Merely because a header file describes a kernel interface doesn't mean that it's not copyrightable on an interoperability theory. It's copyrightable merely if the description itself is sufficiently creative. One way it would not be creative is if the expression is dictated by efficiency concerns, or general engineering best practice. But it's not lacking in creativity merely because it's describing some other code, and therefore hemmed in by the necessity of describing that other code. Even if the header is perfectly dictated by what it's describing (i.e. there's only one way to create the header), if what it's describing is copyrightable than so is the header.

Otherwise, a table of contents wouldn't be copyrightable merely because it's describing the book. But if each chapter heading has a creative aphorism, so does the table of contents; therefore the table of contents would be copyrightable.

Now, if you processed the table of contents, stripped out the chapter headings and were left only with a table of chapter numbers and pages, you would be solid. But that is not what Google is doing. If you think that by stripping out the comments all the copyrightable expression is gone, then you're implying that huge bodies of source code are not copyrightable by themselves, no matter what. That's a dangerous precedent.

Note that this isn't like the SCO case at all. That's a false comparison on so many levels.

You, go, Jon!

Posted Mar 21, 2011 18:33 UTC (Mon) by butlerm (subscriber, #13312) [Link]

What precedent? I'm not aware of any precedent. (If you know of legal precedent, I would like to know about it. IANAL, but I intend to play one someday.)

Try Baystate v. Bentley Systems (1996), which held that technical interfaces are not copyrightable, including structure layouts and element names. See here (pdf). It is hard to see what could be left in a stripped interface header file, other than complex macros or inline functions, which presumably have much stronger protection.

You, go, Jon!

Posted Mar 24, 2011 6:49 UTC (Thu) by branden (subscriber, #7029) [Link]

That's useful, but I cannot find any record that this decision was appealed.

This is important because the holdings in the case were by a federal *district* court. If it had been appealed, it would have gone to a federal appellate court--the holdings of appellate courts are binding upon that court's jurisdiction (the district, the circuit, or the entire U.S. depending on the appellate court level).

District Court opinions do not constitute precedent in the United States. Any court anywhere in the U.S., including that *same* district court, is at liberty to completely disregard the findings and results in this case (unless they have a local rule to the contrary, which might be the case).

You, go, Jon!

Posted Mar 24, 2011 16:24 UTC (Thu) by butlerm (subscriber, #13312) [Link]

District court decisions do not count as binding precedent, certainly. That doesn't mean they aren't widely influential, in terms of logic and reasoning. The idea is to interpret the law, not make it up, right?

If the district court's ruling is a tour de force of rationality, any other court is going to have a difficult time issuing a contrary one. This particular decision treated the issues here in greater depth than any previous U.S. court, and should reasonably be treated as a guide to the way other courts would rule when faced with the same question.

What Google's actually doing

Posted Mar 21, 2011 5:15 UTC (Mon) by jthill (guest, #56558) [Link]

What's left after their filter runs is, according to them, only the uncopyrightable part. There definitely is such a thing; the applicable standard for headers was settled in 2004 if not before.

And I think they have it right: "scènes à faire" material is material that has to be as it is in order to make things work. Presuming so:

There's nothing wrong with copying only what no one has a right to lock up, and nothing wrong with leaving the copyright notice behind with what it refers to.

Even if someone were to go to court claiming the headers themselves were still copyright, despite well-known and settled precedent, that still wouldn't begin to produce the kind of downstream uncertainty the shills are trilling about. Derivation isn't a one-drop-of-machine-oil-in-the-drinking-cistern thing: in order for inclusion to taint the result, the result's similarity to the original must be "substantial". Is your program, the work you produced and distribute, taken as a whole, substantially similar to any selection from linux/*.h? I thought not. You're safe, as is anyone using the headers Google supplies.

Anyone can sue anybody for anything, but the only possiblity here that's not completely laughable would be someone trying Google on for their interest in one or more of the headers. Whoever tried that would lose in as decisive, degrading and humiliating a defeat as SCO did years ago. I don't imagine anyone, no matter how well lubricated, is going to willingly go down that road.

What Google's actually doing

Posted Mar 21, 2011 6:46 UTC (Mon) by wahern (subscriber, #37304) [Link]

The scènes à faire argument doesn't suffice to explain their _wholesale_ copying. The idea that Linux's ctype.h header, for example, isn't copyrightable because it's describing a well known, published, operating system standard is based on the fact that there's really only one way to accomplish that description, and there's an implication that that element of the POSIX standard isn't copyrightable.

But a header describing an interface unique to a body of copyrightable code is completely unlike scènes à faire. Scènes à faire applies to plot devices like film noir private investigators. The mere fact of using one of those does not implicate infringement of some other movie also using those; because they both derive from a common cultural fountain. But if your film noir private investigator is Bob Smith, and so was the other movie's; and if both have a tattoo on their cheek, and various other character traits; that's not scènes à faire. Those specific things aren't drawing from a common fount of material.

Likewise, there's only one Linux. You can't copy Linux's interfaces based on the "idea" of compatibility with Linux's interfaces. That's like making an Indiana Jones sequel based on the "idea" of an Indiana Jones sequel. Indiana Jones isn't an idea; it's original and creative characters and plot devices aren't scènes à faire.

The only way you can copy it's interface descriptions without infringement is if the description itself is devoid of any copyrightable expression; no matter that it's intended for interoperability with the kernel. Yes, there are doubtless many examples of this. But to think that *every* structure, *every* inline function, *every* macro, or *every* collection of such things, is not copyrightable is extremely bold. And if you're right, it means that code of similar expressiveness in any source file is also not copyrightable.

Maybe that would be a good outcome for the software industry. But my gut reaction is that it would make it difficult for Free Software developers to prevent proprietary ripoffs of large chunks of code.

Also, you seem to be conflating issues of (a) substantial similarity, (b) what constitutes derivative works, and (c) Fair Use analysis. Suffice it to say there's not enough room or space to dive into those issues well enough here.

What Google's actually doing

Posted Mar 21, 2011 9:51 UTC (Mon) by foom (subscriber, #14868) [Link]

So you're arguing that userspace programs running on linux using those APIs actually need to be GPLed, despite the kernel authors' intent?

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 12:25 UTC (Mon) by dank (guest, #1865) [Link]

I think wahern is arguing that you need to strip out anything in the
headers that is not actually required to compile working apps.
That was clearly Google's intent, and if they succeeded, I think
they have met Linus's intent as expressed in his emails (and understood
in context, i.e. since Bionic is not a loadable kernel module, one
shouldn't apply Linus's comments about LKMs to it).

Let's examine the resulting headers to see how close Google came to this,
and see if we can find particular lines that are not forced by the kernel ABI.

I looked at one file,
http://lxr.e2g.org/source/bionic/libc/kernel/common/linux...
and saw a few things that seem like they could have been stripped out.
Two examples:

CONFIG_EXT3_INDEX is not unreferenced anywhere (see
http://lxr.e2g.org/ident?i=CONFIG_EXT3_INDEX )

ext3_debug is only referenced inside the kernel, and is defined by
the unstripped kernel headers (see
http://lxr.e2g.org/ident?i=ext3_debug )

I didn't see anything that is both required and 'expressive'.

I suspect the only thing Google ought to do is remove the symbols from the
headers that are not referenced by bionic, but since they're not
referenced, no actual harm has been done.

(Hi, Florian! Are you the same Florian I knew at Knowledge Adventure?)

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 14:42 UTC (Mon) by wahern (subscriber, #37304) [Link]

I agree that no significant practical harm is done if, in fact, nothing derivative has accidentally been caused to be created by third parties.

But the issues of third-party derivative works and Google's violation in stripping the license notices are separate. The only thing I'm arguing is that Google is likely violating copyright because they're not stripping all the expressive elements from the headers, and so had no right to remove the license notices. But whether a particular Android application is derivative of GPLd headers is a significantly more complex issue. Related, to be sure; but distinct.

For example, Linus's original caveat may be implicitly adopted by all the other contributors, and much like section 3 of the LGPLv3, grants the ability to incorporate or otherwise transform certain header code, such as "data structure layouts and accessors." But of course, such a right could only be granted if such elements were copyrightable; otherwise there would be no right to grant. That this section was inserted by the FSF doesn't mean they believe the elements were truly copyrightable, but clearly they had sound reasons for at least hedging. If the situation was so cut and dry, it would never have been added.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 15:31 UTC (Mon) by dank (guest, #1865) [Link]

To summarize my (weak) understanding:

0) Semantic information needed for userspace (libc or apps) to interoperate
with the kernel via public interfaces is either noncopyrightable because it's a published interface intended to be publicly usable, and/or can be used without infringing because Linus said so

1) The expression of that information in a particular header is copyrightable

2) A compiler or other semantic analyzer can extract the noncopyrightable
semantic information from a copyrighted header and dump it to a new sanitized header without infringing the header's copyright

3) Google intended to do that, but didn't quite do a thorough job, so there may be some residue of expressive, non-required, copyrightable code in the headers

4) The residue is probably not being referenced by Bionic or any third-party apps, so there are probably no infringing derivative works

5) Google could reduce the amount of residue if they wanted by adding
another scrubbing pass in the header filter code to remove symbols
not referenced by bionic libc or the apps that come with android
(and for that matter, replacing all possibly expressive whitespace);
this would strengthen their case that removing the license notices
is appropriate. Doing so now would be a fine example of responding to
a possible GPL violation in good faith.

6) Semantic information needed for kernel modules to interoperate
with the kernel via nonpublic interfaces is another matter, and does
not affect the Bionic discussion

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 15:34 UTC (Mon) by wingo (subscriber, #26929) [Link]

> 2) A compiler or other semantic analyzer can extract the noncopyrightable
> semantic information from a copyrighted header and dump it to a new
> sanitized header without infringing the header's copyright

This doesn't sound right; otherwise one would be able to do the same for source files as well.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 16:14 UTC (Mon) by dank (guest, #1865) [Link]

IANAL, but:
In the US, law recognizes that the boundary between "disallowable copy of the expression of an idea" and "allowable reuse of an idea" is a fuzzy one, and tends towards allowing the use of really simple, essential ideas (like how the lines of a financial table are laid out, or how the elements of a struct are laid out).
See http://www.bitlaw.com/source/cases/copyright/altai.html

Since the sanitized headers are (or should be) just a bunch of names, table offsets, sizes, and similar things, their use is likely the allowable reuse of ideas. This reading is bolstered by the fact that the authors of those lines of the kernel marked them with #ifndef __KERNEL__ to indicate they were intended to define the API to be used by userspace.
See http://lwn.net/Articles/244375/

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 3:52 UTC (Tue) by wahern (subscriber, #37304) [Link]

Here's the issue reduced to it's simplest form:

struct foo { int x, y; };

#if __KERNEL__

struct bar { int x, y; };

#end /* __KERNEL__ */

Now Google says that this is not copyrightable:

struct foo { int x, y; };

What, then, makes this copyrightable:

struct bar { int x, y; };

Either they both are, or neither. Whatever it is that makes one copyrightable also makes the other copyrightable; they rise and fall together. Whatever transformation makes one not copyrightable could make the other not copyrightable. They're symmetric. Those magic __KERNEL__ guards don't effect whether one section or the other can be copyrighted; they merely outline the contours of the explicit and implied license grants once we've established actual, copyrighted material.

The same symmetry applies further up the ladder. Either kernel interfaces are protected expression and Google is violating their license by stripping notices, or Google is in the clear and kernel interfaces en toto aren't protected. Again, the boundaries of those magical __KERNEL__ guards don't dictate what interfaces are copyrightable. The same Altai, SCO, et al analyses of copyrightable subject-matter apply equally across the board. For every ctype.h outside of the include guards, there's something equally insubstantially expressive within the include guards; and for every copyrightable selection within the include guards there's something equally substantially expressive outside of the include guards. It doesn't matter what the test is: qualitative versus quantitative, too abstract versus de minimis creativity.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 4:13 UTC (Tue) by dank (guest, #1865) [Link]

One story is that most examples of 'foo' are specified by
POSIX, and are stable, whereas most examples of 'bar' are unstable
internal kernel interfaces.
POSIX interface documentation is also available under a free license, see
http://www.redhat.com/archives/fedora-legal-list/2007-Dec...

But that's not enough; what about the other 'foo's that are part of Linux's extensions to POSIX?

Linus wrote on 19 Oct 2001 (see http://linuxmafia.com/faq/Kernel/proprietary-kernel-modul...):
"If you use standard UNIX system calls (with accepted Linux extensions), your program obviously doesn't "derive" from the kernel itself."

So there y'go. It's different because Linus said it is.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:23 UTC (Tue) by wahern (subscriber, #37304) [Link]

Just peruse the Android git tree. We're not talking about syscall tables for POSIX interfaces. Those sorts of things constitute a mere fraction of the total of their tree. Most of the tree defines interfaces to Linux-original subsystems.

Yes, most of the unguarded sections are meant to be used in user-space. That's inconsequential. That's like saying all of your header files for your libfoo are not copyrightable. What does it matter what it's going to be used for? What makes something copyrightable is inherent in the content, not the authors' intentions for it.

And the question of how "thin" your copyright can be in headers doesn't amount to much, either. Can there be copyright in "struct foo"? "struct foo; struct bar;"? "struct foo; struct bar; struce t baz"? Google is saying it doesn't matter. No code in headers is copyrightable, period. Which amounts to saying that copyright can't subsist in the definition of your API. Which begs the question, if an API isn't copyrightable how can you prevent derivative use of that API? You can't. Not until your code is linked and loaded and running with the implementation would it be derivative. Which means there's no functional difference between the GPL and LGPL, if what they're doing is legal.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:59 UTC (Tue) by viro (subscriber, #7872) [Link]

Oh, for pity sake... Use of system calls is NOT MAKING YOUR CODE DERVATVE. POSIX or not, doesn't matter - just read the sodding license, already. Permission to use the definitions needed for use of said system calls follows from that.

And frankly, what you are trying to push is vile. On par with look-and-feel copyrights.

Incidentally, if libfoo provides only one function that takes no arguments and returns int, not adding any #include at all will *NOT* allow you to escape the need to comply with the license of libfoo. And no, it's not because the identifier "foo" in int n = foo(); is copyrightable.

Get a clue, get a life and piss off, already...

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 16:42 UTC (Tue) by wahern (subscriber, #37304) [Link]

Not one thing you said in your comment disputes what I said, nor do I disagree with the specific points you made other than your slights against me. If only you would read English as closely as C.

And I will piss off. You can continue living in the dark. And you can continue thinking that you have to cling to an improper understanding of the issue because of some other consequence you can neither perceive nor articulate. You're inability to distinguish the legal argument from your commitment to supporting Google's otherwise laudable work is disappointing.

Good day, sir.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 16:53 UTC (Tue) by wahern (subscriber, #37304) [Link]

Actually, upon more careful reading I do disagree with what viro you said, because it's conflating copyright subject matter with licensing. What makes something derivative is a matter of law that can't be avoided by a license. Though I'm not disputing that mere use of a system call does not necessarily make something derivative (I'm not insinuating anything by being circumspect with my words, either); nor that a license can make derivative use okay.

I respond only to protect my name; what with archiving and all. I'm not returning to this thread for the foreseeable future.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 15:52 UTC (Tue) by sfeam (subscriber, #2841) [Link]

Bingo. Despite your implicit scepticism, this is the correct analysis. There is no functional difference between the GPLv2 and LGPLv2 in the case of an external library that is being linked. I limit that statement to v2 simply because I haven't examined v3 in enough detail to have a separate opinion. The FSF argues otherwise, but that does not make them correct on this point. You pointed that out yourself: "What makes something copyrightable is inherent in the content, not the authors' intentions for it." IANAL and all that.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 4:40 UTC (Tue) by swetland (subscriber, #63414) [Link]

I can't comment on theory about what's copyrightable or not (I'm not a lawyer), but I can offer this fact:

The primary motivator in subsetting the kernel headers is to end up with a minimal set of headers necessary to encompass the userspace<->kernel interface surface, and avoid clutter, confusion, or future brokenness by avoiding exposing userspace to anything more than is strictly necessary to make calls into the kernel.

From a support standpoint, anything in headers that doesn't need to be there (as far as structures, function declarations, etc) is something that might break when we refresh the headers from a newer kernel version.

Knowing the habits of application developers, if we didn't yank the #if __KERNEL__ sections, *somebody* would inevitably write code that #define __KERNEL__ 1 and included some linux header for some absurd reason and then they'd be cranky if it stopped working in the future.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 12:28 UTC (Tue) by ekj (guest, #1524) [Link]

In this particular example, both would probably be judged to be trivial, and to lack sufficient content to be worthy of copyright. Exactly what is worthy, varies by jurisdiction, but I'm not aware of any where "struct foo { int x, y; };" would suffice.

Notice, as a parallell, how Wikipedia commons claim, after careful legal review, that a flat-on photo of a 2-dimensional work of art, does not enjoy copyright. (the work of art may or may not, but the PHOTO as such, does not), because there's not sufficient creativity and/or artistic skill involved in the creation.

Copyright protects the expression of an idea, not the idea itself. So if a certain struct, or a certain photo, does not contribute beyond the idea itself, then it's not protected by copyright.

Yes the borders are fuzzy.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:09 UTC (Tue) by wahern (subscriber, #37304) [Link]

I wasn't trying to be literal. There's little doubt that "struct foo" is bereft of original, creative expression. It was merely an exercise which in substance is no different when you apply the analysis to the larger tree.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 23, 2011 8:18 UTC (Wed) by ekj (guest, #1524) [Link]

Like always with non-trivial question the answer is "it depends".

Some people in CompSci tends to think in overly strict principal lines, wanting the grey to go away. Perhaps this has something to do with how a computer works, in binary. But it's not how law works.

If one sentence contains insufficient creativity and/or artistic skill to be worthy of copyright, it does -not- follow that 50 similarily well-written sentences as a whole *also* does not deserve copyright.

In practice, merely doing more of the same, can give copyright. The creativity and/or artistic skill which is there adds up, and at some point crosses the threshold. This message as a whole, for example, may well be sufficient - whereas any individual sentence in it, would likely not be. (and I'm sure many of the sentences have been used in a very similar form before by others)

What I'm saying is, you *cannot* generalise from trivial examples to the whole tree. It's certainly possible that each of the examples, in isolation, is unprotected, while the sum total is protected.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 23, 2011 19:26 UTC (Wed) by martinfick (subscriber, #4455) [Link]

> Some people in CompSci tends to think in overly strict principal lines, wanting the grey to go away. Perhaps this has something to do with how a computer works, in binary. But it's not how law works.

Or perhaps it's how reasonable people think? Many laws are designed to be wishy washy so that the people who speak in vague illogical terms and who spend money on lawyers can take advantage of those reasonable people who don't. Copyright is just one of the many examples of this. Patents are an obvious other.

The fact that this discussion is currently over 100 comments of bickering over the understanding of copyright, likely by professionals who actually operate in the copyright field daily, should tell you that the concept of copyright is beyond grey, and very vague. This is not a subject matter that any law could ever be fair about. It is not a subject matter that you could expect juries to reasonably agree upon in a consistent matter. It is simply a bad use (not just a bad implementation) of law.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 22, 2011 14:43 UTC (Tue) by foom (subscriber, #14868) [Link]

So what are you arguing? That every userspace program is a derived work of the Linux Kernel? Because there's nothing substantially different from what glibc is doing than what bionic is doing; they rise and fall together.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 23, 2011 21:06 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

Either they both are, or neither. Whatever it is that makes one copyrightable also makes the other copyrightable; they rise and fall together.

Even if both are copyrightable, Google's ability to use them without getting in copyright trouble is not necessarily the same. It may be fair use to copy the public symbols because they are part of a defined interface and hence necessary for compatibility. The same does not hold for the internal interface.

Google should strip out unreferenced symbols... but it probably doesn't matter

Posted Mar 21, 2011 16:03 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

That the FSF states some right explicitly doesn't mean they think it's theirs to grant: Their stuff is meant more for the average programmer, who probably doesn't know squat about the nuances of what is and isn't allowed by copyright. Better spell it out, even if for somebody with legal training it is obvious. See some of the explanations in GPL for examples of the above.

What Google's actually doing

Posted Mar 21, 2011 9:52 UTC (Mon) by jthill (guest, #56558) [Link]

I think if you chase my link you'll find that wasn't the only grounds cited there, either, and as you say dissecting all the gory details could go on forever -- leading to the desperately-sought but false appearance of new scary possibilities.

Here:

the unprotectable elements of ideas, processes, facts, public domain, information, merger material, scènes à faire, and other unprotectable elements suggested by the particular facts of the program under examination.

That's what you have to remove from the allegedly infringing and allegedly infringed works before comparing the two for "substantial similarity".

Also, you seem to be conflating issues

I think if you reread what I wrote you'll see that the appearance was due to your own confusion, not mine. For one instance:

But to think that *every* structure, *every* [...] collection of such things, is not copyrightable

I don't think that. I think that what little remains, after you've stripped the headers of facts and information along with everything else, will be such an insignificant part of the linux kernel, of the ... ummm ... 12.7million-line "body of copyrightable code" they describe, that any attempt to claim substantial similarity to the whole shouldn't even merit laughter.

What Google's actually doing

Posted Mar 21, 2011 14:29 UTC (Mon) by wahern (subscriber, #37304) [Link]

If that is indeed the case (and you may very well be right), than how can copyright prevent distribution of binary modules built against those headers? If the actual header code itself describing a particular interface of the kernel isn't copyrightable (as the same expression or as derivative of the expression), then how can anything be derived from it?

If you say, "well, it's deriving from the interface, not the header code" then how is the header code likewise not also equally implicating this abstract interface? Certainly the header code often describes this interface in more exacting detail than the binary module. Some of the material you cited is predicated on the notion that the interface being described isn't copyrightable for very specific reasons relevant to the particular interfaces at issue--an extremely fact-centric analysis not likely to apply to Google's largely indiscriminate copying, __KERNEL__ guards notwithstanding.

Further more, your substantial similarity argument applies equally well--both quantitatively and qualitatively--to the binary modules' proposed infringement. Clearly, how we slice and dice the scope of the infringement is critical.

For something to be derivative, it must create a sufficient impression in one's mind of identifiable, copy-protected elements of the derived work. If a header file cannot do this, how can a binary module do this? It hardly matters that the binary module doesn't work without the Linux kernel. I can write a story in such a manner that every third page seques into a substantial Phillip K. Dick paragraph. And I can distribute that story, sans those paragraphs, if without those paragraphs you couldn't identify specific copy-protectable elements of Dick's stories. That when you put them together it becomes a derived work hardly matters by itself.

I'm not challenging the soundness of the cases you cite. I'm merely suggesting that those aren't necessarily applicable to Google's wholesale copying of huge portions of Linux kernel header code. And if Google is legally in the clear (which IMHO is doubtful with such a huge collection of code, no matter how thin the copyright), then there are tremendous, potentially undesirable consequences for copyleft enforcement. (Though a BSD-style license proponent might not care, and even might welcome it, as strict license enforcement is of lesser consequence and often creates more confusion than clarity.)

It would be interesting to read your reply, but this shall be my last. I don't mind if you get the last word; in fact I would prefer it ;)

What Google's actually doing

Posted Mar 21, 2011 18:51 UTC (Mon) by butlerm (subscriber, #13312) [Link]

If that is indeed the case[...], than how can copyright prevent distribution of binary modules built against those headers?

It can't. That is wishful thinking at this point, at least under current legal precedents (notably Baystate v. Bentley Systems (1996)). At best the license could be used to regulate joint distribution, and it is difficult to write a general purpose license that can clearly distinguish between joint distribution of copyleft and proprietary stuff which is allowed and joint distribution of copyleft and proprietary stuff which isn't allowed.

What Google's actually doing and Kernel modules proper

Posted Mar 22, 2011 4:03 UTC (Tue) by jthill (guest, #56558) [Link]

Well, if I were going to try to make Linus's argument about kernel modules, I wouldn't want to start out exasperated by a blinkered troll to the point of getting all capslocky, as he was.

Before changing the subject, though, let me just say that I've seen propagandists at work before. I'm seeing it again. Don't get sucked in by their misdirection; they will adeptly point in any direction but the ones that silence their alarms, and ignore or change the subject if you go that way yourself. They didn't, for instance, point out what Jake did and vonbrand highlighted, or any number of other obvious and relevant facts. Don't let them choose what you look at. The metaphor of the palantír might be worth revisiting.

One other thing needs addresssing. You say:

Sega v. Accolade said that the disassembly *was* copyright infringement, but that it was a Fair Use

(emphasis mine.) Erm, [citation needed]. Really. The law says, flat out, that no matter what §106 says

the fair use of a copyrighted work [] is not an infringement of copyright.

and the contradictory statement you attributed to the court appears nowhere in 977 F.2d 1510. I looked over it fairly carefully, looking for anything that might have led you to believe what you say. Where is it, please?

=====

So let's change the subject, as you like. From here on, this is just conversation, not debate or argument. It hasn't had time to steep.

The first thing I notice is I'm not sure I agree with Linus, and I'm certain rms disagrees -- at least to the extent that merely including the header does it. (Slashdot pays off with a timely memory). To allege infringement, which is necessary to assert the right to dictate license terms, you have to pass the same test we've been discussing: show that copying occurred, and

whether, as a mixed issue of fact and law, those elements of the program that have been copied are protected expression and of such importance to the copied work that the appropriation is actionable

That, by the way, is not mine, it's the case cited in the IBM deposition I linked, Gates v. Bando,9 F.3d 823. It's at least one of the rules that got the Judge to later caustically refer to "the vast disparity between SCO's public accusations and its actual evidence--or complete lack thereof". So I'm fond of the case anyway, but I like the phrasing because it seems to me it manages concisely stating the general criteria while simultaneously respecting fair use and de minimus.

Anyway, for outside-the-kernel code I agree completely with Stallman (and following Jake's logic, Linus does too; certainly other posters in that thread do): including header material, anything up to pedestrian macros/inlines, cannot bind you. A few structs and an inline, even if they're protectable at all, simply aren't of any actionable importance to the linux kernel. Anybody trying to claim actionable copying there is I think plainly living deep inside anybody-for-anything nutjob/agitator territory.

For in-kernel code it's not so plain, on any count. We have the extent of the copied protected material, the relative importance of the copied portions, and now the resulting harm to the copyright holder comes into play, where nothing reached it before.

Binaries are subject to copyright license terms, we all take that for granted yes? That brings the binaries into question when assessing what elements of the work have been copied, and that means that copying the entire kernel into memory in order to get any benefit of the kernel module is significant: without the full kernel, it isn't just that the source won't run, it's that this so clearly highlights that the work is incomplete without this particular kernel.

From that vantage, "those elements of the program that have been copied" no longer refers only to the portions of the kernel source that appear in the module source, it also refers to the portions of the kernel binary that have been copied into the kernel module -- which, without the kernel binary, is incomplete, so what's actually copied, soon or late, is (virtually) all of it.

That's the part I'm not sure I agree with. Code isn't album tracks isn't movies isn't books isn't blah blah blah. I think _this_ question is fully open to case law, up to any judges involved to decide on the merits of the arguments presented to them what constitutes the resulting "work" with modules necessarily built specifically for a particular kernel version. I also think it's pretty much moot: was the GPL'd-shim stunt invented after his post? Wouldn't surprise me, and it seems not to be drawing any fire from the people who have any standing to bring it.

But I'm not unsure about the objections you raise. They're wrong. I wish you hadn't just dropped them into the thread, I don't think what I find wrong with them is hard to see.

Much as I love the Dick reference. (It seems more apt, more tasty, more, erm, Perky, the longer I contemplate it), details matter. For literature, even two words can be immortal prose, a paragraph is enough to change lives. Binary kernel modules live by different rules, not only by their own nature, but by the kernel's: for starters, books aren't constantly amended by their authors; your writing your literary plugin doesn't seem likely to interfere. So your analogy is much too inexact. As with scènes à faire, I think the concepts still apply, but applying them needs to honor the differences along with the similarities.

I can see that Google's mass-edit offends you and as I think I said earlier it sure got my attention. But there's nothing to see here.

It seems what they're doing is ensnaring a relatively trifling amount of protected code, and as I think I said earlier, there isn't any copyright on just the headers portion of the kernel source any more than there is on any subset of any work: you have to identify the whole work that's being excerpted to properly assess how much was copied. Google's rendered headers do not resemble the kernel. Google's rendered ext2_fs.h does not resemble the kernel's ext2fs module.

The entire net effect that I can see from this is their customers will be very baffled when the alarmists start spewing tripe in their ears about how the GPL eats babies. We already agreed just including a header doesn't even remotely infringe, but that's not what you hear from the shills. So now their customers will have their lawyers look at it, and their lawyers will say "What license terms? There's nothing to license here." This isn't harm, this is a good thing.

What goes in headers isn't like what goes in source. The headers aren't all the source, and copying all the headers isn't the same as copying all of any code any more than copying all the names and descriptions of people mentioned in a newspaper is copying all the stories about them.

So your implicit-slippery-slope argument, that copying the headers is tantamaount to copying everything, just look to me like fearful and thoughtless nonsense. Google is in the clear because the two aren't the same. Leave aside any de minimus test, I'm having a hard time finding any actual harm in it at all -- since afaict no one is relieved of or ducking any actual obligations. But I'm out of patience with this, so if I've missed something please point it out kindly.

You, go, Jon!

Posted Mar 21, 2011 15:04 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Non sequitur. If programs compiled using the kernel's headers aren't derivatives of the kernel, how can programs compiled against other header files be derivative of the kernel? Sure, the munging of the original header files to create the new ones might be suspect, but that doesn't change the above fact.

You, go, Jake!

Posted Mar 21, 2011 12:53 UTC (Mon) by corbet (editor, #1) [Link]

Glad you like it - but do note that Jake wrote this article, not me.