[lsb-discuss] Re: [Lsb-desktop] Re: KDE representation

Matt Taggart taggart at carmen.fc.hp.com
Mon Aug 15 21:18:25 PDT 2005


Olaf Schmidt writes...

> [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. Th
> Qt case fits to this reasoning, even if it doesn't fit to the language how 
> the position was written down.

If the criteria (or it's interpretation) aren't as clear as they could be 
please suggest improvements.

> 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.

I think the RAND terms are a problem for the propriatary applications as 
well, maybe more so since it affects them more than Free Software 
developers.

> 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.

Which is different than it being acceptable for the LSB, under the current 
interpretation.

It just occurred to me that both of Qt's licenses don't meet the LSB 
license critera. Is this a case of two wrongs making a right? :)

> 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.

Yeah we're trying to document it as best we can, we probably need to add 
the recent discussion to the FAQ.

> I am replying to all of them.

Great.

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

s/vendors/developers/    not all developers are vendors
s/contract/obligation/   we want to consider obligations such as the
     GPL in addition to contracts
s/particular vendor/particular sole canonical interface supplier/   not all
     sole canonical interface suppliers are vendors
                        
> By including both Gtk and Qt, no one is forced to by a Qt license from 
> Trolltech.

They are if they pick Qt over Gtk. We've never allowed a case like this, if 
we're to start we need to figure out what the implications are and how to 
deal with them.

> 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).

That's good, it helps make Gtk a suitable replacement for developers who 
can't use Qt.

> 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.

So maybe Gtk isn't a replacement for those people?

> "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.

The point about the slippery slope was that if we open the door for this 
arrangement we open the door for other possibly less desirable situations. 
To take it to an extreme, what if we added a interface where the sole 
canonical implementation required Free Software developers to publically 
renounce Richard Stallman as their leader and print "Open Source rulez!" 
when their program is invoked. Your answer, of course, is that we wouldn't 
add that, but how do we compare those cases in a non-arbitrary way? Can we 
make changes to the criteria that would allow one and not the other? (if we 
can't capture this exactly, we could at least say something like "the 
additional restrictions should be reviewed and approved by the LSB steering 
committee" or something)

> 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.

Yeah I think we might have consensus in this particular case that it 
doesn't make sense to add Gtk without also adding Qt at the same time. 
Which is too bad for Gtk :(. Right now both candidates will require a lot 
of effort to prepare for addition (the phase 3 criteria). What do we do if 
Gtk gets to the point where it's totally ready to be added and blocked only 
because of Qt (either the license, or the spec/test/etc)?

> "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

This is a very good point. We should probably re-consider the existing 
cases with a single canonical implementation and make sure that whatever 
our solution for the Qt/Gtk issue is, it addresses them as well.

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

Well we don't actually specify anything Linux specific, lots of the 
components are GNU, but we also have X11 and SD stuff, so I don't know what 
the proper name should be :)

> 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.

OK.

> "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.

OK. As I said when I stated that, I don't know if we need to solve that 
issue.

So I think we've talked about the following possibilities,

A) The criteria stay the same, Gtk proceeds to inclusion and Qt
    continues to be blocked on license. The Qt using world flames the
    LSB to death.
B) We change the 'best practice' criteria to block Gtk until Qt is also
    ready, and we have neither in the standard. The Gtk using folks get
    upset, maybe less so than case A, they dismiss the LSB as
    crack-smoking suits (or something...)
C) We change the criteria to allow both Qt and Gtk to be added. We do
    this by either,
    1) Saying that Gtk and Qt act as alternatives for each other, with
      a clear explanation about what requirements are and are not
      acceptable.
    2) Saying that properly licensed headers and stub libraries fulfil
      the LSB license criteria.
    3) Some combination of #1 and #2.
    We now have a situation where developers need to be careful about
      which interfaces in the LSB they can target. As you point out
      this may already be the case.

Which of these should we pick and what changes and approval need to happen 
to implement?

Thanks,

-- 
Matt Taggart        Open Source & Linux Organization R&D
taggart at fc.hp.com   Hewlett-Packard






More information about the lsb-discuss mailing list