User: Password:
Subscribe / Log in / New account

Leading items

Get Legal - but not too soon

Get legal. Get The marketing team, sensing an opportunity in the latest round of Business Software Alliance attacks on companies using "pirated" software, has announced the "Get Legal - Get" campaign. It features a cute logo (seen on the right) and a web page discussing the difficulties in remaining in compliance with proprietary software licenses., of course, offers a way out: switch to free software, make no license payments, and be entirely in compliance with the law.

The heavy-handed techniques employed by groups like the BSA have always been destined to play into the hand of free software advocates. Even companies with strict "a license for every copy" policies (and strict enforcement to back those policies up) can find themselves with unlicensed copies of software on their machines. The BSA, with its rewards for employees who turn in their companies and its police raids, can make the cost of those unlicensed copies very high. And, even if a company is able to stay in complete compliance, it bears the costs of license tracking and software audits. So is right to capitalize on this behavior; free software does, indeed, offer a way to avoid the expensive hassles which can accompany proprietary code.

When LWN posted a pointer to this campaign on May 1, however, the marketing team was not amused. One participant exclaimed:

Jesus what an idiot. Makes you wonder if they're purposely trying to wreck the campaign before it takes off.... I'm CC'ing this message to lwn to see if someone can at least smack that poster for us.

Your editor idiot, feeling suitably smacked, withdrew the posting. It is certainly not LWN's wish to "wreck" the efforts of free software projects.

This episode raises an interesting question with regard to how free software projects deal with their user communities. The usual rule is "release early, release often"; the idea being that the opportunity to obtain input from a wider community should be taken at the earliest possible time. There is little to be gained by holding on to work which is intended to be released anyway.

That ethic appears to be changing in some places, however. Companies perform free software work behind closed doors and release the result in one big pile with the obligatory press release. Releasing code earlier, it is said, is just an invitation to "bike sheds" and "stop energy," and an impediment to actually getting the work done. And marketing campaigns are, it would seem, so fragile that any visibility in the wider community threatens to "wreck" them. So work must be withheld until it is finished, ready to present itself in its final form.

It is worth asking whether press releases are really the best way for free software projects to interact with the rest of the world. A press release is fine as a way of gaining the attention of the mainstream media, but there is little in our community which needs to be kept secret until the PR has been officially distributed. It is hard to imagine that the strong message behind the "Get Legal" campaign can truly be compromised if the community knows, before the press release hits the net, that such a campaign is being developed. In fact, it's even possible that people outside of the core marketing group could have useful input which could make the campaign stronger.

The value in the free software process is not just in the delivery of something cool on a date picked by somebody in the marketing department - it's in the process. Without the process, all you have is another corporate product, albeit with less restrictive conditions and a nicer price tag. At times, we may all be tempted by the idea of dispensing with an open development process (and the community which goes with it) in the name of faster development or a splashier release. But going that way has its costs, and risks taking us closer to the proprietary systems that we have worked so hard to replace.

Comments (28 posted)

Looking forward to KDE 4

May 3, 2006

This article was contributed by Tom Chance.

Ever since the first technology preview of Qt4, and probably even before, KDE 4 has been the subject of wild speculation. The KDE Project actually discussed starting the KDE 4 branch as far back as August 2004 in a birds of a feather session. Two major releases later and the developers are finally buried deep in their libraries, overhauling and rethinking the basics of their desktop environment. By the time KDE 4.0 is released, which could be late this year or early 2007, developers will have a lot of new toys to play with.

To give you an idea of what KDE 4.0 will be like it's worth looking back at KDE 2.0, which could almost have been described as a technology preview rather than a complete desktop environment. Basic building blocks for KDE first surfaced in that release, such as the KIOSlaves that enable all KDE applications to handle all kinds of data transparently, from networked machines accessed by ssh to man pages and Beagle searches. In KDE 3.0 those technologies finally matured, and through the 3.x series we have seen the developers realize their promise, creating the desktop that so many know and love today.

KDE 4.0 is going to be a bit like KDE 2.0 - although far more useful and mature - in that it will first expose a lot of infrastructure even if few of the applications manage to exploit their potential. According to Aaron Seigo, the core developer of Plasma:

