Leading items

The third GPLv3 draft

The original plans had called for the third draft of the GNU General Public License update to come out late last year. Needless to say, things didn't happen that way. Between trying to address concerns raised from various directions and responding to the Microsoft/Novell deal, the Free Software Foundation ended up having to slip its schedule; as a result, eight months have passed since the second draft was released. One could well argue that a major license update should not be made in a hurry, and thus the delays are not problematic. In any case, the wait is over: the new GPLv3 draft is available. In many ways, the draft resembles its predecessors; in others, it has changed significantly. This article will focus on the differences.

One area of conflict has been the anti-DRM provisions. The relatively uncontroversial language stating that GPLv3-licensed works are not "technological measures" has been reworked slightly to give it a more international focus:

The previous draft had been specific to the DMCA, but anti-circumvention laws are a global issue, so this change makes sense.

The "anti-tivoization" provisions have been the source of much of the disagreement over this license. The new draft changes those sections significantly - though the intent remains the same, and people who did not like the previous versions are unlikely to feel better about the new language. In previous drafts, signing keys required to convince hardware to run a given binary were deemed to be part of the source code, and thus a required part of the (required) source distribution. The drafters decided that extending the definition of "source code" in this way was not the best idea. So, instead, we now have "installation information":

The license goes on to say that, if GPLv3-licensed code is shipped as part of a product, the installation instructions must be made available as well. Actually, it's not anywhere near that simple, for a couple of reasons. The first is this concept of a "user product," which is new in this draft:

The actual requirement for the shipping of installation information is:

One might well wonder what is going on here. In the explanation materials sent to LWN with the license draft, the FSF states:

The nature of these innocuous business models is not spelled out. What it comes down to, though, is that gadgets intended to be sold to businesses will be exempt from the "installation instructions" requirements. This seems strange; it may well be businesses which would have the most use for the ability to change the code running in devices they purchase. The FSF has been saying that the right to replace the software in a device is required for true software freedom; why is that right now less important for devices which are not "user products"?

This exemption could prove to be a big loophole. Many years ago, your editor bought a digital audio tape deck. The rules for DAT decks in those days specified that they must implement the "serial copy management system" - a couple of bits in the digital audio data stream which indicated whether another deck was allowed to record that stream or not. It turned out that decks intended for "professional use" were exempt, however - musicians, after all, might actually want to make copies of their work. As far as your editor could tell, the difference between "professional" and "consumer" decks (at the low end, anyway) consisted of a pair of rack-mount ears; "professional" decks were available at the local guitar shop. Anybody could get a SCMS-free deck with little trouble. The exemption for devices which are not "user products" looks similar; with this language, the FSF may well be setting us up for a flood of "business use" gadgets which happen to available at the local big-box technology store.

The "additional terms" section has been simplified a bit. The second draft included the optional requirement that, if the covered code is used to implement a web service, the users should be able to get the source via that service. This requirement, intended to close the "web services loophole," is absent from the third draft.

The termination rules still allow any copyright holder to terminate the license if it is violated. There is a new escape clause, though:

An opportunity to fix a GPL violation is consistent with how the license has been enforced so far.

The patent language has changed significantly as well. The second draft included a covenant not to enforce any relevant patents against recipients of the software; in the third draft, instead, an explicit patent license is granted. This change is apparently intended to make the patent grant language look more like that found in other licenses.

The change which will attract the most attention, though, is the language aimed at the Microsoft/Novell deal; it does not look like anything found elsewhere. It starts by broadening the definition of a "patent license" to include things like covenants not to sue, thus covering the Novell non-license. There is a clause saying that if you distribute covered code under the protection of such a license, you must arrange for all recipients - anywhere - to have the same protection. Then there's this part:

The FSF is still considering whether it should grandfather in deals made before this draft was released.

The restriction to deals involving software companies is strange; it will just cause the next deal to be done by way of a patent-troll corporation. The prohibition only applies if the payments are based on the number of copies distributed, meaning that the next such deal will look like a fixed-sum payment - we will never know how that sum was calculated. There are enough loopholes in this section that it seems unlikely to slow down the next patent shakedown in any significant way. If the grandfather clause is added, it will not even affect Novell, the target of this whole thing.

There is an interesting new exception in this draft:

The posted version of the Affero GPL is version 1; your editor was not able to find any mention of a second version anywhere. The FSF must know something the rest of us are not yet privy to.

Finally, there is explicit support for signing away the right to decide on future license changes to others:

