First rpm.org-RPM version released

Recently the first version of rpm.org’s RPM tool was released. While it is only a minor version (4.4.2.1) this release is a milestones because it is a coordinated release between the participating distributions.

rpm.org, the new community behind the package management tool RPM, released a first common version, RPM version 4.4.2.1.
The release is more a bugfix release focusing on stability and reliability, but nevertheless marks an important date for RPM: for the first time in years this release is coordinated between several distributions. This can be best seen by the changelog: bug fixes where included from both, Red Hat and Novell/Suse.

Previous to this release RPM was maintained in house for each distribution. The disadvantage was duplicated effort but also stagnated development because there was no real central project which could manage and drive the development. Therefore each distribution had a growing stack of patches for RPM which lead to several more-or-less forks of RPM.
The reunification will most likely lead to a new development impulse and maybe even to a better coordination of the package management of the RPM distributions. My hope is indeed that they come closer again.

However, in these days there is also another RPM version developed by Jeff Johnson. He was employed by Red Hat for some time as the main developer of RPM, but problems and difficulties between both parties resulted in a break up of that relation.
Johnson continued the RPM development on his own and in the end launched rpm5.org as the project page. Together with several other developers the development is also driven forwards, however it is not clear which distributions will take over that rpm version. The only officially supporting project seems to be OpenPKG atm.

I wonder how this will turn out: I’m not sure who has the name rights of RPM, but if one party has them exclusively I would not be surprised if the other party has to change the name in the end. The current solution is just confusing for normal users…

German Court convicted Skype of violating the GPL

German district court Munich has convicted Skype of violating the GPL. One of the VoIP telephones sold by Skype run Linux, but the GPL text was not handed out together with the phone, although the GPL requires that.

The telephone is actually build and delivered by SMC Networks. But without the GPL text. Harald Welte, the founder of gpl-violations.org who helds copyright in parts of the Linux kernel, asked the company to correct that problem, but they only included a sheet of paper with a set of links, and that isn’t enough.

Hence Harald Welte took legal action with the help of the German Institut für Rechtsfragen der Freien und Open Source Software (roughly translated Institute for questions of law in case of Free and Open Source Software) – and won the process (German only). Skype now has to deliver the licence text with each telephone.
The court also ruled that providing the source code online only is only sufficient if the product is delivered online as well. In cases of hardware which includes the software the source code must be provided in other ways as well (unfortunately the sources are not clear in which ways).

For Germany this process is interesting because it shows (again) that the GPL is bullet proofed for German courts. You have to obey to the licence terms – and the other way around you can also rely that the licence will work in front of a court.
While the GPL was already verified in Germany in case of other lawsuits this time was the first time that a foreign country was convicted of violating the GPL. This shows that you can fight for your rights within the GPL even against foreing companies in front of German courts. Keep in mind that US lawsuits have the tendency to take more time (and most likely more costs) than German lawsuits!

Btw., I wonder when we will see the first GPL3 related lawsuit. And I wonder when we will see the first GPL3 patent lawsuit.

And just to make one thing clear: I’m not against SMC or Skype. Not at all. But they have to make sure that they meet the terms of the licences of the software they use. And this is true for proprietary software as well as for the GPL.

Situation around KHTML and WebKit finally settled

As it was now revealed the situation around KHTML and WebKit is settled. KDE will focus on integrating WebKit into the system while also implementing all yet missing KHTML features into WebKit.

Background

WebKit is a KHTML fork done by Apple some years ago. Today it is developed not only by Apple but also by Nokia, Adobe, Trolltech and many KDE developers. There is even a basic Qt port which can be run under Linux.

At the same time, KHTML development continued since the mentioned fork. Some of the development efforts and results were shared with WebKit, others were not. The main problem was that Apple needed quite some time to learn how to interact with Open Source developers and projects. They did not violate the licence, but they behaved pretty rude, making it often impossible to really incorporate their patches and changes.

The question was now if KDE should (also) adopt WebKit or stay with KHTML.
WebKit offered the advantage of more parties taking part in the development as well as more coverage and a wider spreading of the engine itself. However, KHTML offered the advantage of having an in-house solution which is under total control. Also, there were/are still some bad feelings towards Apple left among some developers because of the way Apple acted in the past.

Therefore the plan was originally to keep KHTML and provide a kpart solution of WebKit as an option. This was developed and was expected to be ready around KDE 4.0 or KDE 4.1.
The result would be to have a co-existence of both, with KHTML as default and WebKit as an option.

The new situation

Now Troy Unrau unveiled that the developers discussed this topic at aKademy 2007 in detail – and settled on WebKit for the long term:

While there are still a few reservations, the consensus is to develop a Webkit KPart for embedding into Konqueror at the earliest opportunity and to take a more active role in the development of Webkit itself.

All features yet missing in WebKit are supposed to be integrated with WebKit, making this more a merge than a switch.

This will certainly give KDE browsers better support from web developers since more people will be able to test with WebKit (because it is wide spread) than with KHTML. Also I’m quite sure that having so many parties developing together will push the development of the engine quite a lot – I would not be surprised if WebKit would become the most standard compliant browser available.

The technical interesting thing is that most KDE users will not see any difference: due to KDE’s excellent design it will be possible to use Konqueror with WebKit without any differences. It will just seamingless integrate with Konqueror and all other applications which use kpart to display html pages.
Also, development wise not too much will change for many KDE developers. Quite some work was already done within WebKit by them, so they are already used to develop WebKit.

Of course the integration still have to take place. At the moment KDE 4.0 is very close to the first Beta release (which is scheduled for July 25, which is tomorrow!) and therefore there should be no new features. On the other hand discussions are under way to slip the Beta date by one month and to publish an Alpha 3 at the 25th. With such a slip of the release date we might even see WebKit as a default kpart in Konqueror in KDE 4.0. I think this will be made clear the next days.