Users are only likely to see applications using the infrastructure in interesting ways by KDE 4.1, and then through the rest of the 4.x series it will mature in the same way as 3.x. Hopefully it will happen with greater speed than KDE 2 as we aren't starting completely from scratch everywhere and we have a bigger development team. I'd expect early adopters and "tourists" to jump into kde 4.0. but not school or enterprise deployments.

Of course for developers this doesn't matter, the hype is all about the technology, so even if Seigo is right and KDE 4.0 is a "first draft of a post-technical preview type of release" there will be plenty to play with. Don't say "vapourware" to a KDE developer!

Phonon, Solid, Plasma, Akonodi: these are the buzzwords that give substance to the hype. Each mini-project is targeted at making developers' lives easier, which is a big part of the KDE development philosophy: give developers great tools and they'll make great applications.

Phonon addresses the complexity of audio and video functionality in applications, whether they're simple games with silly beeps, instant messengers that need audio and video devices, or complex mixing studios. The API should allow developers to get on with the application and have a reliable, desktop-integrated multimedia framework do the boring work. At the moment, for example, Kaffeine can embed videos in Konqueror but it is prone to crashes because it has to make kernel-level calls on its own. With Phonon, developers can do away with such hacks and concentrate on one API if they want enhanced functionality.

The other design decision was to allow developers and users to use different multimedia frameworks underneath Phonon - such as GStreamer, NMM, MAS and Xine - rather than simply integrating one into the KDE libraries. This decision, popular in Amarok, should promote more innovation amongst developers and choice for users, though it will also undoubtedly be more work than just adopting, say, GStreamer, as the GNOME developers have done.

Solid takes up the challenge set by Robert Love's Project Utopia, and will try to make interaction with hot-pluggable devices and networks more, well, solid. KDE already uses DBUS and HAL to provide basic functionality that is almost equivalent to that found in GNOME, Microsoft Windows and Apple MacOSX. But integration has been hard work, and in KDE 3.5 it can only shine through KIOSlaves and other "old" technology. The main design goal of Solid is to give developers a single, consistent API so that the desktop can become more flexible and integrated, much like Love's goals with Project Utopia. It should be easy to make your application fully aware of changes in network and hardware availability. The second design goal is to avoid locking KDE into platform-specific technologies like HAL (which currently only works with Linux).

Plasma will unite and rethink various components in the desktop, including kicker and its various applets, SuperKaramba widgets, the K Menu application launcher, the Run Command dialogue and the desktop space itself. Eye-candy addicts will enjoy the more beautiful design that it brings, but developers are more likely to appreciate the elegant API. Based around a few basic elements, Plasma should help the desktop become a truly functional space rather than a dumping ground for downloads and systray applets. The lofty ambition of Plasma is to completely change the way we interact with the desktop, becoming "workflow sensitive". Project-based collections, network aware widgets for collaboration, interfaces that you can zoom in on to examine details and zoom out of to gain overview and free-form layout of add-ons are all being experimented with. But of course by KDE 4.0 it's likely to change developers' mindsets more than the actual implementation of the desktop.

There are many other ideas floating around, such as Akonadi, a storage layer for PIM (personal information management) applications. But, like Akonadi, many of these ideas may not appear until KDE 4.1. By October we should see a technology preview, which will give developers their first chance to get hands-on experience with which to judge the hype. In the meantime there's always SVN and KDE 2.0 to give you a sense of the excitement.

Comments (14 posted)

Legislative update

It seems to be legislative season, with interesting laws popping up like the flowers in this (northern hemisphere) spring. While much of this activity is happening in the US, there is also, as we will see, activity on the international scene as well.

Network neutrality

As telecommunications companies in the U.S. slowly coalesce back into the Ma Bell we knew over twenty years ago, they are increasingly making scary noises about taking control of the Internet traffic which passes over their networks. These companies would like to shake down operators of web sites for the right to communicate with their customers - who have already paid for their network access. They would like to impede the passage of voice over IP traffic, since Internet telephony services conflict with their own offerings. In general, the idea of the net as a service by which any two applications can communicate using the protocols of their choice is under threat.

