www/ Software/ LicenseStrawman

Strawman X.Org Foundation License Policy

Current Status

The following was initially written down 9/20/2004; it is considered a strawman policy, and your input and opinions are solicited on the mailing list. It cannot yet be considered full consensus of the community. The policy to date can be characterized as "first, do no harm", but the previous inflexibility has also had serious costs.

The X.Org Foundation board believes its role is to try help the community generate a policy with full feedback from the membership.

Also note that with the intention of modularizing the distribution, new parts of the system may in the future be available under different terms than has been true under the past.

This strawman a policy was generated by Jim Gettys, however, to help get the discussion going, who stated this position informally in a number of forums and has had encouraging feedback, but as there has not been public review and comment and it has not been written down and accepted, it must be regarded as a strawman.

Strawman policy on X.org licensing

Preamble

Many people, organizations and companies, have contributed to the corpus of code distributed by X.org, which has been built over 20 years. An implicit unwritten understanding of their contributions to the X Window System code base has been that the code would remain available to them under the same terms that it was made available to the community into the future, though, in fact, there has been no legal terms in the licenses used in X code to enforce this. Violating this trust would be to the long term detriment of X.org, the contributors and organizations that have funded X development.

The current body of code is primarily under the "MIT License", which is considered fully acceptable software by the entire community, whether they call themselves open source or free.(*) A description of what it means to be free software may have best been stated by the Debian project, in the Debian Free Software Guidelines. Certainly licenses that qualify by these guidelines are the only licenses the full community finds acceptable.

Detailed Consequences

  1. Adding more restrictive copyrights on modifications to existing code bases is not allowed.  For example, if a patch or file is added to a library, it may not have copyrights any more restrictive than that of the module which it is a part of, and the usual expectation will be that it be the MIT license or the license used by that module. The most complicated situations come up as software is "aggregated" into larger programs or systems. 
  1. Interactions among copyrights easily become very complicated, and in fact, contradictions among licenses can occur that prevent aggregates being distributed at all. _Compatibility_ between common licenses is a real issue we must continue to be sensitive to, and licenses cannot be arbitrarily mixed in a system as a result. The consequences of a new module that becomes part of a larger program (e.g. a graphics driver in the X server) must be very carefully analyzed before they can be accepted (there can be situations that would make it illegal for the aggregate to be shipped), or it could be that previous contributors contributions might become effectively useless to them, violating the implicit trust given by previous contributors that the terms would not change in the future. 
  1. Similarly, requiring a new dependency on a module may present serious issues.  An example might be the required dependency on a GPL only library (note GPL rather than LGPL) for which there is no BSD/MIT licensed equivalent that is required generally for the software to  be useful, which might disenfranchise those who may be unwilling to accept such libraries on other platforms. Note that dependencies that are specific to a single platform might or might not generate problems of this class, depending upon the precise circumstances. Note that during the recent Cairo licensing discussion that even the LGPL by itself could be problematic, due to concerns of use in embedded systems, in which X has been and continues to be used.  Further understanding of the issues raised during that  discussion are needed to understand if those concerns are valid, even though a solution for that particular situation has been found. 
  1. Consequences 2) and 3) argue toward simplicity of licensing; X.org desires to keep the overall aggregate licensing simple and may discourage/forbid the use of licenses that complicate licensing or make aggregate programs or systems difficult or impossible. The board of directors will decide on whether a license not already in use in the module or program in the system is allowed after full public discussion, if consensus during that discussion is not reached. 
  1. new contributions under other DFSG compliant licenses will be considered, so long as conditions 1-4 are met.

(*) there are currently some exceptions to this situation, e.g. GLX, the B&H Luxi fonts; we (the board) are as time permits attempting to see if we can get these modules relicensed more appropriately.

-- Main.?JimGettys - 23 Sep 2004