Leading items

How not to handle a licensing violation

For a long time, Broadcom 43xx wireless interfaces had no free Linux driver. Happily, a dedicated group of developers reverse engineered the device, and, over time, were able to create the missing driver. In the process, they implemented some features which were not available in Broadcom's proprietary driver. Not wanting their code to become part of the proprietary version, the Linux bcm43xx developers chose the GPL for their code - a choice that most other Linux driver developers make as well.

More recently, the bcm43xx developers noticed that the OpenBSD "bcw" driver looked very much like their code. It would appear that the developer of this driver looked to the Linux code for inspiration and took a bit more than just ideas. GPL-licensed code is meant to be shared and reused, but it is not meant to be relicensed unilaterally by third parties. So the bcm43xx hackers decided to talk to the OpenBSD developer about the apparent copying which had taken place.

Unfortunately, their message was copied to a rather large number of people, along with a few mailing lists. The response from the OpenBSD side took two forms, neither of which will be at all surprising to those who have watched how that community operates:

• The OpenBSD developers do honestly care about the provenance and legitimacy of their code. So the claims were taken seriously; OpenBSD leader Theo de Raadt remarked "This is a major problem in our code base" and said that the issue would be resolved.

• Those developers immediately launched a counterattack as if they were a beehive which had just been hit by a rock. They complained about the wide distribution of the mail, tore into the bcm43xx developers (example: "You are a very poor example of humankind"), repeatedly put down the "precious GPL," and, inevitably, dragged their maintenance of OpenSSH into the discussion. To many, it looked like an overt attempt to attack the messenger and take attention away from the real problem.

In theory, this situation should be simple to resolve. The OpenBSD developer, Marcus Glocker, has acknowledged the problem and stated that he was aware of it before the discussion began. He says:

The bcm43xx developers have said from the outset that they would be willing to relicense at least some of the affected code. The two groups should be able to sit down, talk things through, and end up with everybody being happy.

That has not happened. Instead, we got a nasty flame war, the outright deletion of the OpenBSD bcw driver, and the bizarre sight of Theo de Raadt claiming that he is the person with "at least some fucking empathy in my soul." That is not how things should have gone. There need be no enmity between the Linux and BSD communities; when something like this happens it's worth looking at why in the hope of avoiding a recurrence in the future.

The initial contact from the Linux side was clearly mishandled. When licensing issues come up, the generally-accepted first step is a quiet, polite, private message seeking a solution. People rarely respond well when the first communication about a problem is broadcast to the world. Had the bcm43xx developers conducted a private chat with the OpenBSD bcw developer, chances are that the issues would have been worked out with relatively little fuss. Most developers are interested in solving problems, after all.

The OpenBSD crowd also missed its chance for a quiet solution when it went on the attack. Attempts to divert the discussion through ad hominem attacks, profanity, and general bluster will never lead to a civil conversation or a peaceful resolution of a problem. Deleting the bcw driver (and blaming the Linux community for its loss) seems childish at best. The use of OpenSSH as a sort of trump card is just strange, and a little worrying.

Needless to say, it would also have been better if the code had not been used contrary to its license in the first place. But code licensing issues are complex. In a world where vast amounts of code are floating around under mutually-incompatible licenses, the occasional problem is certain to turn up. That's why the "open source licensing compliance" companies are able to make a living. But licensing disagreements between free software projects are rarely so intractable that they cannot be solved by rational discussion. The next time a situation like this comes up - something which is certain to happen, sooner or later, and the Linux community might just find itself on the other side of the table - we can only hope that all of the people involved will approach a solution in a way which allows that rational discussion to take place.

Comments (103 posted)

Two examples of abandoned hardware

LWN's review of the Nokia N800 (published in March) was rather strongly criticized by one commenter who felt that the "partly open" nature of the device had been skipped over. The commenter also wished that Nokia's abandonment of the 770 tablet had been discussed. He has a point, and recent developments merit another look at this issue.

Back in January, Ari Jaaksi, Nokia's head of open source software operations, wrote about the fate of the 770:

Few people would disagree with the goal of offering better hardware over time - we have all come to expect that, actually. But that does not mean we want our old hardware to turn into paperweights, so the "supports it fully" statement was taken as a good sign by Nokia 770 owners. Many of those owners are expressing their disappointment, however, now that Nokia has started closing bugs with a message saying "WONTFIX. No fixes to N770 anymore." It seems they had thought that "supports it fully" meant that the product was, well, supported fully.

Nokia's Quim Gil has clarified what Nokia means by "full support":

