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

[Jim Gettys]

Note that the LGPL also has problems for specs: say I'm writing code to
an MIT license; should I not be able to cut and paste quotes from a
standards document to explain my code?

I suspect that free specification licenses need to be non-infectious as
they represent interoperability points between systems.
				- Jim


On Wed, 2005-09-28 at 09:31 -0400, Jim Gettys wrote:
> There is another problem with the GFDL is the invariant clause that the
> Debian document you provided a link to misses entirely:
> 
> The invariant clause can make documentation and/or a specification
> useless in the case of a fork in the code (without rewriting the
> documentation from scratch), due to bad interactions with trademark law.
> 
> Say invariant sections surround uses of a trademark, and these sections
> represent key or large parts of the document; if the code and/or
> specification needs to be forked (as happens occasionally, for good or
> bad reasons), you may not be able to eliminate the possible confusing
> use of the trademark, and therefore be in violation of Trademark law.
> You could be taken to court over this one...
> 
> At times the documentation/specification may represent a good fraction
> of the total effort in a system.  I remember spending many months
> working on Xlib documentation/specification in the '80's and early
> '90's; the code as written at that date was a few man years, so the
> documentation/specification was 10's of percent of the total effort; if
> you throw in the tech writer's time on top of my time, it may have been
> as much as 40%.
> 
> So for all the reasons outlined by Debian in the link you provide below,
> and the reason outlined above, the GFDL is useless, and subtly so in
> ways that can be pernicious and not obvious on first examination (which
> is how it came to be, and why Debian to struggled over it). The freedom
> to fork code for your own purposes is a sometimes forgotten, but
> essential freedom; losing all the work in the documentation and
> specifications can be a *major* compromise of that freedom, whether you
> come down on the free or open source side of the fence.  This problem
> only occurred to me as we were cleaning up the use of trademarks in the
> XFree86/X.org fork in the documentation.
> 
> It isn't clear I've seen a copyright I like for formal specifications
> for free/open source software, though I suspect we could generate one;
> IIRC the IETF has copyrights that might be a starting point.  The issue
> I see pretty unique to specifications is ensuring that the spec not be
> claimed to be the specification unless it really *is* the agreed to
> specification of the organization blessing the spec.  In some cases, the
> specification also serves as the documentation for code (and vice
> versa); in other cases, it is an original work unto itself being
> implemented by multiple code bases.
> 
> I'll ping Eben Moglen on this one, along with Michael Tiemann.  It is a
> point of law that I think hasn't seen enough thought in open source/free
> software, and one that will be increasingly common as we "grow up" and
> have more and more formal specifications for our important systems and
> protocols.  It would be good if the SFLC and OSI could tackle this issue
> and come up with a single good copyright for documentation and
> specifications, and avoid lots of copyright proliferation, and the
> resulting headaches of bad interactions between these copyrights and the
> copyrights used on the code itself.
> 				- Jim
> 
> 
> On Wed, 2005-09-28 at 13:52 +0200, Philip Van Hoof wrote:
> > On Tue, 2005-09-27 at 19:41 +0200, Philip Van Hoof wrote:
> > 
> > > I'm guessing the LGPL license or the GNU Free Documentation License are
> > > interesting ones.
> > 
> > One person (in private) expressed his doubt about the GNU Free
> > Documentation License. Mainly because Debian doesn't like this one:
> > 
> > http://people.debian.org/~srivasta/Position_Statement.html
> > 
> > Other opinions?
> > 
>