What's an X.Org module? What license can it have? (was: [PATCH util/modular] build.sh: add xrestop)

[Alan Coopersmith]

On 12/29/10 09:47 AM, Daniel Stone wrote:
> On Wed, Dec 29, 2010 at 12:21:38PM -0500, Gaetan Nadon wrote:
>> I am still puzzled as to what "belongs" to X.Org or not. Or even if this
>> concept applies.
> 
> Well, there's a bit of a disconnect between what we have in git, and
> what we ship in the katamari.  The katamari is MIT/BSD-only, but some of
> the git modules have been less permissive: xf86-input-synaptics used to
> be GPL, xrestop, et al.  xf86-input-wacom is GPL as well, and is
> currently not hosted in /git/xorg, but I expect it will at some stage.
> 
> Personally, I don't see the harm in allowing new GPL modules, given that
> vendors can pick and choose what they want to distribute, but it's such
> an emotive and time-worn fight that I'm not sure it's worth the
> argument.

We do really need to write this down at some point, since "ask the old-timers
to explain" doesn't scale very well for bringing new developers on board.

The license document we currently have was written in the days of the monolith,
when things were simpler, it was either in the monolith or not.   The Consortium
had contrib tarballs, but that was just a ftp directory for downloads, not
hosted development resources.

If I had to write down what I think the rules should be, I'd start with:

X.Org hosted development:
  - git repos under the freedesktop.org/xorg/ hierarchy
    with write access granted to all committers in the xorg group on fd.o
  - tarballs posted under www.x.org/archives
  - xorg-docs/MAINTAINERS must list the module, along with:
	- address to send patches for review (normally xorg-devel)
	- any restrictions on direct pushes to the git repo
	  (such as "Only the maintainer pushes to master" on xorg-server
	   and xf86-video-vmware)
  - Must be licensed under a license approved by the X.Org Board, with the
	initial set being all the licenses currently in one of the modules
	hosted by X.Org, including MIT & BSD, plus GPL/LGPL (v2 or v3).
	The Board is only likely to approve new licenses that are OSI-approved
	and DFSG-compliant, and take a dim view of further license
	proliferation, especially of further customized forms of the MIT
	license.
  - No substantial changes to licenses of existing modules without approval.
	(i.e. moving from customized MIT to standardized MIT is fine, or
	 from 4 clause BSD to 2 clause BSD, but MIT -> GPL is not)
  - Should meet the (still evolving) X.Org build configuration standards,
	to simplify life for people building all the modules.
  - Should be a low barrier to entry - perhaps just an Ack from at least one
	active developer, and no serious objections/nacks.

X.Org katamari:
  - the subset of X.Org hosted modules that form the core window system and
	get rolled up into annual releases
  - Must be licensed under a "permissive" license, preferably the X.Org
	preferred format of MIT License from xserver/COPYING or
	http://www.x.org/releases/X11R7.6/doc/xorg-docs/License.html#id2521948
  - higher barrier to entry, since X.Org is committing to maintain these
	over a longer term (but not forever, as modules can be dropped too)
  - current exceptions:
	openchrome driver (not hosted on fd.o - is it still alive?  developer
	 list seems dead - just one ping since April, no release in over a year)
	xcb modules (hosted separately on fd.o)

Submitting new modules for X.Org hosting shouldn't be done to get some sort of
"blessing" or status that this is somehow a better or more important module
because it's an X.Org module.  It's sharing the maintenance burden with a wider
community, and allowing them to help with things like getting your configure.ac
working on more platforms or making sure your driver is updated for server ABI
changes, and providing for the possibility of ongoing maintenance for the module
after you're done working on it.   However, there is no guarantee of
widespread adoption, and if few people are using it, it's likely no one will
step up to continue to maintain it, and the repo will be left to rot.

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System