Why Binary-only Linux kernel modules are not necessarily Illegal

Recently I came across an old article, but the points in it are typically made today (as a recent argument between myself and Rick Moen shows) and so it's worth rebutting though late.

The argument, as expressed by Chromatic and others, is that if you incorporate expression in one work into another then that necessarily creates a situation where copyright permission is required.  This premise doesn't work very well in the area of computer software, and at least in the US, courts have refused to draw a hard line.

As an introductory note, IANAL, TINLA, and if you want legal advice don't get it off blogs but talk to a Real Attorney(TM) about your Real Case (TM).  Additionally this only applies to the US, though I would generally expect that other countries would have similar rules though the exact place where the lines may be drawn may be deceptively different.  All the more reason to talk to an attorney.

The key issue is a small piece of US statute, 17 USC 102(b), which limits the applicability of copyright to areas where patents are the correct tool.  The statute reads "In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. [emphasis added]"  The effect of this statute is supposed to prevent copyright from being used to monopolize markets for practical tools (patents are the appropriate tool there).


This means that copyright generally protects expression only to the extent it can be separated from function in a software program, and this is not an easy line to draw.  Typically courts seem to look to how easily a section of code can be rewritten such that it does not include the structure, and what the real-world constraints in place are.   It is unlikely that the mere inclusion of API specifications (via a C header file) would be outside the safe harbor that 17 USC 102(b) provides, and therefore one would not need a library owners permission at all to distribute software compiled against that library.


This is generally a good thing.  Certainly those of us in the Free and Open Source Software movements would not be happy with a view of copyright that would require Microsoft's permission (as a matter of copyright law) to compile code against Windows system libraries.  The idea that this is a functional tool and that use of the tool, and combining it with other tools, is beyond the control of the designer through copyright methods, is not something that is very controversial outside the influence of the FSF and there is a growing body of case law which suggests in fact that copyright law is more constrained regarding software than many software vendors and developers would like to think.  Again, I think this is generally a good thing.


Software is, of course, protected by copyright to some degree.  Literal copying of Windows CD's is copyright violation and there is little disagreement about that fact either.   But the sort of protection that copyright provides software authors strikes me as a bit of a corner case, and that applying tools designed to protect authors in the literary arts to those who create functional tools is a bit like driving nails using an adjustable wrench as a hammer.  It works, kinda, but with some odd surprises and traps.  Patents, on the other hand, offer the sort of protection that authors want, but with far more limited times.


There has never been a case in the US that I am aware of, which has ever held that the mere fact that copying of code is required to achieve interoperability has meant that the author of the original practical tool has any say whatsoever on the secondary add-in markets as a matter of copyright law.  In fact the cases which have considered this question have without fail sided against the copyright holders, sometimes citing 17 USC 102(b).  Applicable cases include Galoob v. Nintendo (and the line drawn between that case and Midway v. Arctic), Lexmark v. Static Control, SCO v. IBM, and Oracle v. Google.  These cases, effectively doom the idea that a copyright owner has a say over how copyrighted works that represent practical tools are used after the fact.


In Louis Galoob v. Nintendo, the software at issue was a program called "Game Genie" which allowed users to skip levels, and otherwise modify game behavior.  Import of the software had been banned, and the plaintiff was suing to get a judgement that this did not violate US copyright law under Midway v. Arctic (which had held that software which modified Pac Man in some ways created a new audio-visual work and therefore ran afoul with the exclusive rights of the copyright holder to control the creation of derivative works).  The court concluded that Game Genie did transform the audio visual work but only in ways that were deemed fair use, akin to the fast forward button on a VCR being used to skip scenes of a movie that was rented.   One way to understand the differences between these cases is that in Louis Galoob the court concluded that the software at issue was a practical device, much like a VCR, while the software at issue in Midway created a new game, and hence a new literary work.


In Lexmark v. Static Control, the issue was whether literal copying of code required to allow third party toner cartridges to be used with laser printers was copyright infringement.  On appeal, the three judges on the panel each wrote separately, but only one found that there was any grounds for infringement at all (and he concurred in judgement on other grounds).  The other two judges found that 17 USC 102(b) protected Static Control because the practical constraints made rewriting the software at issue not particularly desirable, and the fact that it was theoretically possible was not enough to overcome the fact that this was in essence a lockout code, of pure practical (rather than expressive) function and therefore unprotected by copyright.  The concurrence went further and said (as I have argued) that there is a clear line which says you can't use copyright to monopolize secondary markets for practical (and especially manufactured) devices.


In SCO v. IBM, the court said that derivation is not contagious, and this places considerable limitations on applying the GPL to bridges between proprietary and open source components.


In Oracle v. Google, the court ruled that API's are not protected by copyright and that literal copying required to duplicate or use API's is therefore not protected.  This is, I believe the final nail in the coffin for the idea that the GPL prohibits linking to programs of incompatible licenses generally.


For these reasons, I think that the FSF's view overreaches, and that the GPL does not prohibit linking generally because distributing software that is compiled against another program doesn't require copyright permission at all (and unless it is an audio-visual work, is protected under 17 USC 102(b)).  This doesn't mean that it is always safe to do so, but that linking is neither necessary nor sufficient to create a derivative work.  One significant caveat I would bring up however is that when distributing statically linked files, the question is whether the GPL offers a license to distribute the statically linked component in this form.  The GPL v2 might or might not (I think it probably does but am not sure as the license could be plausibly read both ways).  The GPL v3 tries very hard to say it doesn't.  This doesn't prevent static linking of course.  It just prevents distribution of the GPL'd component statically linked into another program.  Having the customer do the static linking seems safe in terms of prevailing on the basis of existing case law.  Whether one wants to be in a position of doing that however is a different question.


So I side with Linus here.  Binary only drivers might at some point become so heavily intertwined as to be properly seen as derivative works in themselves, but the mere fact that they link is grossly insufficient.