Copyright of the desktop configuration specification (careful, here be dragons)

C. Gatzemeier c.gatzemeier at
Tue Oct 4 20:03:10 EEST 2005

Hi all,

IANAL, I understand the GFDL has controversal issues
but also see some uses for carefuly applied invariant sections that should not 
prevent forking, like the list of conributors, or see below.

And isn't verbatim quoting a different matter, not subject to the explicit 
licence? Is quoting the spec-doc in other documents or source comments an 

The copyright conclusions I drew for now:

For standards the copyright of the specification document, of the reference 
implementation, and any usage restrictions of the spec (patents) are all 
different decisions:

I would guess you don't want to restrict the use of your spec by claiming 
patents. (Others may be able to claim some anyway as long as patents are not 
considered illegal.)

A free standard should include a free reference implementation.

The question is if the effort should be a give-away for plunder.
By choosing that the reference implementation not only is free, but also stays 
free (copyleft), it could contribute to and be part of comunity efforts, and, 
at the same time, serve as a reference for proprietary "software products".

This way proprietary and free business models compete on their own terms, with 
the advantage to the propritary software vendor with open access to specs and 
reference source code without a price tag for artificial scarcity.

For the specification document though, you don't need nor want to put it in 
the public domain just yet. You do not want to grant a oportunity to have the 
standard picked up, made proprietary, buffed up with some obscure patented 
extensions, etc. that easily.
Share the copyright with those that respect the same.
Allow the freedom to code their own or to collaborate to all. Deny enclosing 
for all.

Copyleft immunizes your work, and the work from those that chose to 
collaborated work. It does not infect others. It gives you you the same  
handle when you encounter ungranted uses like enclosing your work, that 
proprietray vendors use to ensure their artifical monopoly to distribute 
their software.

With the LGPL you prepare your work to also be a free meal proprietary 
software vendors/competitors can have as lunch. This may make sense in some 
circumstances, i.e. to gain momentum where proprietary solutions are already 
wide spread and/or available low priced, or in cases like libc.

For most projects and new specs though, the GPL seems a sound choice:

Consider a GFDL spec document that invariantly points to a GPLed 
reference implementation.

Everybody is allowed to check out the docs and code reference.

Any distributed enhancement to the published spec has to be submitted again to 
change the official spec. 
And the enhancement will need to be available in the free reference 
implementation to realy resemble the spec.

Free projects can link the reference implementation. Proprietary software 
vendors would actually need to write their proprietary code themselves, with 
freebe reference though. By implementing proprietary extensions it is not 
possible to change the official spec nor to officially use official 

A LGPL reference would allow proprietary vendors to advertise using the 
official reference and at the same time introduce incompatible proprietary 

With an official GPL reference, proprietary software can to claim to adhere to 
the open and free spec-document, change it... decently free of course, or 
start from scratch and enclose it from scratch, just as everybody else. :)


More information about the xdg mailing list