LWN.net Weekly Edition for May 8, 2003

Free licenses and warranties

Releasing a work - be it code, words, sounds, or images - under a free license is not just a matter of tossing in a file called COPYING and putting up a tarball. It is a legal decision which may have long-term implications. For an example, consider this discussion on the warranty provisions of the Creative Commons licenses.

The Creative Commons offers several licenses to fit different people's wishes regarding attribution, commercial use, and derived works. They range from being very GPLish, to something that looks vaguely like the BSD license (though rather more complicated), to others that would not be considered "free" by most in the community. One thing they have in common, however, is a fairly strong warranty provision:

In other words, when you release a work under a Creative Commons license, you are making a promise to any potential user that nobody else has any rights to that work that could require payments from that user. This is a warranty: should a third party come to one of your users for royalties or damages, they can come back to you. Releasing a work under one of these licenses means taking on a legal liability.

This feature of the Creative Commons licenses is deliberate: it is intended to give users of CC-licensed works confidence that they can truly use and redistribute those works without getting into trouble. This sort of language is not uncommon; anybody who has had a book published, for example, has signed off on a warranty that is at least as strong as the CC licenses require. But some authors who release under a CC license may not understand the commitment that they are making. The Creative Commons folks will apparently be making some changes to make the warranty commitment more clear.

What about other licenses? The GNU General Public License is clear that the covered works come (in capital letters) "WITHOUT WARRANTY OF ANY KIND." Other common licenses, including the Apache Public License, the Artistic License, the BSD License, the Mozilla Public License, and others all include warranty disclaimers. The Open Software License, instead, reads:

In other words, authors using the OSL are taking on a warranty obligation. The GNU Free Documentation License, interestingly, states only that any warranty disclaimers must be preserved. Authors releasing under that license should probably add an explicit statement of their warranty position.

Of course, no warranty disclaimers will keep you out of trouble if a litigious third party decides that you are distributing their intellectual property. For example, should SCO manage to prove in court that the famous "printer on fire" kernel message was stolen by IBM and placed in the Linux kernel, the fact that the relevant code was released under the GPL (if it was) will prevent other Linux distributors from suing IBM, but will it not help against SCO.

Regardless of disclaimers, anybody distributing material under a free license had better be sure that they have the right to do so. Once that is done, however, it is worth being aware of just what sort of warranty you are promising people who are making free use of your work.

Comments (6 posted)

Silly Corporate Obnoxiousness

The latest bit of amusement in the SCO suit comes from this talk with SCO CEO Darl McBride on News.com. Mr. McBride is now making direct claims that Unix source code has been copied into the Linux kernel. But don't hold your breath while waiting to see where this copying has happened:

Mr. McBride's contempt for the Linux developer community is, it would seem, exceeded only by his contempt for the public as a whole. It takes little thought to realize that his claims makes no sense whatsoever.

The Linux community, of course, would be incapable of "laundering" the code, since it is, according to SCO, incapable of implementing (or reimplementing) anything so advanced without stealing it. Of course, perhaps this band of thieves could rip off replacement code from somewhere else. Suppose, for the sake of argument, that the code in question is "laundered" with a replacement stolen from, say, CP/M. The resulting kernel would be bizarre, but it would no longer infringe upon SCO's copyrights.

Such a series of events would not change SCO's case in any way, however. If IBM truly misappropriated SCO's code, that act remains. And it is an act that cannot be hidden; the evidence is distributed, beyond recall, all over the Internet. And all over the physical world as well. So even if the Kernel Janitors do an especially effective cleanup job, SCO could certainly manage to send one of its brand-name lawyers down to a local computer store to pick up a boxed set of the distribution of their choice. "Exhibit A" should not be that hard to find.

Indeed, the company could simply submit one of its own products to the court. SCO is, with full knowledge now, distributing the disputed source licensed under the GPL. There are two possible conclusions that can be reached from this action:

• SCO has agreed that the code which - it claims - was taken from Unix can now be distributed under the GPL. This would not necessarily make the case moot - SCO might not have agreed to the initial disclosure - but it certainly removes the need to "launder" anything.

• SCO is knowingly distributing a derived product from a GPL-licensed program (the kernel) which is not, itself, licensed under the GPL. If SCO is claiming proprietary rights on the kernel that it is shipping, then SCO is in violation of the GPL, and loses the right to distribute the kernel at all.

Either way, the implications are interesting. If it looks like SCO is in violation of the GPL, the development community is unlikely to adopt a forgiving attitude. The first big Linux lawsuit could end up giving birth to the first big GPL case.

