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.

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.

The Story Behind CVE-2006-4244 and LedgerSMB

In general, one would think that when the author of software would fix major security issues as soon as possible. However, this is not always done. This entry shows my experience in the area of security disclosure when things go horribly wrong and when outright lies are told about people who work tirelessly to help ensure the security of their customers. In this latter category I find myself along with a couple others. It is hoped that others will find it easier to avoid some of the mistakes that I have made in approaching what became a very volatile situation. Furthermore, I would normally leave private emails private, but when public attacks are made on me, I do not feel the obligation to keep the attackers' emails private.

About a year ago, I discovered what I thought was a dangerous but contained exploit in SQL-Ledger. I promptly filed a bug report with the maintainer privately via the web site for which I received no reply. At the time, I suggested I would create a patch on my own and submit the report to Bugtraq if it was not fixed within 30 days. The only problem was that I didn't have any time, so the patch never got written. I didn't want to go to Bugtraq and simply cause many people to have horribly exposed systems so I kept silent. However, I was no longer happy with the way the application was maintained and I informed my customers of what they could do to minimize exposure to attack.

In April, I received a number of very hostile emails from the maintainer of the software for my efforts to build community-maintained documentation. I made the mistake of trying to get him to address my security concerns. He stated that he was not interested in fixing the problem.

On April 17th I wrote:

Session id's are not tracked by login on the server, allowing session

hijacking or even logging on once the user's .conf file exists without a

password.  The old password authentication was therefore more secure

than the current system.
To which he replied:



try it, crack it, hack it. server side cookies are a big security risk,

not client side cookies. The onus is on the user to log out, why should

the server babysit.
This reply indicated to me that he simply didn't understand the problem.  The issue is that one simply cannot trust a client that the administrator may have no control over more than the server.  At the time, I was not yet aware of the entire scope of the problem.    Indeed on a cursory code review, I would find that the session id was simply the UNIX epoch timestamp (or the return value from the Perl time function).  At this point, the full issue struck me and I was faced with a serious decision to make: whether to continue to trust Dieter or not with the security of my customers.  After discussing the matter for a while with others, I reluctantly decided that the only thing I could do was fork the software, especially .  This decision was made in early June, but at the time, I did not have the resources to seriously pursue creating such a fork.  And so things remained for another couple of months.

The catalyst for change came when I was approached by Josh Berkus and asked a number of questions about the viability of the SQL-Ledger community.  Josh introduced me to Chris Murtagh with the idea that we might be able to collaborate on a fork.  While I think that Josh's main interest was in having a fork, my main interest was in getting a security solution for my customers.  Within a day, Chris had created a basic patch which needed some tuning but corrected the problem relatively nicely by tracking random session id's in the database.  While this patch is not perfect, it actually provides an authentication system that is at least up to industry standards.  At that point we notified the list and Bugtraq did some further development and notified the list.  Chris sent the email to the list and I sent the email to Bugtraq.

At that point things got ugly.  Dieter's initial reply to Chris for the posting included this tidbit:

Now if you want to scare everyone start with how unsafe Windows is,

heck even Linux and tell everyone that if you don't lock this or that

anyone can attack you. Will it serve any purpose? NO!
Again, one must eventually conclude that Dieter did not understand that this was a fundamental design flaw in the authentication system of his application.  It is simply not possible to lock this problem out.  After another day we fully tested the patch and sent it to Dieter.  In the mean time, I got this nice email from Dieter:

Then fix it and submit a patch. It serves no purpose to fearmonger.



Did you ever wonder why Microsoft does not just buy out SQL-Ledger? It

would be drop in the bucket for them to get rid of the competition but

guys like you do it for them, and at no cost to them to boot.

Menschenskind how stupid is that?



Think what you do. It affects you just as it affects me, you more so

because if you force me to go proprietary you get no more code. Maybe you

think this will be a service to the general public to keep my code and the

code from other contributors out of the public protecting them from

"vulnerabilities" which are easily squashes if a person does the right

thing. THINK ABOUT IT, not scare the public!
The morning after we sent the patch, we got the following email:


Did you ever ask yourself how a user could get in if he does not have a

shell account. No shell account, no way to create a cookie file.



What you are doing is false sense of security because you believe it is

now safe for a user to have a shell account but in fact you just exposed

your system more so than before.



Think about it!



Your house is safe if you throw away the key. By not giving the user shell

access you throw away the key.
This email was so odd, it almost defies a response...  I suppose that in some exotic environments shell access might be required to create a cookie, but in the vast majority of environments (including essentially all Windows and Mac environments and most Linux and UNIX environments), shell access doesn't make a difference.

