Monday, June 25, 2012

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.

Monday, June 18, 2012

My next year's business expansion plans

I may cross-post this to Perspectives on LedgerSMB at some point but for now it is just here.

Before I start I would like to make it clear that I am not recommending that every business in open source publicly announce what areas they are going to get into ahead of time.  There are often areas where letting competition know what you are doing in advance is a bad idea.  Having carefully considered this, I do not believe this is one of them.   The reason is that at this point I have been doing a solid majority of the development work on LedgerSMB for the last six years.  I am at the center of the community, and nobody can take that away from me in the next year.  Chances are if someone simply tries to do what I am outlining here they will fail and I will pick up their customers.  However if you pick something else you have the opportunity to build your own community around your own solutions.  So hey, knock yourself out.  Try it.  I will even share advice/experience.  The further you go the more successful you will likely make me so I am all for it.

A second point in prelude is that this post also gets into areas where open source financing of development really doesn't work so well.  Identifying these areas is important for open source businesses because it allows us to find alternative structures for funding solutions.

The areas we are going into within the next year are no exceptions.  These areas require frequent updates for regulatory compliance reasons and so you run into trouble with a few people consistently paying for everyone else's continuing use of the software and services.  I don't believe that will work.  Therefore we are pushing these areas into subscriptions which include support and some other goodies.

The areas of support include:

  1. Electronic submission of taxes or revenues to relevant authorities.
  2. Payroll logic per jurisdiction's requirements
  3. Third-party certified versions for uses where certification is important (for example, credit card processing)
Again each of these areas requires a different model of spreading out the cost compared to standard major feature development (which has supported my business for years).

The second major problem, behind spreading the cost, is that the first two are big problems which vary considerably from one jurisdiction to another.  I don't think it is sufficient to hire people to keep up with foreign tax rules, so the approach I am taking is trying to partner with people in each jurisdiction to ensure the payroll and submission logic gets updated when it needs to.  They do the research and keep in touch with developers on my side.  We keep it up to date.  revenues are split.