There are various other tweaks - providing source by way of a network server is now officially allowed, for example. In many ways, GPLv3 is shaping up exactly as it was supposed to: it is bringing the license up to contemporary, worldwide standards and is evolving in response to input from the community. Your editor anticipates that the new anti-DRM and anti-Novell language will be the subject of significant criticism, however. They are developing the complex, baroque nature of code which has been repeatedly patched far beyond its original design. That language may require some work yet.

The current plan calls for the FSF to accept comments on this draft for the next 60 days, after which the final draft will be released. One month later - around the end of June - the GPLv3 will become official. The FSF claims to be actively looking for comments, so now is the time for anybody who has remaining concerns to speak up. Regardless of whether certain high-profile projects move to GPLv3, we all will be working with code covered by this new license. It's important that we help the FSF get it right.

Comments (55 posted)

Beryl and Compiz: back together again?

Once upon a time, just over one year ago, the Compiz window manager hit the net. Compiz, which features fancy 3D effects, was the result of some months' worth of behind-closed-doors work at Novell. There was an enthusiastic reception, and others began to hack on the code. It didn't take long, however, before some of those others found that it was hard to get their changes back into the Compiz mainline. Eventually one of those developers, Quinn Storm, got tired of carrying an increasing collection of external patches. The result was a fork, and the Beryl project was created.

These events can be acrimonious, and the Compiz/Beryl fork was no exception. Beryl developers complained that Compiz was run as a Novell fiefdom which was uninterested in patches from the outside. On the Compiz side, Beryl's decision to relicense the code from the MIT license to the GPL meant that code could flow from Compiz to Beryl, but not in the other direction. In early 2007, a Compiz site administrator vandalized Beryl's site, an act which must surely mark a low point in relations between the two projects.

During this time, development on both sides continued, with Beryl quickly developing a reputation for bells, whistles, and an unbelievable number of configuration options. Compiz took a more conservative course, working on getting the core functionality working in a way which seemed, to its core developers, to be right. Despite all of this, the differences between the two code bases are apparently less than one might think. No major architectural change have happened; instead, most of Beryl's additions come in the form of plugins.

Recently, though, the Beryl developers started to ponder some more sweeping changes. According to Robert Carr, the conversation went like this:

The result was that the two projects started talking again. As of this writing, it would appear that Beryl and Compiz have come to an agreement to end the fork and join back into a single project. Should things happen this way, the results for eye-candy fans should be good. There are a few details which need to be worked out first, though.

One of those is licensing. The fact that Beryl's work is licensed under the GPL means that, for the two projects to merge, one of them must be relicensed. It looks like Beryl will be the one to give here, moving its core back to the MIT license. The number of contributors is evidently sufficiently small that this sort of change is still feasible.

Then there is the issue of how to merge the changes in the code. According to Mr. Carr, agreement has been reached on most points, at least with regard to the core changes. In the past, Compiz leader David Reveman has not been receptive to Beryl code:

It seems that the situation is different now:

The merge is probably helped by the Compiz project's plan to split the code into "core" and "extra" modules. Much of what is currently in Beryl will, it seems, slip into compiz-extra with little trouble.

So if licensing and code are not problems, what are the potential sticking points in this merger? It seems that there are two of them: naming and leadership. The Beryl side is pushing for a new name and structure which would enable a clean start for the entire project. Without that, they fear, one side or the other will probably get the short end of the stick. Mr. Reveman responds:

From reading the discussion, one gets the sense that the leadership issues have not yet been the subject of serious discussion. Some sort of project management model will have to be worked out, or the newly merged project will run a risk of falling victim to the same tensions and forking again.

There should be an answer, though. It would be a sad day if these two projects could come together, resolve their technical and licensing differences, then drop the whole thing because they cannot agree on the name. Some great progress has been made on reunifying one of the most unpleasant forks in our community; it seems like the remaining issues must somehow be amenable to a solution.

Comments (8 posted)

Working with raw images on Linux

This article is part of the LWN Grumpy Editor series.

Your editor's exploration of high dynamic range (HDR) techniques inspired one comment suggesting that photographic topics should be avoided in the future if your editor wishes to avoid looking foolish. As it happens, fear of looking foolish would make this particular job almost impossible to do; when one writes for an audience that knows more than the author, occasional foolishness will inevitably result. Even for authors who are not so inherently foolish as your editor. So, foolish or not, here is a followup to the HDR article; this week's topic is working with raw files.

