Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for January 19, 2006GPLv3: a first look The Free Software Foundation has, at last, made a draft version of version 3 of the General Public License available for comments. Your editor, having read it five minutes ago, is now ready to comment. What follows is a quick overview of the changes which have been made to the GPL; anybody wanting more information should certainly read the accompanying rationale document, which describes the changes - and their motivations - in detail.The GPL is an important license. It is the most popular of free software licenses, and it covers many important components of a Linux system. It is a codification of the FSF's view of how free software should work, and it imposes some real obligations on those who redistribute GPL-licensed software. It is a core piece of our legal source code. So a major revision of the GPL requires a great deal of thought. In your editor's opinion, the FSF has put in that thought, and has put forward a revised license which meets current challenges while remaining true to the spirit of previous versions.
Digital restrictions managementMany of the changes in GPLv3 have to do with DRM schemes. The license makes the FSF's position on DRM quite clear, and does its best to ensure that GPL-licensed code will stay as far away from DRM as possible. To start, the license makes its intent with regard to DRM clear:
As a free software license, this License intrinsically disfavors
technical attempts to restrict users' freedom to copy, modify, and
share copyrighted works. Each of its provisions shall be
interpreted in light of this specific declaration of the licensor's
intent. Regardless of any other provision of this License, no
permission is given to distribute covered works that illegally
invade users' privacy, nor for modes of distribution that deny
users that run covered works the full exercise of the legal rights
granted by this License.
The purpose here is to help ensure that, in any future court case, all of the terms of the GPL will be interpreted with an anti-DRM bias. An interesting clause can be found in section 3:
No covered work constitutes part of an effective technological
protection measure: that is to say, distribution of a covered work
as part of a system to generate or access certain data constitutes
general permission at least for development, distribution and use,
under this License, of other software capable of accessing the same
data.
This provision is clearly targeted at anti-circumvention laws. If it stands up, it says users can bypass any restrictions encoded in GPL-licensed software without circumventing "technological protection measures," since no GPL-licensed program can be part of such a measure. Another key provision can be found in the revised definition of "source code":
Complete Corresponding Source Code also includes any encryption or
authorization codes necessary to install and/or execute the source
code of the work, perhaps modified by you, in the recommended or
principal context of use, such that its functioning in all
circumstances is identical to that of the work, except as altered
by your modifications. It also includes any decryption codes
necessary to access or unseal the work's output.
In other words, "trusted computing" mechanisms designed to keep people from replacing the software on their gadgets cannot be used with GPLv3-licensed software. This is a large and important change - though its effect will be somewhat limited for as long as the Linux kernel remains licensed under version 2 of the GPL.
Software patentsAs expected, the new version of the GPL addresses software patents in a much more comprehensive manner. One fundamental change is that anybody who redistributes software covered by the GPLv3 is explicitly granting all patent licenses needed to use the software. This grant covers "all versions of the covered work," and would seem to override the "field of use" restrictions imposed by some patent owners. Here's an interesting addition in v3:
This License gives unlimited permission to privately modify and run
the Program, provided you do not bring suit for patent infringement
against anyone for making, using or distributing their own works
based on the Program.
It is, of course, a patent retaliation clause. If you launch a patent suit against somebody using a specific program, you cannot make any further use of that program. It's a big departure from GPLv2; the previous version of the license imposed no restrictions on individual use of the software at all. With GPLv3, the right to use the software - not just to redistribute it - can go away as a result of filing a patent suit. There are no other patent retaliation clauses in the GPL itself; the FSF is not entirely comfortable with this concept in general. From the rationale document:
Several other free software licenses include significantly broader
patent retaliation provisions. In our view, too little is known
about the consequences of these forms of patent retaliation.
There is, however, a subsection which allows the incorporation of additional, limited patent retaliation terms. Terms which take away use of the software for filing a wider range software patent lawsuits can be added:
They may impose software patent retaliation, which means permission
for use of your added parts terminates or may be terminated, wholly
or partially, under stated conditions, for users closely related to
any party that has filed a software patent lawsuit (i.e., a lawsuit
alleging that some software infringes a patent). The conditions
must limit retaliation to a subset of these two cases: 1. Lawsuits
that lack the justification of retaliating against other software
patent lawsuits that lack such justification. 2. Lawsuits that
target part of this work, or other code that was elsewhere released
together with the parts you added, the whole being under the terms
used here for those parts.
So the GPLv3 does not include full-scale patent retaliation, but there should be enough there to get the attention of some types of patent holders.
Additional termsA few other types of additional restrictions are allowed in GPLv3. These include limits on trademark use or the use of contributors' names for publicity purposes. The idea here was to try to make the GPL compatible with a wider range of free software licenses. The much-discussed "web services loophole" is also addressed by way of an optional restriction:
They may require that the work contain functioning facilities that
allow users to immediately obtain copies of its Complete
Corresponding Source Code.
Beyond that, version 3, like its predecessors, explicitly disallows the imposition of additional restrictions.
Other changesUnder version 2, termination of the license was automatic if its terms were violated. In theory, one who had gone against the GPL would have to go and explicitly beg forgiveness before being able to distribute the relevant software again. Back in 2000, Richard Stallman told the KDE developers that they had to ask forgiveness in this way. Version 3 changes the terms to put the onus on copyright holders to terminate a license. Any copyright holder can do so if the terms are violated, but a violator who mends his ways need not ask forgiveness from any copyright holder who has not exercised that right. Version 2 contains a clause saying that, if a program cannot be distributed in a way which complies with both the GPL and any other restrictions (patent licenses in particular), it cannot be distributed at all. There has been some disagreement over just how strong that restriction is. GPLv3 makes it clear that a strong interpretation is expected; this section is now titled "Liberty or Death for the Program." The geographical restrictions clause, which allows terms disallowing the distribution of code in certain countries due to legal problems there, has been retained in GPLv3. The rationale document states, however, that the FSF knows of no actual use of that clause, and they suggest it could be removed during the comment period. There are many other changes, mostly aimed at clarifying intent and ensuring that the license is enforceable worldwide. Again, interested parties are urged to read the license itself and the rationale document for the full story. They will then be prepared to take part in the comment and revision process, which is expected to last for about one year. If all goes well, the FSF hopes to adopt GPLv3 in January, 2007.
The .NET API patent, mono, and GNOME The Mono project pushes a lot of buttons in the free software community. Patents, Microsoft, language choice, and platform choice all generate lots of heat individually, and Mono has them all. In spite of all the debate, there are still some issues that remain unresolved. There are undoubtedly some people who have been avoiding Mono just because Red Hat was; now that Fedora has it (while RHEL is still apparently up in the air) it's tough to know if Mono is safe to use or not. I'm not a lawyer, but since everyone who has gotten advice from one (or who is one) is being tight-lipped about it, the rest of us apparently have to figure things out the best we can. I asked Red Hat Deputy General Counsel Mark Webbink about the decision to include Mono, and he replied:
I think you can understand that I cannot discuss Red Hat's internal IP
policy. I would point out that the decision to include Mono with Fedora
was made by the Fedora Foundation and its project folks. I feel confident
the determination was made with an understanding of various patent concerns
that have previously been posed to Novell but also with an understanding
that there are protections available to open source developers, vendors,
etc.
"...protections available to open source developers, vendors, etc."--sounds like the patent pools that are intended to create a mutually-assured-destruction sort of scenario for anyone wanting to sue open source projects for patent infringement. These pools have been derided as PR gimmicks, but Webbink's note makes it sound like some people are willing to actually put some trust in them. This message also makes it sound like the Fedora decision-making mechanisms are finally starting to become separate from Red Hat's. I sent a message to Greg DeKoenigsberg of the Fedora Foundation, and I got the one-sentence official line in return:
"Business considerations that prevented certain Mono components from
being
included in Fedora previously have now been resolved."
Greg also suggested that more information may be forthcoming soon. One of the really interesting aspects of the timing is the fact that the main patent application that has been discussed in the media (the API patent application) appears close to being automatically abandoned. The API patent, if it were granted, would be a big blow to the Mono project. Many patents on various aspects of the implementation could have been worked around, but the API implementation not only makes up a significant portion of the Mono codebase (making it a big project to re-do), but is also what all software written for Mono/.NET uses. If the API becomes unusable, you can't hide a work-around in the Mono internals, because the API forms the connection between Mono and the rest of the world. In October of last year, the patent office issued a "Non-Final Rejection" to the patent application, meaning that Microsoft can try to fix the application. Indeed, if you read the non-final rejection, there are several suggestions the patent examiner makes about how to fix problematic issues. However, there is also a big section of the rejection notice that talks about prior art in the form of two already-issued patents. Those could be harder to work around. The rejection notice says that the deadline for reply is three months from the date of mailing, which was October 21st, 2005. It has now been almost three months, and Microsoft has not yet replied. According to the rejection notice, if there's no reply before the deadline, the application is automatically abandoned. What does that mean? Well, ask a lawyer, I guess, but it sounds pretty good for Mono. More importantly, maybe, is what it means for GNOME. In the spring of 2004, there was a big discussion on whether to begin using Mono in the GNOME core desktop. For example, see Havoc Pennington's essay on the topic. Clearly, it would be good to start writing core functionality in something nicer than C; however, the GNOME developers are understandably reluctant to open things up too widely and end up with a large number of different languages in the core desktop. The debate didn't reach a conclusion, with Novell going one way, Red Hat going another, and the community left hanging, with little information with which to make a decision. Since then, several useful GNOME-targeted applications have been written using Mono. With the confusion regarding whether or not Mono would end up in all the major distributions, though, those applications have undoubtedly not gotten as much support and contributors as they could have. There are also non-Mono alternatives to some of them. While competition between projects is certainly healthy and a good thing in general, one of the strengths of free software is the ability to share and cross-pollinate. If different projects use different languages, libraries, and platforms, though, that sharing becomes much more difficult. Hopefully, some clarity on Mono's risks is forthcoming, and then maybe the split can be resolved. [The author wishes to disclose that he holds stock in Red Hat, Inc.]
The return of software patents in Europe? Last July, when the European Parliament killed the software patent directive, few people thought that it would remain dead forever. The sorts of people who push for that sort of expansion of legal monopoly rights tend to be tenacious; they do not give up easily. Still, the recent headlines proclaiming the return of the software patent debate were a bit of a surprise; one would have thought that the pro-patent camp would lie low for a little bit longer.In fact, what is on the agenda now is not really a return of the software patent directive. It is, instead, the longstanding idea of a "community patent," which would apply across the entire EU. The idea is not entirely nonsensical; patenting an idea across the EU is currently a lengthy and expensive affair. People and companies interested in obtaining patents would really rather go through the process just once; the community patent would make that possible. The text of the proposal [PDF] is available for those who are interested. An attentive reader will note that there is no mention of software patents in the proposal. Where the trouble comes in is with this clause here:
The European Patent Office will play a central role in the
administration of Community Patents and will alone be responsible
for examination of applications and the grant of Community Patents.
So, if somebody were to convince the EPO to start granting patents on algorithms, community software patents would be a reality. The unfortunate news here is that the EPO has been happily granting software patents for some time. FFII has put together a list of some of the worst EPO software patents; included therein are patents on JPEG, MP3, tabbed dialog boxes, form processing in web servers, some remote procedure call protocols, electronic shopping carts, and more. Such patents have no Europe-wide significance now, but, if they were issued as community patents, the situation would then be different. At that point, the only hope would be a court battle with the objective of getting software patents declared invalid. Not a fun process. Besides, it was in the courts that software patents became enforceable in the U.S. Before this situation could come about, however, the community patent proposal would have to be adopted. That has not happened, so far, despite years of trying. Still, if there is to be a renewed push to establish a community patent, it would be much better for that patent to come with clear rules about the patentability of software. The current consultation period goes through the end of March; there will be a European Commission hearing on the community patent on June 13, 2006. So there is not a lot of time to push for changes.
Page editor: Jonathan Corbet Security Firefox and the ping attribute The ping attribute is an HTML extension proposed by the Web Hypertext Application Technology Working Group. This attribute may be applied to anchor ("<A>") tags; its value is a list of URIs. If the user clicks upon the link created by the <A> tag, the browser will, in addition to displaying the destination page, also send a request for each of the given URIs. Essentially, the browser is phoning home - possibly to multiple homes - to report on the user's action.As it turns out, future Firefox releases will implement the ping attribute; by some accounts, this feature will turn Firefox into spyware. Calling it "spyware" is probably overstating the case a little, but this feature is still worth some thought. Many sites perform tracking of outbound clicks now. The normal technique is to reformat an external link to point at an internal script; that script logs the click, then returns an HTTP "redirect" response which sends the browser to the true destination. The redirect technique is arguably worse than the ping attribute for a couple of reasons. The first is the fact that redirect-style URLs obscure the true destination. Redirected URLs can be moderately obfuscated, such as this one taken from a News.com story:
http://dw.com.com/redir?destUrl=http%3A%2F%2Fwww.nationalskillsregistry.in&siteId=3&\
oId=2100-1029-6028107&ontId=1009&lop=nl.ex
They can also be completely obscure:
http://linuxfr.org/redirect/45255.html (The above URL takes the reader to the Fedora directory server page). Redirected URLs can, in the presence of JavaScript, be imposed entirely by stealth. The other problem with using redirect in this way is that it requires a conversation with the logging server before the browser wanders on to the place the user actually wanted to be. If the logging server is sufficiently slow or off the net entirely, the destination becomes unreachable. The ping attribute addresses both of these problems. Destination URLs are not hidden, and the actual phoning home can happen after the destination page has been displayed. The option of ignoring ping attributes can also be presented to the user; there is no such option for links using redirect (though there are some firefox extensions which try hard for specific sites). So, in theory, ping is an improvement over what came before. Still, it is hard to avoid a sense of discomfort with this feature. Firefox is free software, and free software is written with its users' interests in mind. Free software users have grown accustomed to the idea that, for example, applications will not be quietly phoning home in the background. Certainly, Firefox users have no motivation to leave ping enabled - it potentially compromises their privacy while offering them little in return. People will disable ping, and distributors will have a strong motivation to disable it by default in their packages. The Firefox hackers, by adding this feature, risk appearing to serve a community other than their users, and that appearance could reflect back on the reputation of this fine browser in general.
Security news Felten: CGMS-A + VEIL = SDMI? Ed Felten is looking at the copy protection technologies mandated by the proposed "analog hole" law in the U.S. "The second technology, VEIL, is a watermark that is inserted into the video itself. VEIL was originally developed as a way for TV shows to send signals to toys. If you pointed the toy at the TV screen, it would detect any VEIL information encoded into the TV program, and react accordingly. Then somebody got the idea of using VEIL as a 'rights signaling' technology. The idea is that whenever CGMS-A is signaling restrictions on copying, a VEIL watermark is put into the video."
New vulnerabilities albatross: design error
antiword: insecure temporary file
ClamAV: arbitrary code execution
kernel: multiple vulnerabilities
Kolab Server: broken email-signatures or attachments
mantis: multiple vulnerabilities
novell-nrm: heap memory corruption
struts: cross-site scripting vulnerability
sun-jdk: applet privilege escalation
tuxpaint: insecure temporary file
wine: Windows WMF vulnerability
Updated vulnerabilities apache: cross-site scripting
auth_ldap: format string vulnerability
blender: integer overflow
bogofilter: buffer overflow
bzip2: race condition and infinite loop
ktools: buffer overflow
cpio: arbitrary code execution
curl: buffer overflow
cyrus-imapd: buffer overflows
dia: missing input sanitizing
emacs21: format string vulnerability in "movemail"
enscript: arbitrary code execution
ethereal: denial of service
evolution: format string issues
fetchmail: multidrop bug
ffmpeg: buffer overflow
firefox: multiple vulnerabilities
Foomatic: Arbitrary command execution in foomatic-rip
FUSE: mtab corruption through fusermount
gaim: buffer overflow
gdb: multiple vulnerabilities
gdk-pixbuf: multiple vulnerabilities
gettext: Insecure temporary file handling
groff: insecure temporary directory
gzip: arbitrary command execution
HylaFAX: input validation vulnerability
imap: buffer overflow in c-client
ipsec-tools: denial of service
kdebase: local root vulnerability
kdelibs: kate backup file permission leak
kernel: multiple vulnerabilities
kernel: multiple vulnerabilities
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||