[lsb-discuss] The LSB and Qt
dbb at beatties.us
Tue Nov 9 07:20:55 PST 2004
Scott: first off, thank for getting back with us on this topic and
sharing your thoughts with us.
I personally have one question that touches on the legal nature of an
ISV using a GPL'd version of your libraries that perhaps you could
give an official answer to for Trolltech.
If a commercial ISV were to produce a product which would utilize
some LSB specificied QT libs and these LSB specified pieces were
available as commonly available GPL'd code by all certifying distros,
would the ISV code that made use of the GPL'd QT libs be infected
such that this commercial code would also have to be considered as
We have had a number of discussion about this point, but not having
any case law that speaks to this specifically leaves a number of us
wondering what will happen to commercial ISVs in this case.
I believe the LGPL would allow a commercial ISV to build, ship, and
utilize the lib code with their commercial products without having
this point be of concern, but from what I have heard from ISVs there
are a number of them that do worry about shipping product that relies
on GPL'd code. (I don't know if I agree with this concern in general
as the whole system their apps would run on is GPL based, and I would
hope the courts would find an ISV could utilize common GPL'd libs
without infecting their apps, but again this has not been determined.
Is there any way you (meaning Trolltech) could see of helping us with
this concern so in the end ISVs would not have any question about
exposing their inner workings (their bread and butter) to possible
Thanks again Scott for bringing this forward. I know Trolltech is
working to help us along. The Accessibility workgroup is working
with Trolltech and the Gnome community to make sure future versions
of low level functionality will provide compatible means for helping
out with assitive technnology needs. This would be a great boost towards
getting a standard for a Linux Desktop moving ahead.
On Tue, Nov 09, 2004 at 12:07:07AM -0500, Scott Collins wrote:
> The following is a message I sent originally to Matt Taggart. I'm
> posting it to the list because I think it bears public discussion. The
> thread (linked below) that precipitated this has grown cold over the
> past year (before I even started work at Trolltech), but warrants
> effort to straighten out the misperceptions, and let the FSG and the
> LSB group know where Trolltech stands with Qt. When it comes to Linux
> on the desktop, we're all on the same team; we all stand to benefit by
> finding a way to work together.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> My name is Scott Collins. I'm an engineer by training; and I'm one of
> the principals behind Mozilla. I started work for Trolltech just this
> past year as an evangelist and liason to the Open Source community.
> The Open Source and Linux communities are fundamental concerns for me
> both in my personal life and on behalf of my employer.
> I see that you (plural, if not you specifically, Matt) are working to
> get Qt integrated into the LSB (or you are at least open to the idea of
> work happening that would allow Qt to get into the LSB ;-), but that,
> according to, e.g.,
> ...there is a perception that our license stands in your way.
> Everybody here at Trolltech thinks the LSB is an important effort, and
> that Qt really belongs in it, particularly in light of one noted LSB
> motivation: `to document currently accepted best practice'. Getting Qt
> into the LSB is good for both of us.
> I want to clear up any misconceptions and communicate four points:
> - our license strategy meets the LSB's requirements
> - we are very strong supporters of Linux development
> - our mission and goals are very compatible with those of the LSB
> - the LSB should include Qt
> I've read through the entire thread at
> There are some misunderstandings about our licensing in that thread
> that I think must be cleared-up before we can make any headway. I'll
> quote from that thread as appropriate.
> Doug Beattie writes:
> >I don't think he sees the point that even though the kernel folks
> >can legally use, without cost, the particular code they do, that
> >TrollTech does not allow commerical use of their code without
> >royalty fees being paid to them.
> Theodore Tso reiterates:
> >However, in the case of an ISV writing a commercial application,
> >they may not be able to distribute code linked with the Qt
> >license without first paying royalties. The requirement of
> >making an ISV pay large amounts of royalties to potentially
> >dozens of entities isthe reason for the LSB licensing criteria
> >which requires a no-cost license for use by commercial
> Trolltech does not charge royalties on Qt or Qt-based apps. No matter
> which license you use, you are free to ship as many copies of your
> Qt-based app as you wish. No Qt license requires any per-unit charges.
> No Qt license has any requirements whatsoever on (re)distributors of
> Qt-based apps.
> Theodore Tso continues:
> >I also don't think it's fair to make a group volunteers spend
> >time defining ABI's to a library which requires commercial
> >licensing, when all that would do is line the pockets of the
> >copyright holder (in this case, Trolltech).
> The two points I want to address here are (a) our libraries don't
> _require_ commercial licensing: they are alternatively available
> completely free of charge under the GPL, and (b) on top of that,
> further describing the situation as something that would `line our
> pockets' is loaded language. Getting Qt into the LSB is good for both
> of us, as I said earlier. Qt is good for the LSB as it supports your
> credibility in representing best practices, and provides additional
> depth in an area ISVs care most about. The LSB is good for Qt for very
> much the same reasons: credibility and depth, and demonstrating our
> commitment to the community. The LSB would not be a mechanism for
> `lining our pockets'.
> Theodore Tso continues:
> >On the other hand, if Trolltech were to join as a FSG member, and
> >provided the funding to define the ABI for its library, *AND*
> >there was a zero-cost functional alternative to Qt/KDE (i.e.
> >Gtk/GNOME) defined at the same time for use by commercial ISV's,
> >it might make sense for the LSB workgroup to make an exception to
> >its criteria.
> We're very interested in cooperating fully, including joining the Free
> Standards Group and funding work in the LSB. We ourselves provide a
> zero-cost alternative in our GPL'd distribution, but welcome the
> diversity in alternatives, e.g., Gtk/GNOME.
> Theodore Tso also writes:
> >Fundamentally, the LSB is not just for free software. Part of
> >the LSB's goal is to make it simpler for ISV's to write
> >commercial software that will run on Linux. If we don't give
> >them an easy way to do this, companies like Intuit and Delorme
> >will continue to only write commercial programs for Microsoft
> >Windows. And that would be a good thing to change. And
> >specifying the Qt works against this particular luadable goal.
> We are ourselves an ISV. It happens that we sell a development tool,
> and so among our customers are other ISVs. We sell our software much
> the way other ISVs do: per seat. In our case, one seat equals one
> developer. If you want a totally free solution, you can use Qt under
> the GPL and pay us nothing. If, as a commercial entity, you don't want
> to use GPL'd code, you can purchase Qt commercially and be completely
> free of the GPLs restrictions. Just as you would from other ISVs, you
> would purchase our software (including support) package per developer
> who would use it. If you have two developers writing your app: you buy
> two seats. End of story. Write as many apps as you want; ship as many
> units as you want.
> We are ourselves an ISV just like the ISVs the LSB wants to support and
> encourage. We're working hard to provide something of value to the
> community, and still be able to put bread on the table. We feel our
> `quid pro quo' license strategy is a reasonable way to do this. Though
> it does mean, on occasion, that there are misunderstandings we need to
> clear up to get everyone on the same page.
> Qt makes it easier to write high quality GUI applications on Linux. Our
> license is not an obstacle for developers, either free or commercial.
> That is a combination that is very much in line with the LSB's goals.
> Qt is among the top two toolkits preferred by commercial Linux ISVs,
> possibly the #1 choice. Thousands of commercial Linux apps have been
> built on Qt. We are a choice that encourages vendors to bring their
> Windows applications to Linux. We are a choice that significantly
> enhances the development experience on Linux. We have been players in
> the Linux community longer than almost any other ISV. One of our
> internal mission statements has always been to "Make programming fun."
> We bring that joy and ease to Linux development, and that is one of the
> things that brings commercial ISVs to the Linux table. To that end,
> your goals and ours are a perfect match.
> Expanding on our license, I'll address the LSB's License Criteria
> from <http://www.linuxbase.org/futures/criteria/index.html#license>
> >The component should have at least one compliant implementation
> >available under an Open Source license that also promotes a "No
> >Strings Attached" environment for developers. This means that the
> >developer would be able to develop and deploy their software
> >however they choose using at least one standard implementation.
> >This is interpreted to mean that at least one implementation is
> >available under a license that meets the Open Source Definition
> >but is does not prohibit propriatry usage. The rationale for this
> >criteria is very similar to that of the LGPL.
> Our licensing strategy perfectly fits this definition. We have a `no
> strings attached' solution where there are no further licensing
> restrictions on your code. We also have a zero-cost solution. Our
> GPL'd library is a standard part of almost all distros. So the
> developer can develop and deploy their software however they choose,
> using at least one standard implementation. Either way, no royalties,
> ever. In other words, we have at least one implementation available
> under an Open Source license, and we do not prohibit proprietary usage
> _exactly_ as your criteria require.
> Our license meets the LSB's standard. Trolltech and the LSB have
> strongly overlapping goals, particularly around fostering development
> on Linux, which we have long supported and encouraged. Adding Qt to
> the LSB is a win for both of us, and a natural reflection of industry
> best practice. The LSB should include Qt.
> What is the next step? Did I sufficiently clear up the misperceptions
> from that email thread to allow Qt into the LSB? If not... then let's
> start a dialog and get the right things to happen, both within
> Trolltech and the LSB. We want to make sure we really address the
> actual concerns of the LSB, and that we contribute to and support the
> LSB's effort, which we see as one of the fundamental building blocks in
> the bridge that takes Linux to the desktop. If the License Criteria as
> per your web page doesn't perfectly reflect what you are really looking
> for, that's knowledge that candidate libraries and vendors need to
> know; and as candidates for inclusion we'll want to understand
> perfectly so we can do the right thing.
> If I haven't yet convinced you that we're all on the same team and that
> Qt belongs in the LSB, or if there are misunderstandings on my part
> that need to be corrected, then let's find a time to meet in a higher
> bandwidth setting, e.g., phone or in person. I'm based in Ann Arbor,
> Michigan, but I travel constantly, and would be happy to meet in
> person. I'll do whatever needed to make sure the right thing happens.
> Thanks for taking the time to read this,
> Scott Collins, Evangelist
> Trolltech <http://www.trolltech.com/>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
> -----END PGP SIGNATURE-----
> lsb-discuss mailing list
> lsb-discuss at mail.freestandards.org
More information about the lsb-discuss