One candidate has generated more discussion by far than all others, libqt. It is the consensus of the LSB futures subcommittee that it does not meet the LSB candidate selection criteria. Many of the discussions around this issue tend to be repeated on the mailing lists. This document attempts to record the Frequent Asked Questions and various arguments around this issue. If you don't see something here and can't find it in the mailing list archives, please bring it up on the lsb-futures mailing list.
libqt has always been considered a candidate for the LSB. It was first added to our tracking system on April 15, 2002 (roughly the same time as gtk).
The LSB Selection Criteria is a set of guidelines developed for the LSB project in order to have a consistent, fair, non-arbitrary set of metrics for determining if an interface was appropriate for adding to the LSB. It was developed in response to mistakes the project had made, criticism of being too closed, and overall confusion (inside the project as well) of how we make decisions. Most of it was developed after the LSB 1.0 release when the project had a chance to reflect on how the release went. There have been some additions and adjustments since it has been developed.
When the criteria are being evaluated, what's under consideration is the canonical implementation of the interface. If multiple implementations exist they can each be evaluated and in some cases be evaluated together as a way of fulfilling the criteria. This is to ensure that at least one implementation is available for runtime implementors to use that meets the criteria.
libqt is currently considered to not meet the LSB license criteria. The license criteria was first proposed November 11, 2002 and adopted on January 7, 2003. libqt's requirement that developers purchase a license in order to develop applications that use libqt is considered to violate the "no strings attached" requirement of the license criteria. Specific questions and arguments are addressed below.
This issue of libqt has been discussed on the lsb-futures, lsb-discuss, and other mailing lists over the last 4 years.
In a message to the lsb-futures mailing list, Ted Ts'o explains...
"While payment to one such company might be acceptable, over time, if we allowed this to stand, there could potentially be dozens of company that need to be made happy before a commercial application could be developed under Linux. This would be a Very Bad Thing.
The LSB benefits both commercial, shareware, and free software; however, it is less of a benefit if it were to include royalty bearing IP. This boundless cost is prohibitive for all...
No. Applications are allowed to use whatever interfaces they like, but if those interfaces are not in the LSB they can't assume that they will be present at runtime on an LSB compliant system. So to be LSB compliant they are responsible for providing any external dependencies, for example by linking statically or by providing their own shared copy of the interfaces they require.
No. As described above it just means they can't assume the libqt interfaces will be present on an LSB runtime environment.
The LSB only selects interfaces that have emerged as a best practice for the particular problem they are designed to solve. The LSB futures subcommittee decided that gtk and libqt, while very similar, address slightly different problems and audiences, enough so that we are willing to consider each separately and if they can each meet the LSB criteria they can each be added. We're not aware of any objection to this approach.
The Linux kernel has their own license criteria and the LSB Workgroup has no control over that. It's really up to them to decide, and for the most part doesn't affect the LSB since it doesn't specify kernel interfaces.
It is not in dispute that Qt meets the Open Source definition and can safely be used by Open Source projects. The LSB license criteria is different than the OSI license criteria, for reasons described in this document. The LSB should be freely used by all, including non-Open-Source projects.
This helps libqt meet the best practice criteria. It doesn't affect the licensing criteria.
This helps libqt meet the demand criteria. It doesn't affect the licensing criteria.
This helps libqt meet the stable ABI/API and upstream cooperative criteria. It doesn't affect the licensing criteria.
RAND clauses have been widely rejected for use in Free Standards. There was a large controversy when the idea was proposed in the W3C standards group, resulting in this policy.
The LSB selection criteria rules are designed to produce a standard that allows for maximum possible participation and increase the use of Free Software. We are not playing favorites, any interface that meets these criteria can be added to the LSB, including libqt.
Other candidates are blocked due to license criteria, for example Berkeley Database.
In addition to the things mentioned above, we can expect that someone would start a competing standard to the LSB that didn't include a RAND clause. The competing standard would be usable by more developers, and everyone would follow it instead thus making the LSB obsolete. The same thing would happen if we decided to add things that prevented a free software implementation. To address the largest audience possible we need to be as inclusive as possible.
Yes, but as long as it does not meet our license criteria it is not within the charter of the Free Standards Group to develop. We encourage those who would benefit from such a standard to create one and we would like to see it exist as a layer on top of the LSB and would be willing to work on any changes needed to the LSB in order to make that happen.
The LSB is a development standard, it's intended audience is developer and not users directly. The "no strings attached" idea in the license criteria is no strings attached for the developer both for deployment and development.
The difference in the two cases is between making a product available in an LSB compliant manner versus adding interfaces to the LSB itself. Trolltech (or anyone else willing to follow their implementation's GPL license) is able to create an LSB compliant version of libqt for people using libqt who want to make their application LSB compliant.
Perhaps. Currently the Harmony project has been abandoned for quite a while and doesn't implement the full interfaces that libqt developers are using today.
While this might prevent reverting of the current situation in the future(or might even improve it), it does nothing for the current problem that developers are required to purchase licenses. So it's not relevant to the license discussion, unless the release clause is actually invoked.
It is unclear if interfaces determined in this way can be placed under a different license. Some the other projects have attempted something similar in the past have faced lawsuits.