[Celinux-dev] eLinux Wiki Policy Page Draft

Fri Nov 10 21:24:11 PST 2006

I think it's really important that the policy page (and maybe other
places) make it clear that the poster is responsible for matching the
licenses on any quoted/derivative material - that the wiki sponsor(s)
are not responsible for verifying that the poster has the right to post
it.

scott

| From celinux-dev-bounces at tree.celinuxforum.org Fri Nov 10 10:33:16 2006
| Date: Fri, 10 Nov 2006 11:17:15 -0500
| From: "Bill Traynor"<btraynor at gmail.com>
| Cc: <celinux-dev at tree.celinuxforum.org>
| Precedence: list
| 
| On 11/9/06, Tim Bird <tim.bird at am.sony.com> wrote:
| > 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?
| 
| Yes, I would think so.  Otherwise, we're looking at a situation where
| we need to validate the license chosen by a user when applicable to
| new content.  I think we can and should validate, but only when
| license disputes arise, which hopefully will be never.
| 
| >
| > 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.
| 
| Yes, I agree.
| 
| >
| > How is such labeling done?
| 
| Not sure yet, although at first thought, I'd presume if would have to
| be done simply by an author declaring it textually in the relavant
| page.  Perhaps this is a function that could be added to Mediawiki
| some day by us.  Perhaps a button that provides a choice of license.
| 
| > Do we have a guideline for that?  Do we need one?
| 
| Not yet, but I think we do, as it answers the How question.
| 
| > Can a user put a license reference anywhere on the same page as a code snippet?
| 
| They can, however, I'm not sure how this will work yet.
| 
| > 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.)
| 
| I agree that separating the license from the code is bad in this case.
| 
| All great questions and feedback, thanks. As I begin to document the
| policies & guidelines, I'm finding I'm asking myself the how, why,
| when, what questions more and more.  I'm looking to the Wikipedia
| examples for guidance.  But I fear that our Policies & Guidelines may
| be larger than anticipated.  I was shooting for brevity with the
| initial cut, but that typically raises more questions than it answer.
| 
| Any word from Sampo on either getting control of the server at Movial
| or whether Movial has made the Mediawiki changes I asked for, such as
| File Upload, and Interwiki linking?
| 
| Bill
| 
| >
| > >
| > >> -----------------------
| > >>
| > >> "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
| > =============================
| > _______________________________________________
| > Celinux-dev mailing list
| > Celinux-dev at tree.celinuxforum.org
| > http://tree.celinuxforum.org/mailman/listinfo/celinux-dev
| >
| _______________________________________________
| Celinux-dev mailing list
| Celinux-dev at tree.celinuxforum.org
| http://tree.celinuxforum.org/mailman/listinfo/celinux-dev
| 

-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece at motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114 at vtext.com