<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 4:47 PM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Nick Chase" <<a href="mailto:nchase@mirantis.com">nchase@mirantis.com</a>><br>
> To: "Anne Gentle" <<a href="mailto:annegentle@gmail.com">annegentle@gmail.com</a>>, "Steve Gordon" <<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>><br>
><br>
> On 3/18/2015 4:51 PM, Anne Gentle wrote:<br>
> ><br>
> ><br>
> > On Wed, Mar 18, 2015 at 12:42 PM, Steve Gordon <<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a><br>
</span><div><div class="h5">> > <mailto:<a href="mailto:sgordon@redhat.com">sgordon@redhat.com</a>>> wrote:<br>
> ><br>
> ><br>
> >     > Are we saying here that current contributors to the project have<br>
> >     not signed<br>
> >     > the CLA? I know this is potentially the case for authors who<br>
> >     contributed to<br>
> >     > books written in sprints using external tools (Ops Guide, Design<br>
> >     Arch Guide)<br>
> >     > but ultimately to get into e.g. openstack-manuals someone who<br>
> >     has signed the<br>
> >     > CLA has to contribute the patch(es) and in doing so grants<br>
> >     copyright to the<br>
> >     > "Project Manager" no? Maybe I am missing something but I don't<br>
> >     understand<br>
> >     > why we would need a second CLA here as the existing one doesn't<br>
> >     specify a<br>
> >     > license either, yet isn't it the mechanism we're using to<br>
> >     distribute using<br>
> >     > Apache 2.0 today?<br>
> ><br>
><br>
> First off, I can't speak to the Ops Guide but the Design Arch Guide was<br>
> all people who'd signed the CLA, I believe, though that's by<br>
> happenstance and not by any causation.<br>
><br>
> As far as what I remember about the previous expedition:<br>
><br>
> In order for us to officially change the license, we needed to find a<br>
> way to:<br>
><br>
> a)  Add the new license to the overall CLA and get everyone to sign it<br>
> b)  Get everyone to sign a separate new CLA that specified the new license<br>
> or<br>
> c)  Find a way to ensure that new contributors knew that their content<br>
> was going under a different license than the code.<br>
<br>
</div></div>Per other comments, this seems like an odd requirement given how we currently handle the code - that is the CLA certainly doesn't specify that we're using ASL 2.0 today.<br>
<span class=""><br>
> Making things further complicated was the fact that some books (the API<br>
> Guide?) have substantial amounts of code and need to ALSO have the ASL,<br>
> even if we add the CC-BY for the prose part.<br>
<br>
</span>Currently the API Reference is actually the example of a guide that doesn't expose any license boiler plate at all, ASL 2.0 or otherwise (fun). </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> And of course any license changes needed to be approved by the board,<br>
> which is, I think, where we eventually ran aground.<br>
<br>
</span>This is where I get confused because things go a bit circular. Using CC-BY for documentation was already approved by the board, in 2012 no less [1][2], and at some point (apparently) a letter was drafted to the board explaining the steps required to execute (I assume this was the outcome of your work) but it's unclear to me what if anything happened next. Was it presented to the board and rejected?<br>
<span class=""><br>
> That, and I think the final question was, "Why do we need to do this,<br>
> again?"<br>
<br>
</span>This pre-dates my involvement, and Anne only touches on it in the email I can find [1], but from my point of view even if the ultimate answer is no we want to stick with ASL 2.0 for documentation we need to resolve the current hodge podge of licenses being exposed on <a href="http://docs.openstack.org" target="_blank">docs.openstack.org</a>. We currently have examples of all of these cases:<br>
<br>
- Guides that expose ASL 2.0.<br>
- Guides that expose CC-BY-SA 3.0.<br>
- Guides that expose both.<br>
- Guides that expose no license at all.<br>
<br>
What's still not clear to me at the moment is *how* to proceed with that.<br>
<br></blockquote><div><br></div><div><br></div><div>Okay, I think we're getting closer to what we want. Then we can put a plan in place for the outcomes.</div><div><br></div><div>I personally want contributors to understand how their doc contributions get licensed, but perhaps the output is the only way to do that. </div><div><br></div><div>Some guides will purposely expose both due to having code and content, is that problematic for you still Steve? </div><div><br></div><div>I checked on the CC-By ability of the clouddocs-maven-plugin and it can do CC-by, but only 3.0 currently. Bug logged: </div><div><a href="https://bugs.launchpad.net/openstack-manuals/+bug/1433868">https://bugs.launchpad.net/openstack-manuals/+bug/1433868</a><br></div><div><br></div><div>How about this: I'll take a stab at the desired state for each guide. Then for each guide we can say what has to be done to get to desired state.</div><div><br></div><div>I'll use <a href="https://wiki.openstack.org/wiki/Documentation/ContentSpecs">https://wiki.openstack.org/wiki/Documentation/ContentSpecs</a> as a starting point. I won't write up a blueprint or spec yet since this is "just" bug fixing for now, as long as we get agreement on each guide's license. </div><div><br></div><div>The only place where I still need legal guidance is whether I need an audit-able trail for the license assignment, does anyone know? For example, if I change the Ops Guide to CC-by, do I have to get agreement from all the contributors to the Ops Guide?</div><div><br></div><div>Let me know your thoughts. Thanks all for the input. </div><div><br></div><div>Anne</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
-Steve<br>
<br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-docs/2013-September/002904.html" target="_blank">http://lists.openstack.org/pipermail/openstack-docs/2013-September/002904.html</a><br>
[2] <a href="https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#Approval_of_the_CCBY_License_for_Documentation" target="_blank">https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#Approval_of_the_CCBY_License_for_Documentation</a><br>
<div><div class="h5"><br>
> >     ><br>
> >     > > The desired outcomes are:<br>
> >     > > - every reader knows the license<br>
> >     > > - all people (corporate contributors, publishers) know if and<br>
> >     how to reuse<br>
> >     > > the docs<br>
> >     ><br>
> >     > To be honest from previous discussions (which I believe kicked<br>
> >     off Nick's<br>
> >     > expedition) I thought we had this nailed but now I'm more<br>
> >     confused than when<br>
> >     > we started as it seems like we remain in complete limbo on this.<br>
> >     Currently<br>
> >     > we have:<br>
> >     ><br>
> >     > - Some books reporting ASL 2.0: E.g.<br>
> >     > <a href="http://docs.openstack.org/high-availability-guide/content/" target="_blank">http://docs.openstack.org/high-availability-guide/content/</a><br>
> >     > - Some books reporting CC-BY-SA: E.g.<br>
> >     > <a href="http://docs.openstack.org/openstack-ops/content/" target="_blank">http://docs.openstack.org/openstack-ops/content/</a><br>
> >     > - Some books reporting BOTH: E.g.<br>
> >     > <a href="http://docs.openstack.org/admin-guide-cloud/content/" target="_blank">http://docs.openstack.org/admin-guide-cloud/content/</a><br>
> >     ><br>
> >     > ...and I have no idea which ones are correct. The earlier<br>
> >     replies seemed to<br>
> >     > indicate we should be displaying both, but more recent ones seem<br>
> >     to indicate<br>
> >     > we should be only displaying ASL 2.0. So in both my roles, as a<br>
> >     downstream<br>
> >     > and as a contributor I can now count myself as thoroughly confused.<br>
> >     ><br>
> ><br>
> ><br>
> > So sorry Steve, it _is_ confusing.<br>
> ><br>
> > I'll give this my full attention when I'm back next week. Feel free to<br>
> > get more clarification here though! It's completely possible I'm not<br>
> > remembering everything.<br>
> ><br>
> > Anne<br>
> ><br>
> >     > -Steve<br>
> >     ><br>
> >     > > - every contributor knows their rights when they write<br>
> >     upstream docs<br>
> >     > > - contributors are not held liable if the docs are wrong<br>
> >     > > - use of the OpenStack brand and logo still go through normal<br>
> >     brand<br>
> >     > > guidelines<br>
> >     > ><br>
> >     > > That's all I can think of for now. Let me know if there are<br>
> >     additional<br>
> >     > > questions or difference in opinion on the outcomes we need.<br>
> >     > ><br>
> >     > > Anne<br>
> >     > ><br>
> >     > > _______________________________________________<br>
> >     > > OpenStack-docs mailing list<br>
> >     > > <a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a><br>
</div></div>> >     <mailto:<a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a>><br>
<span class="">> >     > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
> >     > ><br>
> >     ><br>
> >     > --<br>
> >     > Steve Gordon, RHCE<br>
> >     > Sr. Technical Product Manager,<br>
> >     > Red Hat Enterprise Linux OpenStack Platform<br>
> >     ><br>
> >     > _______________________________________________<br>
> >     > OpenStack-docs mailing list<br>
> >     > <a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a><br>
</span>> >     <mailto:<a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a>><br>
<div class=""><div class="h5">> >     > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
> >     ><br>
> ><br>
> >     --<br>
> >     Steve Gordon, RHCE<br>
> >     Sr. Technical Product Manager,<br>
> >     Red Hat Enterprise Linux OpenStack Platform<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-docs mailing list<br>
> > <a href="mailto:OpenStack-docs@lists.openstack.org">OpenStack-docs@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
><br>
><br>
<br>
--<br>
Steve Gordon, RHCE<br>
Sr. Technical Product Manager,<br>
Red Hat Enterprise Linux OpenStack Platform<br>
</div></div></blockquote></div><br></div></div>