But by that point we were already working on our fork.  Since that point, Dieter has publically stated that it is a very technical issue which is not a serious problem.  Yet the National Vulnerability Database gives it a severity rating of 7 (high).

Preparing the fork took Chris and I about a week and a half of nearly sleepless nights.  Both of us are fathers of young children.  We both have families and other time commitments.  This has been an unbelievably exhausting time.  And in the end, we were publically attacked for our efforts.

A couple points to repeat for emphasis:

1. We created the security patch before starting work on the fork.
2. The release LedgerSMB took more than another week.
3. SQL-Ledger *still* has no official patch over a week
   
4. Dieter still suggests it is not a big deal despite the fact that nearly every private security company acknowledges that it is a serious problem.

Now, if I could do some things differently, I would. I have learned a number of valuable lessons from this experience.

1. I would not have confronted the maintainer of the software when he was already upset at me.
2. I would have gone to Bugtraq even without a patch in hand. In the end, perhaps this could have been avoided and the problem fixed a year ago had I followed through with my original plan.

Yet to my knowledge this vulnerability has not yet been exploited. I guess that as rough as this has been, it might save some people problems,

An example of an Open Source Business

My business has been doing a fair bit of work on an open source accounting package called SQL-Ledger. In particular, we have built a wiki for community documentation and have created a package of enhanced point of sale features for this software. In the end, this has accounted for around 20% of our revenue in 2005.

Naturally, everything we do is contributed back to the community. Many of our design changes have been accepted and merged into the main source tree for SQL-Ledger, but many have not. This is because some of our changes are not considered relevant to all deployments, and some are considered to be difficult to implement automatically in Windows environments. This means that for our work, we have a better platform to add even more features, and yet people who want a full-featured retail management environment based on Free/Open Source Software still cannot get it out of the box and have to come to us. Hence our costs are reduced, and we get help from across the community in maintaining some of our core features.

So if you are trying to start a business regarding Free/Open Source Software, it doesn't hurt to make an add-on for an existing software project that meets some specific need.

Diversion into politics

Well, Karl Rove is now the talk of the nation. I try not to use this blog to discuss my political views, so this will be as far removed from partisan politics as possible.

It is clear to me that Bush's only responsible choice would be to fire Rove. Bush isn't stupid-- he is a brilliant propagandist and someone who has been remarkably successful at pushing through his agenda items (both foreign and domestic). If Bush has a failing here, it is in his aquiescence to scandal within his administration. It would have certainly been better politically for him to fire Rumsfeld after Abu Ghraib and try to put that matter behind the administration.

In international law (IANAL) there is a concept called "Command Responsibility." Under this concept, a leader is responsible for the conduct of those who report to him. These responsiblities include the requirement that the leader appropriately discipline subordinates who act in violation of such laws (this has been a large part of the case against Milosevic). The idea is that the failure to provide such discipline when the leader knew or should have known about the offense actually means that the leader was aquiescent to the offence (sort of the "Don't violate the law, now" wink, wink, nudge, nudge approach).

Bush owes it to his administration, his party, and ultimately his country to appropriately discipline those who are responsible for wrongdoing within his administration. He has publically stated that whoever was involved in the Plame leak would be fired, and backing off from that position now would be ultimately damaging to his administration and his party. It would also help the Democrats cement their opposition to the Bush agenda.

In politics, nothing works better than an enemy to mobilize forces. I wonder how well right-wing politicians would like it if Roe v. Wade was overturned as this would significantly dampen their propaganda capabilities. I say right-wing because there are many Republicans who support abortion rights (along with the majority of Americans). Similarly, I wonder if the Democrats (this is largely a partisan issue) would really like it if the Bush administration did fire Rove, as this would reduce their propaganda capabilities. Bush has nothing to lose from firing Rove. His party has nothing to lose. And Bush has everything to gain by stating that he will not tolerate such behavior even from those in the most privileged positions of his administration.

Why McVoy is wrong about Open Source

Forbes Magazine posted an article where they summarize Larry McVoy of Bitmover. Larry made the following points:

• Open Source is unsustainable.


• Open source can't make enough money to produce the next generation of software

This article will demonstrate why Larry is fundamentally wrong in both these assertions.

Sustainability of Open Source Software

McVoy does have a minor point in that it can be somewhat difficult to begin work on the next generation of an open source program and spread out the cost of development in a reasonable way. Completely rewriting software is a difficult proposal in Open Source software.

However, this does not mean that it cannot be done. One basically has two choices: either one can charge enough for services (including further development services) on the current generation of the software to be able to facilitate the development of the next version or you have to break up your improvements such that they can be done by a large number of non-intrusive patches. In reality most projects rely on a combination of both approaches.

