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

[Peter Hutterer]

On Wed, 29 Dec 2010 14:32:10 -0800, Alan Coopersmith <alan.coopersmith at oracle.com> wrote:
> 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.

sounds good to me. one thing missing, though obvious, is that a module
should be related to and of benefit to the X.Org core components. an
xfart application, while potentially hilarious to some, seems somewhat
misplaced, and so would random desktop applications that have little to
do with X itself.

Other than that, I'd be happy to take the above as a guideline. Want to
pop that on the wiki somewhere?

Cheers,
  Peter