Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
|
| |||||||||||||
LWN.net Weekly Edition for November 16, 2006Resisting the binary blobLast week, LWN pointed at a software review claiming that Fedora Core 6 was so bad that the whole distribution should simply be shut down. The failing which led to such a dire prescription was a lack of proprietary software. According to the reviewer:
I appreciate the fact that distributions like Fedora Core are still
focused on free-as-in-rights software, but today's Web content
requires more proprietary browser plugins than yesterday's did, and
today's hardware is increasingly designed to be dependent on
proprietary binary blobs in the form of firmware and driver
packages... Users do not want to hear reasons and excuses for why
the operating environment doesn't work with their favorite Web
sites or computer hardware -- all they know is that it doesn't
work, and making it work is not a simple or obvious process.
This reviewer is not the only one to express this point of view; there would appear to be a rising chorus out there calling on Linux distributors to load up their systems with proprietary code. Some distributors have heeded this call, as witnessed by (for example) Ubuntu's decision to include more binary drivers by default in its next release. It's not too hard to see where this pressure is coming from. A prospective user with a problematic laptop will be happier with a distribution which "just works." Most of the people who truly care about free software are likely to be using a free system already, so it is easy to imagine that the next wave of users will be less concerned - at the outset - about software freedom. So they will gravitate toward a system which does what they want to do (running on closed hardware, playing patent-encumbered media, etc.) without concerning themselves much about the provenance of the software they are using. The fact that many of these users worry little about software freedom now does not mean that they will never care, however. Very few of us were born knowing that free software is a better solution, that using free software is an important part of being free in general. Just like most of us have learned, over time, that saving some of the money we earn, while perhaps being inconvenient in the short term, brings long-term benefits, we have also learned that using free software - and helping to improve that software - is better in the long term. Certainly some subset of the new users coming to Linux will come to understand this fact as well. But it will not matter how well these users understand the fine points of software freedom if, by the time they have figured it out, there are no free operating systems for them to run. If we want free systems then, we have to build and use free systems now. There can be a place for a binary blob which enables a specific bit of hardware to work; your editor would argue that running such a blob is not an inherently immoral act. But it is not necessarily a wise act, and a distribution which quietly installs such blobs on an unsuspecting user's system in the name of "it just works" is not necessarily doing that user any favors. As a thought experiment, consider how things might have gone if the Linux community had accepted the "just works (most of the time)" non-free Java implementation that Sun made available. Linux distributors, rather than put large amounts of work into making Java code work with free alternatives, could have simply shipped Sun's version. Had they done so, would we have (the promise of) a GPL-licensed Java from Sun now? If we simply accept proprietary drivers in the name of "it just works," when, exactly, do we think free drivers will become available? So criticism of Fedora - or any other distributor which sticks to free software principles - is, at best, misplaced. There are proprietary systems out there for people who want to run them, but Linux is about free software. It makes no sense to try to push proprietary code onto a distribution which has set a goal of being 100% free, and it is silly to criticize such a distribution for containing only free software. We should, instead, be appreciative of the vast amount of work that has gone into giving us a 100% free system - and help to improve that system. Along these lines, it becomes natural to wonder why the Free Software Foundation has not recognized the work done by the Fedora Project to make its distribution entirely free. Instead, the FSF has put its energy into promoting obscure distributions like gNewSense and UTUTO. It seems that the Fedora developers and the FSF have been talking about recognition for Fedora, resulting in the posting of this message from Richard Stallman. It covers a number of issues, including firmware, fonts, patents, and more. One sticking point, it would seem, is this:
We can certainly go through the [Fedora packaging] guidelines. We
have not yet done so, but we know of one problem in the current
policy: it says that packages can be included which qualify as open
source but not as free software. In other words, not all packages
need to meet the definition of free software.
Given the people involved with Fedora, and the work that has been done to eliminate packages with problematic licensing, your editor has no qualms in saying that Fedora is a truly free distribution. It is unfortunate that the work which has gone into the creation of this distribution is not as widely recognized as it should be. If we want to promote free software, and if we want to live in a world where we can use exclusively free software, we should not hesitate to acknowledge the work of those who have built free systems, and who have not given in to those pushing for the addition of proprietary code. They are doing the work we so very much want to see done, and we are far richer for it.
Some notes on free JavaThe free software community would appear to have developed a winning strategy for bringing semi-proprietary code under a free license. Just create a project to reimplement that code, and name the project "Harmony." About the time that the Harmony project starts to make some real progress, the original code base will be relicensed to the GPL, and everybody will be happy.This approach worked well with the first Harmony project, which was created to make a free version of the then-proprietary Qt library. In September, 2000, Trolltech finally made Qt available under the GPL. More recently, a Project Harmony set out to create a free Java implementation. A year and a half later, Sun Microsystems finally let go, and has promised to release Java as free software - and under the GPL at that. Clearly some serious thought needs to be put into picking an appropriate target for the next Harmony project. Actually, the "Harmony" name may not become available for a while yet; a quick look at the mailing list shows that, unlike the previous Harmony project, the current Harmony developers are continuing full-speed with their work. One might well wonder why, given that the "real" Java code is now promised to the community. It may be partly a matter of momentum, and partly waiting until the code actually becomes available (it will be a few months yet). Sun's interesting choice of the GPL also appears to be relevant. The Harmony project, being under the Apache umbrella, is using the Apache license, which is not compatible with the GPL. So the Harmony developers will not be able to make use of Sun's code in their project. If they want an Apache-licensed Java, they will have to continue to work to create it themselves. There appears to be some concern within Harmony that Sun will require copyright assignments from those who would contribute to the GPL code base, and that, in turn, would allow Sun to make use of contributed code in proprietary projects. There are Harmony developers who are unwilling to contribute under those conditions. It has also been suggested in the Harmony camp that Sun might use patents to enforce Java compatibility. So Harmony may well continue for a while. Another project which will be affected by this release is GNU Classpath. Unlike Harmony, however, Classpath uses a "GPL plus exception" license which allows the use of the library in proprietary applications. Sun's choice of the GPL makes life easy for the Classpath developers - especially since Sun adopted the same exception. But it does leave open the question of whether Classpath is needed at all. The real answer there probably depends on the shape of the actual code release; there may be parts of the "real" Java class library which Sun is unable to release, and which might then be substituted from Classpath. It also seems that Classpath has managed to build a dynamic and effective development community; the desire to continue to develop in that environment may keep Classpath going for a while yet. Many pixels have been expended in attempts to analyze Sun's choice of the GPL. Most likely, Sun went with the GPL because (1) the response to the CDDL has been lukewarm at best, and (2) experience shows that GPL-licensed code is relatively resistant to the creation of incompatible forks. Sun's ostensible reason for resisting free licensing all these years was a fear of incompatible versions, so fork resistance should have been on their minds. Also worthy of note is the fact that Sun has specified that it is using version 2 of the GPL. A switch to GPLv3 seems likely once the license is final (see Jonathan Schwartz's weblog), but Sun is not committing to that ahead of time. Sun has made some hints that Solaris might move over to the GPL as well. This would be a significant change, as it would allow Solaris code to find its way into the Linux kernel. There must be useful code within Solaris, even if some of the more interesting parts (the ZFS filesystem, say) would be a major challenge to port. In any case, Sun's freeing of Java is a significant - if a bit overdue - gift to the community. It will enable the Java language to become a first-class citizen within Linux distributions and make a powerful language fully available to free software developers. Sun certainly cannot be faulted for failing to contribute in recent years. Soon, it will be up to the community to take this code and do great things with it.
Open Firmware is now freeA full twenty years ago, Mitch Bradley sat down to write the firmware (BIOS) code for Sun's upcoming SPARCstation line. The resulting code, then called OpenBoot, shipped on SPARC systems for years, and found its way into other vendors' computers as well. Mr. Bradley eventually left Sun to continue to work with this code, now called Open Firmware. It has proved to be useful for system manufacturers who found it to be a quick way to get their hardware going. Twenty years later, he is still at it at his company, FirmWorks.As of this week, however, one aspect of Mr. Bradley's job has changed: he is now working with free software. Between code releases by Sun Microsystems and FirmWorks, the entire Open Firmware system is now free. Most of it is available under the BSD or MIT license; it can be browsed on the net or obtained from the Subversion repository at svn://openbios.org/openfirmware. Open Firmware is an interesting system. At its core, it is an interpreter for the Forth language; most of the higher-level functionality is implemented in Forth and run on the interpreter. That will make the Open Firmware source relatively opaque for those of us who are not accustomed to working in stack-based languages; Open Firmware will certainly have the only ext2 filesystem code which looks like this:
: ext2fsfread ( addr count 'fh -- #read )
drop
dup bsize > abort" Bad size for ext2fsfread"
file-size lblk# bsize * - ( addr count rem )
umin swap ( actual addr )
lblk# read-file-block ( actual )
dup 0> if lblk#++ then ( actual )
The use of Forth does help to keep the Open Firmware code compact and quick, however. This system can work with several different filesystems, perform TCP/IP networking (including functioning as an HTTP server or client), work with USB devices, and drive a wide range of devices in general. And it all fits in about 350KB of flash, with the ability to shoehorn it into 256KB if need be. Open Firmware can also be useful for debugging hardware issues. The Forth interpreter is available at the system console, allowing a sufficiently clued developer to poke at device registers directly and see what happens. This feature is especially useful when trying to bring up new hardware which is displaying unexpected behavior. As Mr. Bradley has been heard to say:
I find that a certain amount of foot shooting is necessary,
especially when dealing with new, possibly-broken hardware with
dubious documentation. Interactivity at the lowest level lets you
get all the foot-shooting done quickly, and more importantly, lets
you examine the wounds in great detail.
Open Firmware is a foot-shooting tool of substantial power. The Open Firmware code was widely used, even when it was a proprietary product. This code will be even more widely distributed soon. Back in October, the One Laptop Per Child project announced that it would be adopting Open Firmware for its systems. LinuxBIOS will remain on those systems as the low-level BIOS, but Open Firmware will be the code which performs boot loading and presents the firmware-level interface to the user. The OLPC decision was based on smaller size, greater speed, and greater flexibility of the Open Firmware code. Once Open Firmware set on the path toward a free release, OLPC's decision was relatively easy. In the future, the now-free nature of Open Firmware may cause it to appear on a number of new systems, in places where a proprietary BIOS would have been found before. As a result, a part of our systems which has traditionally been proprietary and closed might just become open and free. So, while many of us may never work with this code directly, we'll likely benefit from its freedom anyway.
LWN comes out early next weekThursday, November 23, is the Thanksgiving holiday in the U.S. As has become traditional, LWN will be published one day early next week so that we all have time to join our families and begin the task of serious eating. We'll return to the normal schedule the following week.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|
||||||||||||