[Celinux-dev] eLinux Wiki Policy Page Draft

Tim Bird tim.bird at am.sony.com
Thu Nov 9 10:29:30 PST 2006


Bill Traynor wrote:
>> Here is some feedback on existing material:
>>
>> "Unlicensed content is any post to the wiki that does not either
>> explicitly
>>  (via declaration) or implicitly (through inheritance) carry a license
>> already."
>>
>> This is OK.  I'm a little unclear how inheritance is determined. For
>> patches
>> (mentioned later) I guess it is assumed to be obvious.  What about a
>> standalone C file?  How is it's inheritance determined?
> 
> My thought when writing the "inheritance" bit was specifically to
> address content that is not original to the wiki and already bears a
> license.  A standalone C file would either carry the license it's
> already under or default to the GPLv2.

What I'm specifically asking is "how"?  How is an "inherited" license
determined by a user of the site.  I expect two kinds of software on the site:
patches and standalone snippets and files.  Is it always obvious from a
patch what it patches, and what the license for that is?  (To answer my
own question, probably yes.  I can imagine counterexamples, but they would
be rare.  Is it, then, our policy that determination of the "inherited"
license for a patch is left as an exercise for the user?

For a snippet or standalone C file which is related to a larger project,
the situation gets a little worse, since there may not be in the code itself
any indication of the project to which it applies.

I guess in either of these cases, the result would be that with the ambiguity
we would assume the code to be GPL v2.  I suppose if our assumption is
clear (from our policy statement), and someone wants to avoid problems with
something NOT licensed GPLv2, then they all they have to do is appropriately label it.

How is such labeling done?  Do we have a guideline for that?  Do we need one?
Can a user put a license reference anywhere on the same page as a code snippet?
Or does it need to be close?, or adjacent?, or contextually inside the snippet?
If the code is in an attachment, does the license have to be in the code file
or can it reside on the page referencing the attachment?  (I would recommend
against separating the license from the code by very much.)

> 
>> -----------------------
>>
>> "Unlicensed content will default to one of the following licenses
>> depending
>> on it's nature:
>>     * The GNU Free Document License (GFDL) - This license applies to
>> all unlicensed
>>     content that is NOT code.
>>     * The GNU General Public License, Version 2 (GPLv2) - This license
>> will apply
>>     to all unlicensed code or code snippets."
>>
>> I think that Matt Mackall had a complaint about using GFDL for text,
>> since some
>> text might flow into code comments which might then be problematic to
>> re-incorporate
>> into GPL software.
>>
>> I thought Paul's last comment on this was a proposal to dual-license
>> unlabeled
>> stuff.  This is what I prefer.  That is: "The license for material
>> that is not explicitly
>> license-labeled is "GFDL or GPL v2".  We should declare as part of the
>> policy how
>> to label the license of something in the wiki.
> 
> I thought that the statements above for unlicensed content cover this.
> That is, the textual portion would be GFDL and the code portion,
> GPLv2.

Matt Mackall raised an objection to using GFDL for text.  That's
why I'm proposing something different.  Not "GFDL" for text and "GPLv2" for
code, but "GFDL or GPLv2" for both text and code.

That way, someone can extract material from the site (whether text or
code) and move it to either Wikipedia (by selecting GFDL from the choices
in the dual license) or to, say, the kernel (by selecting GPLv2 from
the choices in the dual license).  Stuff can't move back the other way,
but I don't care too much about that.  Any there's a mechanisms (explicit
labeling) to handle those cases (which I expect to be rare).

Anyone have objections to this?
 -- Tim

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================


More information about the Celinux-dev mailing list