Re: changing content licenses (OPL => CC BY SA)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2009-06-25 at 22:22 -0700, Karsten Wade wrote:
> On Thu, Jun 25, 2009 at 06:54:18PM -0400, Eric Christensen wrote:
> > On Thu, 2009-06-25 at 18:48 -0400, Tom "spot" Callaway wrote:
> > > On 06/25/2009 03:22 PM, Karsten Wade wrote:
> > > > When we went from GFDL to OPL we specifically had to ask everyone
> > > > because none of the content works were under the Fedora CLA.  The
> > > > stated reasoning at the time iirc was, we wouldn't have to do this
> > > > check with everyone again if we had to relicense because we had the
> > > > CLA.
> > > 
> > > I think the important distinction that I missed was that I thought you
> > > were only referring to the reference documentation in the separate files
> > > (e.g. Release Guide), where there are well defined lists of the
> > > contributors. For the wiki, that task is far too major and we would
> > > definitely want to leverage the CLA to relicense that content.
> > > 
> > 
> > There is still a problem, though.  Most, if not all, of our guides start
> > on the wiki.  I know a lot of information that went into the Security
> > Guide came from the wiki and thus from various developers.
> 
> Aye, there's the rub.  I think only the Installation Guide doesn't
> have wiki sourcing in it.
> 
> One difference going in to the future is that we have worked on having
> improved editing via the Docs CMS (Zikula), and I can foresee Docs
> moving most of this editing to the improved wysiwyg environment in
> Zikula.  We could enact a different type of contribution policy for
> the Docs CMS than for the wiki, although I think we'd want to focus on
> keeping the barriers the same (i.e., no CLA per-se for the relnotes
> writing part of the CMS with a deeper reaching policy?)
> 
> Perhaps we have a funnel+filter approach like this for any guide
> written on the wiki, from Release Notes to User Guide.  Let's take the
> release notes beats as a use case:
> 
> * Consider a new namespace ([[Relnote:]]?) if that helps us sequester
>   that content better.
> 
> * Make it clear that editing the relnotes on the wiki beyond a certain
>   level may require a contribution agreement.
> 
> * Minor edits and additions that are not copyrightable are considered
>   safe for conversion from wiki to CLA-covered guides in an SCM.
> 
> * Major edits and contributions require i) the editor actually have a
>   CLA with Fedora Project, and ii) they agree to be tracked/included
>   as an author.
> 
> * When we include relnotes content, the Docs Team needs to add the
>   steps of attributing contributions that are copyrightable.  This is
>   done by identifying the changes via the wiki history tool, then
>   including a brief description and permanent URI for that history
>   change in the SCM commit; ideally, one commit per attribution in
>   some reasonable fashion. This allows tracking back for any future
>   copyright requirements.
> 
> Wow, that's a bit of extra work.  Is it worth it?  It might be
> necessary regardless.  Automating the last step in some manner would
> be a good idea.
> 
> - Karsten

Why would we allow people to not sign the CLA to write for the relnotes?
Don't we want contributors of Fedora to be our contributors for the
relnotes?  Especially seeing as how this single document gets wedged
into every release and is posted or referred to in many other
announcements (i.e. high visibility).  

Eric

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-docs-list mailing list
fedora-docs-list@xxxxxxxxxx
To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-docs-list

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Red Hat 9]     [Yosemite News]     [KDE Users]

  Powered by Linux