In response, there have been several pushes for "network neutrality" laws which would prohibit telecom companies from discriminating between packets. These proposals have, so far, not gotten all that far in the legislative process. But they keep coming; the latest is the Markey Network Neutrality Act of 2006. The core language in this act is:

Each broadband network provider has the duty to ... not block, impair, degrade, discriminate against, or interfere with the ability of any person to utilize their broadband service to: (A) access, use, send, receive, or offer lawful content, applications, or services over broadband networks, including the Internet; or (B) attach any device to the provider's network and utilize such device in connection with broadband service, provided that any such device does not physically damage, or materially degrade other subscribers' use of, the network.

There are some exceptions, of course; for example, spam filtering and "parental control" are allowed, as long as they are optional. ISPs are also allowed to prioritize classes of service - voice, for example - as long as all traffic of that class is prioritized in the same way.

Network neutrality laws have a certain appeal; they attempt to codify the way we tend to think the net has operated all of these years anyway. There is danger, however, in giving an agency like the U.S. Federal Communications Commission (FCC) the power to regulate traffic over the net. Once the FCC starts telling ISPs how to handle the packets they carry, there will inevitably be pressure from well-funded interests to tweak those regulations in their favor. The net's relatively unregulated regime has suited it well this far; we should think carefully before starting to add regulations to the net.

Broadcast flags

U.S. Senator Stevens is pushing a huge telecommunications bill for this session. It includes a number of things, including a network neutrality section - though the Stevens version simply requires the FCC to crank out occasional reports on whether neutrality regulation may be required. Buried in the depths of this bill, however, is a subsection called Digital Content Protection Act of 2006. This section, quite simply, directs the FCC to implement the broadcast flag as described in its previous attempts.

The consequences of the broadcast flag have been discussed many times. It will treat anybody with a television or radio as a pirate and deprive them of their fair use rights. A mandated broadcast flag will also outlaw any radio or TV implementation in free software. Code which can be changed by end users will never live up to the robustness requirements that come along with broadcast flags. So this sort of legislation means the end of projects like MythTV - at least, in the jurisdictions where the legislation has force.


The World Intellectual Property Organization is busily working on a treaty. There is now a draft of the new WIPO treaty in circulation; it has been put onto a fast track with an eye toward adoption in 2007.

There is a fair amount of bad news in this draft. It includes a DMCA-style anti-circumvention clause which all adopting countries would have to implement; the DMCA could yet become a worldwide law. This treaty also looks to extend its 50-year (minimum) protection to "webcasting organizations" which make content available on the net. The definition of a "webcasting organization" is interesting:

"webcasting organization" means the legal entity that takes the initiative and has the responsibility for the transmission to the public of sounds or of images or of images and sounds or of the representations thereof, and the assembly and scheduling of the content of the transmission.

Note that there is no mention of the "webcasting organization" actually owning this content or having any other rights over it in any way. By virtue of "taking the initiative" and putting content up for distribution over the net, an organization can claim exclusive copyright rights over that content for 50 years. Should somebody else wish to use the webcast materials in another work, it will no longer be sufficient to obtain the rights from any relevant copyright holders; the middlemen represented by the "webcasting organizations" will also be involved.

The webcasting provisions are an optional part of the WIPO treaty, though, as others have pointed out, it would be highly in-character for the U.S. to require adoption of those provisions as part of any trade treaty it signs. The DRM provisions are not optional, however, and neither are the articles giving broadcasters exclusive rights over "fixation" (i.e. recording) of their output. This legal right, combined with legally-enforced DRM, will, once again, be the end of projects like MythTV.

(See writeups by Cory Doctorow and the EFF for more information on WIPO).

The drive to gain control over information is relentless. As a community based on openness and sharing of information, we are threatened by those who require technical and legal controls over the sharing of information. If we want to continue to live in a world where we have the right to create, to share our creations when we so choose, and to use free systems to do so, we must pay attention to these threats. Tempting as it may be to ignore the unpleasant legislative processes happening world wide, the sad fact is that those processes will not ignore us.

Comments (4 posted)

Page editor: Jonathan Corbet
Next page: Security>>

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds