Strawman licensing policy (was: DRM radeon i2c support and GPL)

[Jim Gettys]

Keith,

We haven't managed to write such a policy down yet, and demonstrate full
consensus of the community.  So far, I'd describe the policy today as
"first, do no harm".

It is certainly on the board's radar screen 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.

I'll take a crack at enunciating a policy now, however, to help
get the discussion going.  I've stated this position informally
in a number of forums and have 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
        ==================================
		Jim Gettys
	   9/20/2004 version .1

		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
(which can be found at: http://www.debian.org/social_contract).
Certainly licenses that qualify by these guidelines are the
only licenses the full community finds acceptable.

		Detailed Consequences
		---------------------

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

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

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

d) consequences b) and c) 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.

e) new contributions under other DFSG compliant licenses will
be considered, so long as conditions a-d are met. 

I hope this strawman starts a productive discussion.
			Regards,
				Jim Gettys

(*) 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.



> The issue with GPL and drm is as I have stated several times now that we've 
> wanted XFree, and now Xorg, to be able to distribute this code as part of 
> their tree.
> 
> XFree86 had a strong policy against allowing GPL into their tree, I don't know 
> what Xorg's stand is.  Maybe someone can comment from there?
> 
> Keith
> 
> 
> _______________________________________________
> xorg mailing list
> xorg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xor