[lsb-discuss] The LSB and Qt

Scott Collins scc at trolltech.com
Mon Nov 8 21:07:07 PST 2004


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.

Cheers,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy,

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

    <http://www.linuxbase.org/futures/candidates/Qt/index.html#license>

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

<http://mail.freestandards.org/pipermail/lsb-discuss/2003-November/001
851.html>

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

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>

> 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

iQA/AwUBQYEsTcN8VLjezbXrEQLk2ACglk1MnxCkVsRfMwIctkJRwiHjKoUAoKyI
nqSmnEuFGANj1yXAK+A/XAfV
=MjMt
-----END PGP SIGNATURE-----





More information about the lsb-discuss mailing list