In other words, 770 users can expect the device to not turn into a brick overnight, but not a whole lot more. Mr. Gil does go on to say that severe security problems would be fixed, but that seems to be about the extent of it. There are no plans for another system software release for the 770. There is an OS 2007 on 770 project which is working at porting a version of OS 2007 (the version running on the N800) to the 770 as a "hacker edition," but some parts of it work better than others, and it's not likely to be what many 770 owners had in mind. The hacker edition will not be a supported product.

It's tempting to say that, since the 770 is a Linux-based device, the community should be able to support it into the future. As long as people care about the platform, it should continue to work. The problem is that the 770 contains a fair amount of non-free software at all levels. It seems that Nokia's agreement with Opera prohibits them from providing a new version of the browser for the 770. Some of the power management code is proprietary, as are various other pieces of the system. So, even if the "hacker edition" can be made to work, it will be a system with a number of binary blobs in important places. That will severely limit the degree to which the community can support the platform; it's a slow death sentence for the 770 tablet.

There have been calls for the opening of the tablet software. The same message from Mr. Gil talks about why that was not done in the first place:

An obvious counterargument would be the One Laptop Per Child project which is successfully developing high-quality hardware and software under tight deadlines in an entirely open manner. That notwithstanding, the 770 project is long finished, so Nokia should be able to release the relevant source now. Unfortunately, such a release appears not to be in the cards:

Note that the "slow" argument applies only to the hardware-specific components. A release of higher-level software is even less likely:

Mr. Gil's postings include a number of statements to the effect that things will be better in the future. He says:

There are hints that more components will be opened in the future as well, but no promises. The end result is that the 770 will, for many users, hit the end of its useful life much sooner than it should have, and that the N800, while hopefully lasting longer, may well encounter similar issues. This state of affairs is unfortunate, it makes a nice piece of hardware less valuable than it really should be.

On a different front, users of the proprietary NVIDIA drivers should be aware, by now, that the company has decided to drop support for a number of its products from the latest driver release. Here's a list of supported (and dropped) adapters for the curious. The older hardware can still be run using the "legacy" driver, but not all features are supported.

This loss of support can be a problem for users; it is also a problem for the few distributors which make these drivers available. Ubuntu, in particular, has been contending with this issue. Including the "legacy" driver adds a support requirement over time. It also adds some interesting twists to the "feisty" upgrade: some systems will have to "upgrade" to the "legacy" driver, while others can go to the current module. One assumes they will work everything out, but it is a hassle that nobody needed. And it could have been avoided by simply making the driver be free software.

Comments (22 posted)

Blaming Fedora

A disgruntled Fedora user recently complained about how the distribution's policies "sometimes suck." It seems that this user had attempted to use an obscure OpenOffice.org feature which is available under some distributions, but which is not available on Fedora systems. This feature, it turns out, is implemented with a piece of closed-source code, which Fedora is unwilling to ship.

Your editor has a gripe as well. For a period of time, his Rawhide desktop contained the Emacs 22 pre-test releases from the FSF. Once Rawhide picked up those releases, however, your editor happily stopped building his own. But the Rawhide version of Emacs lacks the Tetris game found in stock Emacs. The end result is that your editor has to use his editor for actual work instead of pointless block stacking. Rather than start a lengthy flame war, though, your editor simply chose to avoid procrastination and get something useful done.

Fedora, like any complex project, offers plenty of opportunities for criticism; some of those have appeared in these pages in the past. But this sort of feature removal is not one of those opportunities. Anybody who uses the Fedora distribution should understand the constraints the project operates under. They include:

• Fedora is committed to shipping 100% free software. Any software which is not free doesn't belong in this distribution.

• Fedora is tightly tied to Red Hat Inc. and cannot do things which expose Red Hat to lawsuits. So software which could attract patent or trademark litigation must be obtained from somewhere else.

Sometimes it seems like Fedora cannot win. The distribution takes regular grief for its omission of patented codecs, non-free office suite components, binary drivers, etc. But those who appreciate free software rarely credit the project for the extensive work it has done to ensure that everything it ships is free. Fedora users benefit from Red Hat's support: without that support, there would be far less developer time, bandwidth, publicity, etc. available to the project. Dragging Red Hat into unneeded legal hassles would benefit nobody but the lawyers; Fedora users have an interest in avoiding that eventuality.

One might well wonder why certain Fedora users feel the need to repeat these complaints so often. Perhaps the project is not doing an adequate job of communicating what it is trying to do. One assumes that, if people understood what Fedora is, they would not complain about it not being something it can never be.

Comments (22 posted)

Page editor: Jonathan Corbet
Next page: Security>>