[Celinux-dev] Re: Policy Document (for embedded wiki)

[Matt Mackall]

On Fri, Oct 13, 2006 at 02:10:46PM -0700, Tim Bird wrote:
> Matt Mackall wrote:
> > I think GFDL is a bad choice of license, especially in the field of
> > kernel development.
> > 
> > a) it's not GPL compatible (in either direction!)
> > 
> I don't agree, but if it's going to cause problems
> with contribution, it could be an issue.

Any additional restriction beyond what the GPL specifies makes things
incompatible because it prohibits additional restrictions. The GFDL's
so-called anti-DRM provision is one such restriction, the transparent copy
provision is another, optional invariant sections are another.

Which means you can't incorporate GPLed content into GFDLed (adding a
restriction) or GFDLed content into GPLed (removing a restriction)
beyond what "fair use" allows.

> > b) the GFDL's advantages for our purposes aren't obvious
> > 
> >   The protections it gives beyond what the GPL gives are mainly aimed
> >   at printed works where authorship is a valuable asset (see invariant
> >   sections), but authorship on wikis is a fairly nebulous concept.
> I agree.

I'd like to see a rationale for using the GFDL. I don't know of any
aside from "Wikipedia does".

> > c) it's not even clear that it qualifies as a free license!
> > 
> >   This has been hotly debated in several circles, most notably Debian-legal:
> > 
> >   http://people.debian.org/~srivasta/Position_Statement.xhtml
> 
> The analysis in the position statement is seriously flawed.
> It takes the requirements for Invariant sections and applies
> them to the entire text. If you have no invariant sections,
> as I expect for a wiki, then most of the objections have no
> basis.

For Debian's purposes, invariant sections are relevant. Most of the
FSF's docs have them.

> Please note that I would prefer not to rehash the entire GFDL
> debate.  I disagree with the Debian-legal conclusions.

My point is that it's hotly debated, by lawyers and laypeople alike.
We can avoid this rather large and muddy gray area trivially by
avoiding the GFDL entirely.

> > Further, compatibility with Wikipedia is not terribly important (we
> > can always link), while ability to mix with the kernel source and
> > kernel documentation is fairly critical. Which means using the GPL
> > (v2!).
> 
> My proposal for the license policy is:
>  * text - GFDL
>  * standalone code with no license mentioned - GPL2
>  * standalone code with a license mentioned - must be under an OSI-approved license
>  * patches - licensed same as software to which they apply
> 
> Note that the wiki is not SourceForge, so theoretically we could punt on
> the code issues, and have them hosted somewhere else.  (It's not like there's
> a shortage of places on the Internet to host code - the CELF wiki could be used
> for otherwise homeless code and patches.)  I think it's much more likely
> that text will move between the embedded linux wiki and Wikipedia than
> between the embedded linux wiki and the kernel sources.

I'm primarily concerned with the ability to quote non-trivial portions
of code or text in the text of the wiki. 

For example, let's say I wanted to put up a page on doing GPIO. It's
going to be different on every platform, so I'm going to take the
simple driver I found in arch/arm, quote pretty much the entire thing
(well beyond "fair use"), and then annotate it, explaining how to
adapt it to another platform. As I go, I want to quote API bits from
Documentation/ to an extent that may or may not be fair use.

The right way to do this sort of thing is not obvious if "text" is
GFDL and "code" is GPL. The whole page is clearly a derived work, as
the "text" part can't stand alone. Is the rest of the wiki a derived
work? Maybe, maybe not.

With just the GPL, there's no problem.

> Anyone care to comment on the pros and cons of making the general
> text GPL2?  The files in <linux>/Documentation are GPL2, no?

Yes, they are.

-- 
Mathematics is the supreme nostalgia of our time.