Re: KDE representation

[Matt Taggart]
> Do you understand why the LSB has taken this position? Do you agree with it
> or do you think we should do something different?

Yes, I understand the position. I also agree with the reasoning behind it. The 
Qt case fits to this reasoning, even if it doesn't fit to the language how 
the position was written down.

In your example, you imply that RAND terms only are problematic for the free 
software community and open source terms only are problematic for vendors of 
proprietary applications. This is why Qt is available under both terms, and 
experience shows that both proprietary vendors and free software developers 
are comfortable with this license combination.

In your other emails, you list a number of other objections to the Qt license. 
Thanks for naming them all. This helps the discussion a lot.

I am replying to all of them.


"The LSB must not force vendors into a contract with any particular vendor"

By including both Gtk and Qt, no one is forced to by a Qt license from 
Trolltech. The KDE project has written a number of technologies to ensure 
that Gtk programs integrate well with the KDE desktop (far better than the 
other way around). We will continue with this approach. Nevertheless it is 
clear that we will keep using Qt in KDE itself, and there will always be 
developers who prefer Qt and maybe kdelibs.


"Allowing Qt into the standard would be a slippery slope"

This is why I suggest to clearly define the rules when an OSS/proprietary dual 
licensed library is admitted. My suggestion: a) The library must be 
open-source. b) There must be an alternative in the standard that solves the 
same problem and meets the current license criteria.

Allowing a single toolkit would be a slippery slope for devaluing the "best 
practise" criterion, and including no toolkit would force us to do the whole 
desktop standardisation effort ourside of the LSB.

"Vendors might accidentally violate the Qt licence"

It is dangerous to imply that developers can code to the LSB standard without 
checking the legal consequences of the licenses involved. The LGPL, for 
example, has a clause about reverse engineering. By using Qt, they could get 
rid of this requirement of the LGPL.

Currently the license criterion of the LSB misleads vendors into believing 
that using LGPL means "no strings attached" and developing and deploying the 
application "however they choose". But if an application vendor ships a Gtk 
application with a standard EULA forbidding reverse engineering, then they 
automatically lose their right to use the library. According to the FSF, they 
even have to contact each copyright holder of the library personally and ask 
them for "forgiveness" before they can continue to ship their application 
after they have rectified the situation.

You only have a "no strings attached" situation with BSD-licensed libraries, 
but we are the LSB and not the "BSD Standards Base".

We should correct the misleading language of the license criterion here and 
clearly state that developers must always check the licenses before they 
start developing against the LSB. Everything else would be irresponsible.


"Developers cannot easily port Qt applications to Gtk"

This is correct, but I do not see this as problem. Vendors who want to ship a 
proprietary Qt application must always buy the license before they start 
development, so there is no need to change the license in the middle of the 
development effort. Qt developer licenses have no time restriction. You only 
need to refresh your license if you want extended support and updates. And 
ISVs who distrust Trolltech can base their applications on Gtk. No one would 
be forced to use Qt.


Olaf