| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for August 18, 2005The Open Software License, Version 3.0 In December, 2004, a committee tasked by the European Commission issued a report [PDF] on open source licensing. This report concluded that, while the existing open source licenses achieved a number of important goals, none was 100% suited to the task of licensing software in Europe. The shortcomings they found led the committee to suggest that the EU should adopt either a modified version of the Open Software License or a completely new license drafted with European requirements in mind.Most of the problems found by this committee were related to terminology. Most open source licenses, for example, allow the licensed software to be redistributed. Under the European interpretation, however, "redistribute" has a narrower meaning; in particular, it does not include acts like making the software available for general download on the net. The essential right for this sort of redistribution is "communicate to the public." Without an explicit grant of the right to communicate the licensed code to the public, the possibility remains that some court, somewhere, could conclude that putting a tarball on a web site is a violation of the license. "Virality" is another concern of the authors, who see the GPL is being rather more "viral" than the alternative licenses. In particular, the authors see dynamic linkage as a barrier over which the concept of a "derived work" cannot cross:
The viral effect through mere dynamic linkage (also called "strong
copyleft") is a much more debated question, and currently discussed
on its legal grounds. From our point of view, there is no legal
provision in the EC 91/250 directive on which this viral effect
could be grounded. On the contrary, when a program dynamically
linked with another, no code is reproduced in the program as such:
the only reproduction of code that is made occurs in the RAM of the
computer, where both the programs are "merged".
The Free Software Foundation, instead, does not feel that the type of linking used affects the copyright status of the resulting program. This distinction is important; it could, for example, affect the status of proprietary kernel modules. Because they disagree with the FSF's interpretation, the report's authors shy away from the GPL, even though other "copyleft" licenses contain similar language - and copyleft is what the authors say they want. A few other details caught their attention. Licenses in Europe, for example, are generally not allowed to outlast the corresponding intellectual property protection period. The terms of a copyright license thus cannot be imposed after the covered work has gone out of copyright, should that ever be allowed to happen again. Some details in warranty disclaimers are different, and there are certain types of warranty which cannot be disclaimed. In response to this report, Lawrence Rosen, the author of the Open Software License, has announced a draft version 3.0 of the OSL [PDF] for review. The draft is annotated so that it is easy to see what has changed from the current version (2.1). Most of the changes are fairly obvious given the discussion above: the OSL now explicitly grants the right to "communicate" the software, for example. The license is no longer "perpetual"; instead, the copyright and patent grants are for the copyright and patent protection periods, respectively. There are a couple of new terms which might not be popular with all users of this license, however. The "acceptance" clause now includes the following text:
If You distribute or communicate copies of the Original Work or a
Derivative Work, You must make a reasonable effort under the
circumstances to obtain the express assent of recipients to the
terms of this License.
This language is a response to concerns about whether a license can truly be binding in Europe if the licensee has not explicitly accepted it. The "reasonable effort under the circumstances" might include an active copyright acceptance step required at download time or when the software is installed. It is unclear what might be expected of a distributor shipping OSL-licensed software mixed in with thousands of other packages. The new license also adds:
Unless You obtain a separate license or a waiver of this sentence
from the Licensor, (i) You must display Licensor's copyright and
patent notices on copies of the Original Work and Derivative Works
that You distribute, in the same places and with the same
prominence as You display Your own copyright and patent notices,
and (ii) You must display a statement to the effect that "Your work
is a Derivative Work of Licensor's Original Work licensed under the
Open Software License version 3.0" in copies of Derivative Works
that You distribute, in the same places and with the same
prominence as You display Your own trademarks.
This looks like the return of the unlamented BSD advertising clause. It is less onerous, however, in that it only requires attribution in places where the redistributor is asserting copyright claims. Still, a splash screen for an application built from several OSL-licensed libraries could get unwieldy. Mr. Rosen states:
This change has nothing to do with the other changes I made in
response to the EC proposal for a license that conforms more
closely to their language and needs. It was made because certain
open source companies who contribute free software have told me
they need a way to prevent downstream distributors from simply
making it appear that the new distributors -- and not the original
author -- are the ones responsible for the work.
It is not clear how much of a problem this has been in the real world, and whether it truly needs fixing. The OSL is not a hugely popular license; Freshmeat claims that the OSL applies to 0.15% of the projects listed there. There are some important projects using the OSL, however, including Rails, Globus, ImageMagick, and sparse. This license is well respected and carries a certain influence. Its importance could grow if it comes to be seen as the license to use for those who are especially concerned about adherence to European law. So this proposed update is significant. For those who are interested, the discussion is happening now on the Open Source Initiative's license-discuss mailing list.
GNOME and the way forward It is not often that a straightforward software release announcement generates over 100 comments on LWN, so the recent GTK+ 2.8.0 announcement is special. One might think that the commenters were excited about the new GTK+ features, including Cairo graphics, composite extension support, or that sexy new file browser widget. But no such luck. It would seem that what people really want to talk about is key bindings, which are unchanged in 2.8.0. Certain users see GNOME as moving steadily away from its initial user base, and away from the traditions of Unix as a whole, and they are vocal about their discontent with this state of affairs.Certainly, the GNOME desktop offers enough annoyances to make just about any user grumpy. Your editor is burned daily by the metacity "a new window gets the keyboard focus regardless of the pointer position" policy; having the focus yanked away in the middle of a sentence does not seem like the most user-friendly policy. Why can't gthumb's forms do the right thing when the user hits "enter," rather than forcing another trip back to the mouse? Where, exactly, is the little option to get emacs key bindings? Clicking on a window does not mean the window should be raised; there is a separate combination for that. The new, "electron cloud" busy-cursor behavior in the Rawhide version of GNOME 2.12 is distracting and annoying, requiring a trip to an external site for a new cursor theme. Dia's aggressive use of "tool tips" makes a nice drawing application almost unusable. Why is there no easy way to move settings from one system to another? And so on. Annoyances are part of using a computer, however. It is hard to imagine that a desktop as complex and featureful as GNOME would be free of glitches. These things can be smoothed out over time to make room for new bits of obnoxious behavior. The GNOME debate goes beyond the current set of misfeatures, however, and into a couple of fundamental issues which are worth a look. One of these is: to what extent is GNOME a "Unix" desktop, and to what extent should it preserve the traditional Unix way of doing things, whatever that might be? At the 2000 Ottawa Linux Symposium, Miguel de Icaza delivered his famous "Unix sucks" talk. Unix, he said, had gone stale and had not been the source of any significant innovation for quite some time. The GNOME project intended to move beyond hidebound Unix ways and deliver something new. Miguel's vision, which seemed to involve switching over to hidebound Microsoft ways, does not appear to be driving the GNOME project at this time, but the project does appear willing to break from the past - even its own past - if that offers hope of a better desktop. And that is how it should be. The Unix way of doing things worked well in a different era, when users were clueful, systems were small (in capability, if not in actual size), and an ADM 3 terminal in one's office seemed like a major step up. How do many of the fundamental Unix ideas - writing programs as small, text-oriented filters, for example - fit into the creation of a modern, graphical desktop? Clearly, developers wishing to pull Linux forward into a larger world with a broader user community have to be willing to do some things differently. One may not agree with everything that the GNOME project has done, but the GNOME hackers are (like their counterparts at KDE and elsewhere) trying to change the world for the better. It would be surprising indeed if there were a consensus on what "better" is, especially before it has been implemented and pounded on. The GNOME idea of "better" may or may not win out in the end, but, because the developers are working at it, we will have the opportunity find out. And that is a good thing. The other issue which comes up with some regularity is a perceived arrogance from some in the GNOME camp. Experimentation with the desktop will go best when accompanied by careful attention to the resulting cries of agony from the user community. Users have often been heard to complain, however, that the GNOME hackers Know Too Much to listen to those cries as they follow the One True Course. A tendency by some developers to describe user requests as "crack" probably has not helped in this regard. Recent posters have complained about the refusal by the Evolution maintainers to accept a patch enabling the use of external editors. There is a hard line to follow here; the maintainer of any successful free software project must learn to say "no" to features and requests much of the time, or that project will likely collapse under its own weight. Say "no" too often, however, and both users and developers will leave for a more accommodating environment. The GNOME developers may well be guilty of occasionally erring on the "no" side of that line, however. The project probably hit its low point early in the 2.x series, when configuration options were being jettisoned in a seemingly indiscriminate manner and few apologies were forthcoming. The situation seems to have improved, however, even if work remains to be done; chances are that 2.12 will be the best GNOME release yet. The nice thing about all this is that we are dealing with free software. Using GNOME is not required to get the most out of Linux. The KDE project is out there, and several other desktops as well; it should not be hard to find one to suit the needs of any particular user. One can even still operate a Linux system via an ADM 3 terminal, using the traditional key bindings. The GNOME hackers are doing the right thing in a general sense by pushing toward their vision of a better desktop. If they fail to meet the needs of the user community - or to listen to that community's feedback - there are plenty of alternatives to choose from. Or even the option of forking the project, should that seem like the best course. For the time being, however, this project has made major progress in the creation of a powerful Linux desktop, and the whole thing is free software. There are limits to how much one should complain about that. [As a footnote, it's worth noting that long-time GNOME release manager Jeff Waugh is stepping down; his replacement will likely be Elijah Newren. Congratulations are due to Jeff for heading up several smooth, on-time GNOME releases.]
Page editor: Jonathan Corbet Security Wiretapping and email The legal protection for email has been expanded, just slightly. The full First Circuit Court of Appeals has overturned a First Circuit panel decision that allowed Bradford Councilman to monitor the content of his users' incoming email. Councilman was vice president of Interloc, a company that ran an online service that listed rare and out-of-print books, and offered its customers an email at "interloc.com." (Interloc has become Albris.) In January 1998, Councilman directed employees to copy incoming email from Amazon.com to subscribers. A procmail script was used to copy those messages, without any notice to Interloc's users, into a mailbox that Councilman could read in an attempt to gain a commercial advantage. In 2001, a grand jury charged Councilman with conspiracy to violate the Wiretap Act. This count was dismissed by district court, and the dismissal was affirmed by a panel hearing of the First Circuit Court last year, but the full court granted an en banc hearing which overturned the panel decision. The judgment has been vacated and the case has been remanded to the district court. The case centers on whether email is an "electronic communication," or whether Congress meant to -- by exclusion -- exempt "communications in transient storage" from the Wiretap Act. The Electronic Communications Privacy Act (ECPA) of 1986 updated title 18 of the United States Code (the Wiretap Act), making it an offense to "intentionally intercept, endeavor to intercept, or procure any other person to intercept or endeavor to intercept, any wire, oral, or electronic communication." If email is considered an electronic communication, then it is considered protected under the ECPA. However, Councilman argued that email was not "electronic communication" when it was copied because it was "in storage" at the time. The court has decided that Councilman's interpretation "is inconsistent with Congress's intent."
The statute contains no explicit indication that Congress intended to
exclude communications in transient storage from the definition of
"electronic communication," and, hence, from the scope of the Wiretap
Act. Councilman, without acknowledging it, looks beyond the face of the
statute and makes an inferential leap. He infers that Congress
intended to exclude communications in transient storage from the definition
of "electronic communication," regardless of whether they are in the
process of being delivered, simply because it did not include the term
"electronic storage" in that definition. This inferential leap is not a
plain text reading of the statute.
It's also worthwhile to note the court's comments on the Stored Communications Act, saying that "Councilman's conduct may appear to fall under the Stored Communications Act's main criminal provision," but that he would also fall under the provider exception, which says the Act "does not apply with respect to conduct authorized by the person or entity providing a wire or electronic communications service." The Stored Communications Act, according to the Court's decision, appears to establish "virtually complete immunity" for service providers in handling email on their systems. However, the Stored Communications Act does not provide a "safe harbor" for Councilman, since the Wiretap Act has a much narrower service provider exception, which only allows interception as "necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service." Obviously, Councilman's actions do not fall within this definition. The court concluded that "electronic communication" includes "transient electronic storage that is intrinsic to the communication process for such communications" and that "interception of an email message in such storage is an offense under the Wiretap Act." Assuming this decision holds, the Councilman decision is a victory for users and protects email in transit -- whether that is "on the wire" or in temporary storage on a server awaiting delivery to its final destination -- granting email the same protection from interception and monitoring that is given to phone calls.
Security news An overview of multilevel security One of the many features added to the 2.6.12 kernel is multilevel security support for SELinux. The only problem is that few people actually understand what MLS is. James Morris has posted a multilevel security overview which makes a good starting point. "The reason why we have categories as well as sensitivities is so that sensitivities can be further compartmented on a need to know basis. For example, while a user may be cleared to Secret, they may not need to know anything about project WarpDrive (which could be the name of a category)."
The Hidden Boot Code of the Xbox The Xbox Linux Project site has posted a detailed article on how the Xbox was designed to prevent the booting of "unauthorized" software, and how that scheme was defeated. It is an interesting look at the design of non-free hardware. (By way of Bruce Schneier).
New vulnerabilities Adobe Acrobat Reader: arbitrary code execution
awstats: command injection vulnerability
bluez: command execution
evolution: format string issues
kdeedu: tempfile handling vulnerabilities
Mozilla: frame injection spoofing
Updated vulnerabilities a2ps: input validation error
affix: two remote vulnerabilities
amd64: multiple vulnerabilities
httpd: off-by-one overflow and cross-site scripting
bzip2: race condition and infinite loop
ClamAntiVirus: integer overflows
cpio: directory traversal
CUPS: multiple vulnerabilities
cyrus-imapd: buffer overflows
dbus: information disclosure
dhcpcd: denial of service
emacs21: format string vulnerability in "movemail"
enscript: arbitrary code execution
epiphany: Mozilla regression vulnerability
ethereal: dissector vulnerabilities
evolution: message crash vulnerability
fetchmail: buffer overflow
Foomatic: Arbitrary command execution in foomatic-rip
gaim: buffer overflow
gdb: multiple vulnerabilities
gtk-pixbuf, gtk2: denial of service
gettext: Insecure temporary file handling
ghostscript: symlink vulnerabilities
glibc: tempfile vulnerability in catchsegv script
gnupg: information leak
grip: buffer overflow
groff: insecure temporary directory
gzip: arbitrary command execution
heartbeat: insecure temporary files
htdig: cross site scripting
imap: buffer overflow in c-client
imlib2: buffer overflows
junkbuster: heap corruption and settings modification
kdelibs: kate backup file permission leak
kernel: ELF loader core dump vulnerability
kernel: multiple vulnerabilities
kernel: multiple vulnerabilities
krb5: double-free flaw
libconvert-uulib-perl: arbitrary code execution
libdbi-perl: insecure temporary file
libgadu: memory alignment bug
libgd2: buffer overflows in PNG handling
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||