[As a postscript: SCO's veiled hints that the free software community is behind the denial of service attack on its web site border on libel. As Eric Raymond has pointed out, Linux hackers have better things to do. Criminal attacks do not help us in any way, and are not the free software way of doing things.]

Comments (none posted)

A Look At WineX

[This article was contributed by Joe 'Zonker' Brockmeier]

Gaming is still an area where Windows is, so to speak, way ahead of the game. Since Loki Entertainment Software went under, Linux gamers have had little hope of seeing a wide selection of popular games for Linux. However, the folks at TransGaming are trying to bridge the gap with WineX. TransGaming recently released version 3.0 of WineX, a product that's designed to allow Linux users to run Windows games on Linux. I took it for a spin recently to see just how well the product worked, and whether WineX is the answer to gaming on Linux. The answer, as it turns out, is "maybe."

WineX is not compatible with all Windows games on the market. In fact, TransGaming supports only a small subset of Widnows games. You can find a full list of supported games on TransGaming's site along with ratings for games that have been tested by TransGaming or submitted by their users.

I tested WineX 3.0 on a machine with an Athlon XP 2000+ CPU, one gigabyte of RAM and an ATI Radeon 9000 with 64 MB of RAM running Mandrake Linux 9.1. It's not as brawny as many gaming machines, but it's no slouch in the speed department either. I've been running native Linux versions of Quake III Arena and Unreal Tournament on it for some time, and I'm happy with the performance of those games.

Setting up WineX 3.0 is pretty easy, I just grabbed the WineX RPM and installed it. I also installed their Point2Play GUI, but I didn't have very good luck with it. At first, it couldn't even find my CD-ROM or DVD drives -- apparently the format of Mandrake's /etc/fstab threw it for a loop. Even after I fixed that, the options for installing a game using Point2Play remained greyed out. That's not really a big deal, installing a game with WineX is easy enough from the command line. All you need to do is mount the CD-ROM and run "winex3 setup.exe" (replacing "setup.exe" with the appropriate name for the setup program) and run through the normal installation procedure you'd go through in Windows.

I tested several games, some on TransGaming's list and some not, and only had real success with two games. To be fair, the games that didn't function were either not on the list or marked as working poorly. Half-Life installed, but threw an error after startup and then hung on a black screen with an hourglass cursor. I suspect that if I spend some time tweaking config file, I could probably get it to work. The installation program for Dungeon Master died midway through the install, as did the installer for MDK 2.

Then I tried installing the Windows version of Return to Castle Wolfenstein. This installed flawlessly. Then I began the grueling work of actually testing the game. After several hours of gameplay I didn't notice any glitches or problems with Wolfenstein. I had success switching the resolution, tweaking the brightness, saving and loading games -- in short, it seemed to work perfectly. I then installed Heretic II. I had to tweak the WineX configuration file so that Heretic would realize that the CD-ROM was in the drive, but it also ran perfectly after I made the switch.

WineX 3.0 kind of reminds me of the days when I used to buy a DOS game and cross my fingers hoping that it would run on my computer. Some games would install and run easily, others would take a little wrestling to get them to run, and others never ran due to conflicts with this or that piece of hardware or for some other almost unknowable reason. The difference here is that TransGaming is continuously working on WineX, so it's possible that a game that doesn't run today will run sometime down the road.

While WineX may not be compatible with a fair number of games, the performance of the games that are compatible is very satisfying. If you're thinking that you want to run a Windows game under Linux, my advice would be to check TransGaming's list of compatible games first. If your game is on the list with a working rating of 4 or 5, you can feel pretty confident that you'll be able to play your game on Linux with WineX and be happy with the performance and stability of that game. Otherwise, proceed with caution.

Even though WineX doesn't run everything under the sun, I still think it's worth the price. TransGaming doesn't sell WineX as a boxed product, you have to subscribe to WineX to get the prepackaged files. They offer RPMs and Debian packages of current releases only to subscribers, but you can access their CVS and try to build it yourself from source. I didn't try this, but would be curious to hear what kind of success others have had. The pricing for the subscription is pretty reasonable, just $5 a month with a 3-month minimum. Even if you cancel the subscription after the initial three months, you still have the releases that you download during your subscription. It's not a perfect solution, but WineX does show a lot of promise.

Comments (6 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Hardening the kernel against buffer overflows; new vulnerabilities in eipc, fuzz, mod_auth_any, OpenSSH.
• Kernel: <tt>sched_yield()</tt>; module reference counting; driver porting: the device model
• Distributions: Knoppix - the Great Linux Advocate
• Development: The New Generation of Foomatic, Ardour developments, new versions of Alsa, JACK, Moodss, Silva, GNOME System Tools, Sound Juicer, Epiphany, Lynx, PythonCAD, Evolution, LyX, StarDict, ECL, and Mono.
• Press: Linux compared to Windows Server 2003, SCO in the news, Open Source in US state governments, dealing with false open source representatives.
• Announcements: OpenOffice celebrates first year, Red Hat elects general to board, AFFSAC, Birmingham, Netfilter Developer Workshop, Open Source in Government Conference in Paris, 2003 Perl Conferences.
• Letters: Win2003 v. Linux

Next page: Security>>