Secondly McVoy seems to feel that the primary market for Open Source in companies is in support services. While Red Hat has certainly shown that such support services can be valuable and profitable, and while many companies have run into trouble doing customized solutions, I still think that custom development is often overlooked as a potentially major source of revenue. Such custom development is difficult to get right-- it requires an eye for features which others can use too, and an ability to write them so that they are generally useful and can be contributed back to the main project for the next release. Also custom development revenue is beneficial because it can allow you to build a truely customercentric project.

Innovation and Open Source

Innovation is a marketing term which has lost most or all of its original meaning. That is not to say that there is no innovative software out there, but most software that is marketed as innovative isn't. Real innovation from a user's perspective doesn't come from having a large number of paid developers working on a difficult problem, as the result will almost certainly be hidden from the user. Instead it comes from a single person saying "Wouldn't it be great if..." And in the world of software, very very few programs continue to develop innovatively beyond the first few versions.

Open source software is no different, but they are more likely to add new innovative features during future versions. This is because one enlists the user (who is more likely to be buying services rather than buying mere software) into this process. The user often has a direct channel to the developers, especially if development services are sold. The user can then be free to say "This would work better for me if... or Wow, I wish it had this feature-- that would revolutionize my life/business/whatever." Indeed the ability for the user to innovate and pay developers for features that they dream up not only pushes the innovation forward in open source software but it also provides a powerful selling point for custom development services.

Larry McVoy is categorically wrong about the economics of open source. He represents a common but myopic view of how money can be made and overlooks a large number of factors which discredit his argument.

Obstacles to Open Source

Linux shipped on 5% of desktops last year. This article looks at the obstacles regarding customer adoption of open source in general. It should be noted that most of the systems that ship with Linux include proprietary software and the distributions are not reproduceable in their entirity.

Difference in Solutions And Customer Expectations

Most customers enter the Linux world with expectations informed by their experiences with Mac OS and Windows. This can create a few usability issues, but the larger issue is that of software procurement and solution building. Most desktop systems sold with Linux (Xandros, Linspire, etc) ship with proprietary, commercial software similar to the way in which it is sold for Windows and MacOS. This is an important observation because the same trend used to old in the server markets as well but as the market matured, these players (anyone remember Caldera?) have more or less disappeared.

People new to Linux think that there is a lack of available software. In reality, there is a huge variety of software available to suit all needs. They range from arcane command-line tools to simple graphical tools and even sophisticated office suites. There is indeed at least as much variety of software on Linux as there is on Windows.

But the software is fundamentally different in nature and how it is best procured. With Windows, you normally go to the store, pay a few hundred dollars for a tool, and go home and install it. With Linux, often you may either do your own research or pay a consultant a comparable fee to determine which tools are best, download them, and set them up so that you have a complete system. This can go for simple CD mastering and burning software to complex aggregates of software like those for doing e-commerce fulfillment systems. Contrary to popular it does not usually cost any more to run Linux software even including services than it does for Windows. But because this solution is still foreign to many users, they are afraid to use it.

Question of Ownership

When a complete solution is purchased from a company, there is a perception that the vendor owns the solution in terms of support, fitness for a purpose, etc. even though responsibility for these issues is usually expressly denied in the End User License Agreement (EULA). Instead, if the solution is put together via many small pieces by a consultant, the business who uses that owns the product and may need to rely on outside support for maintenance and software support.

One area where this is a real issue is in support but in larger business systems this is less of an issue because these systems tend to be often aggregate systems as well (which is why open source is hitting the server area first).

However, in most cases, the desktop tools are simple enough to make this effectively a non-issue. With good error reporting, it should be easy for any third-party consultant to troubleshoot the systems. For example, take the tool known as File-roller (similar to Winzip but with more functionality). Fileroller requires various command-line utilities such as tar, gzip, zip, ar, and more. If one of these tools is missing or not working, it is easy to determine which one and replace it. This is certainly no worse than the sort of DLL-Hell that exists on Windows anyway.

Cost of Migration

The final issue that causes issues for Linux adoption is that of cost of migration. Linux is generally less costly for new deployments in which there are no legacy application requirements for. However, for those organizations already dependent on Windows, it can take years to get to the point of being able to migrate the actual operating systems. This is rather a strategic goal and something that companies might move towards than something that they generally do. So we will probably not see mass migrations for the next 3-4 years.

These obstacles are not ones which say that companies can never adopt Linux on the desktop but rather indicates why growth is slow and why it is happening primarily in proprietary software bundles at the moment.