[lsb-discuss] RE: [lsb-futures] Re: [Lsb-desktop] Re: KDE representation
rajesh.banginwar at intel.com
Tue Aug 16 14:06:59 PDT 2005
While we continue to discuss the licensing issues around GPL libraries,
another potential option came up during my discussions with Dirk
We always talk about that the application developer needs to include the
dynamic libraries with the applications if those libraries are not part
of LSB yet. For an application to be LSB compliant either it should
limit the usage to LSB specified libraries and symbols, link statically
with those non-LSB libraries or distribute them along with the
LSB also requires that these distributed library need to be LSB
compliant. Why not loosen that restriction? So with this, LSB will allow
the application developers to allow distribute any non-LSB library and
not require them to be LSB conformant. App A depends on libraries B,C
and D. B and C are covered in LSB and hence not a problem for App A; but
library D is not covered, but shipped with App A making sure the library
is available and installed at /opt hierarchy.
I am not sure whether libQt license allows this or not. If it does, then
we can consider this as a potential solution to this problem.
> -----Original Message-----
> From: lsb-futures-bounces at base3.freestandards.org [mailto:lsb-futures-
> bounces at base3.freestandards.org] On Behalf Of Matt Taggart
> Sent: Monday, August 15, 2005 9:18 PM
> To: Olaf Schmidt
> Cc: lsb-desktop at freestandards.org; lsb-discuss at freestandards.org; lsb-
> futures at freestandards.org
> Subject: [lsb-futures] Re: [Lsb-desktop] Re: KDE representation
> Olaf Schmidt writes...
> > [Matt Taggart]
> > > Do you understand why the LSB has taken this position? Do you
> with it
> > > or do you think we should do something different?
> > Yes, I understand the position. I also agree with the reasoning
> it. Th
> > Qt case fits to this reasoning, even if it doesn't fit to the
> > the position was written down.
> If the criteria (or it's interpretation) aren't as clear as they could
> please suggest improvements.
> > In your example, you imply that RAND terms only are problematic for
> > 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
> well, maybe more so since it affects them more than Free Software
> > This is why Qt is available under both terms, and
> > experience shows that both proprietary vendors and free software
> > are comfortable with this license combination.
> Which is different than it being acceptable for the LSB, under the
> 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
> > 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
> the recent discussion to the FAQ.
> > I am replying to all of them.
> > "The LSB must not force vendors into a contract with any particular
> 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/
> sole canonical interface suppliers are vendors
> > By including both Gtk and Qt, no one is forced to by a Qt license
> > Trolltech.
> They are if they pick Qt over Gtk. We've never allowed a case like
> we're to start we need to figure out what the implications are and how
> 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
> > other way around).
> That's good, it helps make Gtk a suitable replacement for developers
> 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
> > 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
> > same problem and meets the current license criteria.
> The point about the slippery slope was that if we open the door for
> arrangement we open the door for other possibly less desirable
> To take it to an extreme, what if we added a interface where the sole
> canonical implementation required Free Software developers to
> renounce Richard Stallman as their leader and print "Open Source
> when their program is invoked. Your answer, of course, is that we
> add that, but how do we compare those cases in a non-arbitrary way?
> make changes to the criteria that would allow one and not the other?
> can't capture this exactly, we could at least say something like "the
> additional restrictions should be reviewed and approved by the LSB
> committee" or something)
> > Allowing a single toolkit would be a slippery slope for devaluing
> > practise" criterion, and including no toolkit would force us to do
> > 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
> of effort to prepare for addition (the phase 3 criteria). What do we
> Gtk gets to the point where it's totally ready to be added and blocked
> 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
> > checking the legal consequences of the licenses involved. The LGPL,
> > example, has a clause about reverse engineering. By using Qt, they
> > rid of this requirement of the LGPL.
> > Currently the license criterion of the LSB misleads vendors into
> > that using LGPL means "no strings attached" and developing and
> > application "however they choose". But if an application vendor
> > application with a standard EULA forbidding reverse engineering,
> > automatically lose their right to use the library. According to the
> This is a very good point. We should probably re-consider the existing
> cases with a single canonical implementation and make sure that
> our solution for the Qt/Gtk issue is, it addresses them as well.
> > You only have a "no strings attached" situation with BSD-licensed
> > 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
> the proper name should be :)
> > We should correct the misleading language of the license criterion
> > clearly state that developers must always check the licenses before
> > start developing against the LSB. Everything else would be
> > "Developers cannot easily port Qt applications to Gtk"
> > This is correct, but I do not see this as problem. Vendors who want
> ship a
> > proprietary Qt application must always buy the license before they
> > development, so there is no need to change the license in the middle
> > development effort. Qt developer licenses have no time restriction.
> > need to refresh your license if you want extended support and
> > ISVs who distrust Trolltech can base their applications on Gtk. No
> > be forced to use Qt.
> OK. As I said when I stated that, I don't know if we need to solve
> 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
> ready, and we have neither in the standard. The Gtk using folks
> 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
> 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
> to implement?
> Matt Taggart Open Source & Linux Organization R&D
> taggart at fc.hp.com Hewlett-Packard
> lsb-futures mailing list
> lsb-futures at mail.freestandards.org
More information about the lsb-discuss