[lsb-discuss] Re: KDE representation
ojschmidt at kde.org
Fri Aug 12 23:38:01 PDT 2005
> 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.
More information about the lsb-discuss