Most digital cameras are set to produce JPEG files; for many applications, such files are more than good enough. But most decent cameras support other formats, and a vendor-specific raw format in particular. The raw format contains something close to what was measured by the sensor, with a minimum of processing in the camera. These files are large, unwieldy, and in a proprietary format, which argues against their use in many situations. But, by virtue of holding the original image data, raw files give the photographer a much wider range of options later on. Much of the processing normally done in the camera (white balance, histogram adjustment, etc.) can be tweaked later on. For this reason, people who do photography for a living often prefer to record in the raw format.

Even for the rest of us, who have no hope of earning a living that way, raw files can keep creative options open. For people who like to play with HDR techniques there is an additional advantage: the camera typically record 12 to 16 bits of data for each channel - rather more than fits into a JPEG file. That, in turn, means that the dynamic range of raw files is significantly higher - assuming, of course, that the camera has a sensor which can meaningfully record data at that resolution. The extra range can be used to increase detail in images in a number of ways, including the use of tone mapping techniques.

Raw file formats are created by camera manufacturers, who generally feel no need to document their work. They will usually sell you a tool for decrypting their raw files - but, strangely enough, Linux support is usually missing from the feature list. Fortunately, the free software world benefits from the work of Dave Coffin, who has set a task for himself:

The result is dcraw, which comes awfully close to meeting that goal. It supports a huge list of cameras, and it does so at a high level of quality - arguably better than the vendor's tools. It is a command-line tool, aimed at batch operation or invocation from other programs; dcraw can be run from a gimp plugin, for example. Just about anything one wants to do with a raw image file is supported by dcraw.

The only downside is that processing raw images can be an interactive process. If one wants to make adjustments, a command-line tool can get tiresome after a while. The answer to that complaint is the UFRaw tool, which is built on dcraw. UFRaw allows adjustment of the white and black points, gamma curve, white balance and more - all with immediate visual feedback. When the desired result is achieved, it can be saved in a number of formats.

UFRaw is not perfect. It's one of those applications that thinks it's clever to remember where the last image was stored and put the next one in the same directory. Your editor, instead, expects programs to default to the directory they were started in, or, failing that, to the directory where the source file was found. It's aggravating to save a file then have to figure out where the application decided to put it. UFRaw is doubly obnoxious in this regard because it immediately exits after saving the file. The non-resizeable window is also annoying. One assumes these little difficulties can be dealt with eventually; meanwhile, the core functionality is good stuff.

What sort of results can one expect? Here are three versions of the window view photo featured in the HDR article:

Original	UFRaw edited	Tone mapped

(See this page for larger versions of the pictures).

Some quick editing with UFRaw was sufficient to bring out a fair amount of detail in the plant in the foreground - though the background lost some contrast as a result. The tone-mapped photo does better at maintaining contrast throughout the frame. The end result is not as complete as the full HDR image (visible here), but it does show that raw files contain information which can be recovered later on to improve the picture. Taking a single raw image is much easier than the full bracketed HDR technique, and it allows tone mapping techniques to be used on subjects which stubbornly refuse to stand still for a few minutes while several shots are taken.

One thing worth noting in conclusion: we should not take our ability to work with raw images for granted. Vendors like Nikon and Sony are known for encrypting their raw formats. The language they use to justify themselves will look most familiar; consider this advisory from Nikon regarding its NEF format:

In other words, photographers are being locked out of their own images for their own benefit. All of the usual counterarguments apply here; photographers might just have their own idea of where there benefit lies. And what happens to those raw images a decade or two from now, when the vendor has long since ceased to support the format and, even if one can find one's single legal backup copy of the software, it refuses to run on currently available systems? Fortunately, we have dcraw, which will document the reading of these formats indefinitely.

So far, vendors' attempts to encrypt raw files have been broken in short order. Chances are that trend will continue. But there is little difference between breaking into a raw image file and turning off the copy protection bits inside a PDF file. The stage is clearly set for an ugly battle, probably involving the DMCA, when some vendor decides to turn nasty.

Photographers have been worried about this issue for a few years now; efforts like the OpenRAW project have been working, with little success, to get camera manufacturers to open up their formats. Adobe has been pushing its Digital Negative format as a standard; it would be a step in the right direction, but this format still has mechanisms for the embedding of vendor "private" information. At this time, there does not seem to be a clear solution in sight. We must deal with cameras just like we deal with many other types of hardware: we have to figure out how it works ourselves.

Comments (13 posted)