The Linux Foundation

 
LicenseCriteria

From The Linux Foundation

Contents

LSB License Criteria

There has recently been much discussion on the license criteria used by the LSB Futures subgroup (see [1]), sparked mainly by the failure of Qt to meet these critera when under consideration by the LSB Desktop subgroup.

This page is intended to provide a place where we can work on editing a new version of the criteria, originally proposed by Scott Collins of Trolltech. This new version allows for dual license products, such as Qt, to meet the criteria, while still protecting the Open Source no-strings-attached concepts previously in place.

Please feel free to add [wiki:LicenseCriteria/Comments Comments] or to edit the text directly.


Suggested Text

The following suggested text is proposed for the case where LSB will consider ABI with GPL licensed implementations.

Licensing

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.

LSB will relax the above mentioned restriction around proprietary usage for components:

  1. satisfying the rest of selection criteria AND
2. when standardization of such component maintains LSB's promise of even handedness in implementing free and non-free software requiring the functionality offered by the component. This means that, the LSB will need to include another component (set of ABI) providing similar functionality with at least one implementation allowing proprietary usage.

Suggested Text

The following suggested text is proposed for the case where we might consider GPL software because a balanced pair of "Best Practice" alternatives together satisfy all the goals ofthe LSB.

Licensing

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 does not prohibit propriatry usage. The rationale for this criteria is very similar to that of the LGPL.

On occassion, two competing components will achieve a balance such that only as simultaneous alternatives can they be considered "Best Practice". In such a case, as long as both meet all other criteria, and as long as one meets the License Criteria above, thus ensuring a "No Strings Attached" environment, a license for the second meeting the Open Source Definition but with restrictions that might otherwise preclude it from the LSB can be considered.


The following suggested text was proposed where we were considering allowing dual-licensed software, where together the licenses might satisfy all the goals of the LSB.

Licensing

The LSB describes a set of Application Binary Interfaces (ABIs), each formalized by a complete set of stub[note 1] headers, stub libraries, a suite of tests, and documentation (hereafter, ABI materials). A component implementation that matches the stubs, passes the tests, and agrees with the documentation conforms to that ABI. It is the ABI itself that is the LSB's promise to developers. Where more than one conforming implementation is available, a developer or a distribution is free to choose.

The LSB defines the ABI, not any particular conforming implementation. However, a deployed work built upon that ABI will necessarily run as a combined work with some conforming component implementation. Therefore, the license for that component may impact the rights of the developer, distributor, or user of that work. Moreover, while the ABI materials are sufficient to compile and link, they are not sufficient to execute a compiled work, and so the activities of developing and testing typically require an actual component implementation. To become a part of the LSB, there must exist a both a formal ABI (as defined above) and one or more conforming component implementations.

In the case of the documentation materials that formally describe the ABI, if they are produced and published externally to the LSB project, they must conform to certain rules. Since the LSB is an ISO standard, any external reference should follow the guidelines in Annex N of the ISO JTC 1 directives (currently under review, new proposed text attached at attachment:annex-n.pdf). If the reference materials are not from a source recognised as a valid standards development organisation by ISO, then it must be possible for them to be licensed to the Free Standards Group (FSG) for inclusion in the LSB specification documents, which are licensed under the GNU FDL.

The LSB seeks to ensure that the developer's on-going rights and ability to build both proprietary and Open Source code using an ABI, and to expect that ABI to be satisfied at run-time, can never be endangered by any actions of the ABI's original developer, nor require on-going payments to maintain; and that the LSB itself remains a no-cost and reliable standard for both developers and distributors. The following license requirements are intended to safeguard these rights, abilities, and goals.


Licensing requirements for the ABI materials

  1. The ABI materials must be offered under a perpetual, no-cost license. Additionally, the license for the test suite must meet the Open Source Definition (and therefore be a source license).
2. The license for the ABI materials must place no restrictions, obligations, or costs on the end-users of those materials, i.e., developers `coding to the LSB'. In particular, this means that a developer writing code to use an ABI from the LSB cannot be charged merely for the privilege of using the ABI materials.[note 2]
3. The license for the stub headers must place no restrictions, obligations, or costs, on works derived from the stub headers. The license must allow any third party working only[note 3] from the ABI materials to create a conforming component implementation, without any obligation to the original developer.

Licensing requirements for components

One or more conforming component implementations must be available, under one or more licenses such that singly, or in combination, those licenses support both proprietary and Open Source development upon that ABI:

  1. At least one conforming component/license must support the development of proprietary software by offering a perpetual, royalty-free, source license that places no restrictions on the developer's rights to deploy (or not) their own source code or the compiled whole (i.e., "no strings attached"[note 4]).
2. At least one conforming component/license must support the development of Free and Open Source software by offering a perpetual, no-cost (no purchase costs, no royalty costs, i.e., "'free' as in 'free beer'"), source license that meets the Open Source Definition.

If a single component and license can satisfy both these requirements, so much the better, but both requirements must be met.

These licensing requirements are intended to guarantee that neither distributions nor developers are beholden to the original developer. A component developer cannot rescind an ABI, and they provide both the rights and sufficient material to allow alternative implementations, thus guaranteeing a conforming component at run-time.


Notes

The first paragraph specifically addresses Matt Taggart's comments from the Wednesday phone meeting: highlighting the fact that the LSB is about ABIs, and multiple implementations are possible (and even desirable).

The second paragraph explains why there are two different pieces to think about (the ABI materials, and conforming component implementations), and why the licenses for these pieces matter.

The third paragraph explains the special requirements on the specification part of the ABI.

The fourth paragraph explains goals of the LSB that can be approached by choosing appropriate licenses for these pieces.

The closing paragraph, below the two sets of requirements, summarizes the intent of the requirements.


[1] Stub means "sufficient to compile or link a work referencing that ABI, though not necessarily sufficient to execute it".

[2] This clause can't be taken to mean that there must be no restrictions, only that there must be no restrictions consequential to the use of the ABI materials. This clause doesn't address any restrictions, requirements, or obligations consequential to using works outside the scope of the ABI materials, e.g., a component implementation.

[3] Think 'clean room'. Building an alternative conforming implementation using only the stub headers and tests for guidance _must_ be allowed. This clause does not address the implications of also using source or knowledge gained from an existing conforming implementation.

[4] "Almost no strings attached." On occasion, licenses with reasonable restrictions may be considered, e.g., a number of ABIs in the LSB have conforming component implementations licensed under the LGPL. The LGPL has requirements of which you must be aware if you intend to ship a proprietary work. In particular, you cannot ship your work with an End-User License Agreement (EULA) that forbids reverse engineering. The LSB intends to make development easier, but you must still invest effort to ensure you understand the licenses of the components you select.


To add comments to this page, click on [wiki:LicenseCriteria/Comments User Comments] and select edit.


[[Include(LicenseCriteria/Comments)]]


[Article] [Discussion] [View source] [History]