RE: [lsb-futures] Re: [Lsb-desktop] Re: KDE representation

While we continue to discuss the licensing issues around GPL libraries,
another potential option came up during my discussions with Dirk
Hohndel.=20

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

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

Comments/thoughts...

-Rajesh



> -----Original Message-----
> From: [email protected] [mailto:lsb-futures-
> [email protected]] On Behalf Of Matt Taggart
> Sent: Monday, August 15, 2005 9:18 PM
> To: Olaf Schmidt
> Cc: [email protected]; [email protected]; lsb-
> [email protected]
> Subject: [lsb-futures] Re: [Lsb-desktop] Re: KDE representation
>=20
>=20
> Olaf Schmidt writes...
>=20
> > [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.
>=20
> If the criteria (or it's interpretation) aren't as clear as they could
be
> please suggest improvements.
>=20
> > 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.
>=20
> 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.
>=20
> > 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.
>=20
> Which is different than it being acceptable for the LSB, under the
current
> interpretation.
>=20
> 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? :)
>=20
> > 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.
>=20
> Yeah we're trying to document it as best we can, we probably need to
add
> the recent discussion to the FAQ.
>=20
> > I am replying to all of them.
>=20
> Great.
>=20
> > "The LSB must not force vendors into a contract with any particular
> vendor"
>=20
> 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
>=20
> > By including both Gtk and Qt, no one is forced to by a Qt license
from
> > Trolltech.
>=20
> 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.
>=20
> > 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).
>=20
> That's good, it helps make Gtk a suitable replacement for developers
who
> can't use Qt.
>=20
> > 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.
>=20
> So maybe Gtk isn't a replacement for those people?
>=20
> > "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.
>=20
> 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)
>=20
> > 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.
>=20
> 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)?
>=20
> > "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
>=20
> 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.
>=20
> > You only have a "no strings attached" situation with BSD-licensed
> libraries,
> > but we are the LSB and not the "BSD Standards Base".
>=20
> 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 :)
>=20
> > 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.
>=20
> OK.
>=20
> > "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.
>=20
> OK. As I said when I stated that, I don't know if we need to solve
that
> issue.
>=20
> So I think we've talked about the following possibilities,
>=20
> 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.
>=20
> Which of these should we pick and what changes and approval need to
happen
> to implement?
>=20
> Thanks,
>=20
> --
> Matt Taggart        Open Source & Linux Organization R&D
> [email protected]   Hewlett-Packard
>=20
>=20
>=20
> _______________________________________________
> lsb-futures mailing list
> [email protected]
> http://mail.freestandards.org/mailman/listinfo/lsb-futures