Re: [legal-discuss] [OpenStack-docs] Licensing of documentation
Adding back legal-discuss as while there were some tangential issues around infra being discussed I believe my core question/concern is most definitely a legal one. ----- Original Message -----
From: "Steve Gordon" <sgordon@redhat.com> To: "Anne Gentle" <annegentle@gmail.com>
----- Original Message -----
From: "Anne Gentle" <annegentle@gmail.com> To: openstack-docs@lists.openstack.org
Message: 1 Date: Wed, 18 Mar 2015 08:36:07 +0100 From: Andreas Jaeger <aj@suse.com> To: Stefano Maffulli <stefano@openstack.org>, openstack-docs@lists.openstack.org Subject: Re: [OpenStack-docs] Licensing of documentation Message-ID: <55092AE7.6040207@suse.com> Content-Type: text/plain; charset=windows-1252
On 03/17/2015 07:12 PM, Stefano Maffulli wrote:
The conversation has definitely drifted off-topic now :) but I think it's worth responding here (and eventually move to infra, where it should continue)
On Tue, 2015-03-17 at 15:57 +0000, Jeremy Stanley wrote:
Once we can safely migrate review.openstack.org to authenticate against the same openstackid.org identity provider as www.openstack.org uses, this should become much simpler again since we'll have a way to force contributors to sign up for a foundation account (though they'll no longer need to fill out the foundation membership form when doing so).
Indeed, stop using Launchpad and use openstackid.org globally is the last step we need to accomplish before we can decouple individual memberships from commit rights. I think we already have all the basic tools in place to build the list of voters, we need to start thinking about moving gerrit to use openstackid.org.
Now, to go back to licensing docs:
what's the status of licensing for the OpenStack upstream documentation?
(I can wait for Anne to come back from holiday if she's the only one who can answer this question).
**************************
Sigh, that's not good. I don't want to be the only one who knows this. :)
Technically the docs are still Apache 2.0 because there is no indicator to a docs contributor that it would be licensed any other way. (To me, this is why we either change the current design or get the transfer underway.)
What indicator does a contributor get that their contributions are licensed under Apache 2.0 today? Are we just talking about the marks on the rendered output (that is, after they already contributed)?
Nick Chase did a lot of legwork a few years back looking into what the legal need is to get all docs licensed cc-by, and we think we need to have all current contributors indicate in writing (somehow) that they license the content cc-by. Then the CLA needs to either change or we need a 2nd CLA for docs contributions.
Are we saying here that current contributors to the project have not signed the CLA? I know this is potentially the case for authors who contributed to books written in sprints using external tools (Ops Guide, Design Arch Guide) but ultimately to get into e.g. openstack-manuals someone who has signed the CLA has to contribute the patch(es) and in doing so grants copyright to the "Project Manager" no? Maybe I am missing something but I don't understand why we would need a second CLA here as the existing one doesn't specify a license either, yet isn't it the mechanism we're using to distribute using Apache 2.0 today?
The desired outcomes are: - every reader knows the license - all people (corporate contributors, publishers) know if and how to reuse the docs
To be honest from previous discussions (which I believe kicked off Nick's expedition) I thought we had this nailed but now I'm more confused than when we started as it seems like we remain in complete limbo on this. Currently we have:
- Some books reporting ASL 2.0: E.g. http://docs.openstack.org/high-availability-guide/content/ - Some books reporting CC-BY-SA: E.g. http://docs.openstack.org/openstack-ops/content/ - Some books reporting BOTH: E.g. http://docs.openstack.org/admin-guide-cloud/content/
...and I have no idea which ones are correct. The earlier replies seemed to indicate we should be displaying both, but more recent ones seem to indicate we should be only displaying ASL 2.0. So in both my roles, as a downstream and as a contributor I can now count myself as thoroughly confused.
-Steve
- every contributor knows their rights when they write upstream docs - contributors are not held liable if the docs are wrong - use of the OpenStack brand and logo still go through normal brand guidelines
That's all I can think of for now. Let me know if there are additional questions or difference in opinion on the outcomes we need.
Anne
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
On Wed, Mar 18, 2015 at 12:42 PM, Steve Gordon <sgordon@redhat.com> wrote:
Adding back legal-discuss as while there were some tangential issues around infra being discussed I believe my core question/concern is most definitely a legal one.
From: "Steve Gordon" <sgordon@redhat.com> To: "Anne Gentle" <annegentle@gmail.com>
----- Original Message -----
From: "Anne Gentle" <annegentle@gmail.com> To: openstack-docs@lists.openstack.org
Message: 1 Date: Wed, 18 Mar 2015 08:36:07 +0100 From: Andreas Jaeger <aj@suse.com> To: Stefano Maffulli <stefano@openstack.org>, openstack-docs@lists.openstack.org Subject: Re: [OpenStack-docs] Licensing of documentation Message-ID: <55092AE7.6040207@suse.com> Content-Type: text/plain; charset=windows-1252
On 03/17/2015 07:12 PM, Stefano Maffulli wrote:
The conversation has definitely drifted off-topic now :) but I
it's worth responding here (and eventually move to infra, where it should continue)
On Tue, 2015-03-17 at 15:57 +0000, Jeremy Stanley wrote:
Once we can safely migrate review.openstack.org to authenticate against the same openstackid.org identity provider as www.openstack.org uses, this should become much simpler again since we'll have a way to force contributors to sign up for a foundation account (though they'll no longer need to fill out the foundation membership form when doing so).
Indeed, stop using Launchpad and use openstackid.org globally is
last step we need to accomplish before we can decouple individual memberships from commit rights. I think we already have all the basic tools in place to build the list of voters, we need to start
about moving gerrit to use openstackid.org.
Now, to go back to licensing docs:
what's the status of licensing for the OpenStack upstream documentation?
(I can wait for Anne to come back from holiday if she's the only one who can answer this question).
**************************
Sigh, that's not good. I don't want to be the only one who knows this. :)
Technically the docs are still Apache 2.0 because there is no indicator to a docs contributor that it would be licensed any other way. (To me,
why we either change the current design or get the transfer underway.)
What indicator does a contributor get that their contributions are
under Apache 2.0 today? Are we just talking about the marks on the rendered output (that is, after they already contributed)?
Nick Chase did a lot of legwork a few years back looking into what the legal need is to get all docs licensed cc-by, and we think we need to have all current contributors indicate in writing (somehow) that they
the content cc-by. Then the CLA needs to either change or we need a 2nd CLA for docs contributions.
Are we saying here that current contributors to the project have not signed the CLA? I know this is potentially the case for authors who contributed to books written in sprints using external tools (Ops Guide, Design Arch Guide) but ultimately to get into e.g. openstack-manuals someone who has signed
CLA has to contribute the patch(es) and in doing so grants copyright to
----- Original Message ----- think the thinking this is licensed license the the
"Project Manager" no? Maybe I am missing something but I don't understand why we would need a second CLA here as the existing one doesn't specify a license either, yet isn't it the mechanism we're using to distribute using Apache 2.0 today?
The desired outcomes are: - every reader knows the license - all people (corporate contributors, publishers) know if and how to reuse the docs
To be honest from previous discussions (which I believe kicked off Nick's expedition) I thought we had this nailed but now I'm more confused than when we started as it seems like we remain in complete limbo on this. Currently we have:
- Some books reporting ASL 2.0: E.g. http://docs.openstack.org/high-availability-guide/content/ - Some books reporting CC-BY-SA: E.g. http://docs.openstack.org/openstack-ops/content/ - Some books reporting BOTH: E.g. http://docs.openstack.org/admin-guide-cloud/content/
...and I have no idea which ones are correct. The earlier replies seemed to indicate we should be displaying both, but more recent ones seem to indicate we should be only displaying ASL 2.0. So in both my roles, as a downstream and as a contributor I can now count myself as thoroughly confused.
So sorry Steve, it _is_ confusing. I'll give this my full attention when I'm back next week. Feel free to get more clarification here though! It's completely possible I'm not remembering everything. Anne
-Steve
- every contributor knows their rights when they write upstream docs - contributors are not held liable if the docs are wrong - use of the OpenStack brand and logo still go through normal brand guidelines
That's all I can think of for now. Let me know if there are additional questions or difference in opinion on the outcomes we need.
Anne
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
On 3/18/2015 4:51 PM, Anne Gentle wrote:
On Wed, Mar 18, 2015 at 12:42 PM, Steve Gordon <sgordon@redhat.com <mailto:sgordon@redhat.com>> wrote:
> Are we saying here that current contributors to the project have not signed > the CLA? I know this is potentially the case for authors who contributed to > books written in sprints using external tools (Ops Guide, Design Arch Guide) > but ultimately to get into e.g. openstack-manuals someone who has signed the > CLA has to contribute the patch(es) and in doing so grants copyright to the > "Project Manager" no? Maybe I am missing something but I don't understand > why we would need a second CLA here as the existing one doesn't specify a > license either, yet isn't it the mechanism we're using to distribute using > Apache 2.0 today?
First off, I can't speak to the Ops Guide but the Design Arch Guide was all people who'd signed the CLA, I believe, though that's by happenstance and not by any causation. As far as what I remember about the previous expedition: In order for us to officially change the license, we needed to find a way to: a) Add the new license to the overall CLA and get everyone to sign it b) Get everyone to sign a separate new CLA that specified the new license or c) Find a way to ensure that new contributors knew that their content was going under a different license than the code. Making things further complicated was the fact that some books (the API Guide?) have substantial amounts of code and need to ALSO have the ASL, even if we add the CC-BY for the prose part. And of course any license changes needed to be approved by the board, which is, I think, where we eventually ran aground. That, and I think the final question was, "Why do we need to do this, again?" ---- Nick
> > > The desired outcomes are: > > - every reader knows the license > > - all people (corporate contributors, publishers) know if and how to reuse > > the docs > > To be honest from previous discussions (which I believe kicked off Nick's > expedition) I thought we had this nailed but now I'm more confused than when > we started as it seems like we remain in complete limbo on this. Currently > we have: > > - Some books reporting ASL 2.0: E.g. > http://docs.openstack.org/high-availability-guide/content/ > - Some books reporting CC-BY-SA: E.g. > http://docs.openstack.org/openstack-ops/content/ > - Some books reporting BOTH: E.g. > http://docs.openstack.org/admin-guide-cloud/content/ > > ...and I have no idea which ones are correct. The earlier replies seemed to > indicate we should be displaying both, but more recent ones seem to indicate > we should be only displaying ASL 2.0. So in both my roles, as a downstream > and as a contributor I can now count myself as thoroughly confused. >
So sorry Steve, it _is_ confusing.
I'll give this my full attention when I'm back next week. Feel free to get more clarification here though! It's completely possible I'm not remembering everything.
Anne
> -Steve > > > - every contributor knows their rights when they write upstream docs > > - contributors are not held liable if the docs are wrong > > - use of the OpenStack brand and logo still go through normal brand > > guidelines > > > > That's all I can think of for now. Let me know if there are additional > > questions or difference in opinion on the outcomes we need. > > > > Anne > > > > _______________________________________________ > > OpenStack-docs mailing list > > OpenStack-docs@lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > > > > -- > Steve Gordon, RHCE > Sr. Technical Product Manager, > Red Hat Enterprise Linux OpenStack Platform > > _______________________________________________ > OpenStack-docs mailing list > OpenStack-docs@lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs >
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
On Wed, Mar 18, 2015 at 05:13:44PM -0400, Nick Chase wrote:
As far as what I remember about the previous expedition:
In order for us to officially change the license, we needed to find a way to:
a) Add the new license to the overall CLA and get everyone to sign it
I don't understand this part -- why would the CLA need to specify what the outbound documentation license is? On the software side, the CLA does not specify that code will be licensed under the Apache License. What constrains the Foundation to distributing CLA-licensed code under the Apache License is the bylaws IP policy, not anything in the CLA itself. Richard
On Wed, Mar 18, 2015 at 4:27 PM, Richard Fontana <rfontana@redhat.com> wrote:
On Wed, Mar 18, 2015 at 05:13:44PM -0400, Nick Chase wrote:
As far as what I remember about the previous expedition:
In order for us to officially change the license, we needed to find a way to:
a) Add the new license to the overall CLA and get everyone to sign it
I don't understand this part -- why would the CLA need to specify what the outbound documentation license is? On the software side, the CLA does not specify that code will be licensed under the Apache License. What constrains the Foundation to distributing CLA-licensed code under the Apache License is the bylaws IP policy, not anything in the CLA itself.
Got it, thanks for clarifying. I should not try to understand nor explain anything while on vacation. :) My misunderstanding is around "what mechanism do contributors have to understand how their contribution is licensed?" I mistakenly thought the CLA had words to explain that. I've read it with that need in mind, and indeed, it does not specify licensing. Anne
Richard
On Wed, Mar 18, 2015 at 04:31:03PM -0500, Anne Gentle wrote:
On Wed, Mar 18, 2015 at 4:27 PM, Richard Fontana <rfontana@redhat.com> wrote:
On Wed, Mar 18, 2015 at 05:13:44PM -0400, Nick Chase wrote: > As far as what I remember about the previous expedition: > > In order for us to officially change the license, we needed to find a way to: > > a) Add the new license to the overall CLA and get everyone to sign it
I don't understand this part -- why would the CLA need to specify what the outbound documentation license is? On the software side, the CLA does not specify that code will be licensed under the Apache License. What constrains the Foundation to distributing CLA-licensed code under the Apache License is the bylaws IP policy, not anything in the CLA itself.
Got it, thanks for clarifying. I should not try to understand nor explain anything while on vacation. :)
My misunderstanding is around "what mechanism do contributors have to understand how their contribution is licensed?"
I mistakenly thought the CLA had words to explain that. I've read it with that need in mind, and indeed, it does not specify licensing.
Actually there's a good argument the CLA *should* specify this, so I didn't mean to suggest it is a bad idea. (That would make the CLA somewhat more like the DCO in some respects.) RF
----- Original Message -----
From: "Nick Chase" <nchase@mirantis.com> To: "Anne Gentle" <annegentle@gmail.com>, "Steve Gordon" <sgordon@redhat.com>
On 3/18/2015 4:51 PM, Anne Gentle wrote:
On Wed, Mar 18, 2015 at 12:42 PM, Steve Gordon <sgordon@redhat.com <mailto:sgordon@redhat.com>> wrote:
> Are we saying here that current contributors to the project have not signed > the CLA? I know this is potentially the case for authors who contributed to > books written in sprints using external tools (Ops Guide, Design Arch Guide) > but ultimately to get into e.g. openstack-manuals someone who has signed the > CLA has to contribute the patch(es) and in doing so grants copyright to the > "Project Manager" no? Maybe I am missing something but I don't understand > why we would need a second CLA here as the existing one doesn't specify a > license either, yet isn't it the mechanism we're using to distribute using > Apache 2.0 today?
First off, I can't speak to the Ops Guide but the Design Arch Guide was all people who'd signed the CLA, I believe, though that's by happenstance and not by any causation.
As far as what I remember about the previous expedition:
In order for us to officially change the license, we needed to find a way to:
a) Add the new license to the overall CLA and get everyone to sign it b) Get everyone to sign a separate new CLA that specified the new license or c) Find a way to ensure that new contributors knew that their content was going under a different license than the code.
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.
Making things further complicated was the fact that some books (the API Guide?) have substantial amounts of code and need to ALSO have the ASL, even if we add the CC-BY for the prose part.
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).
And of course any license changes needed to be approved by the board, which is, I think, where we eventually ran aground.
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?
That, and I think the final question was, "Why do we need to do this, again?"
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 docs.openstack.org. We currently have examples of all of these cases: - Guides that expose ASL 2.0. - Guides that expose CC-BY-SA 3.0. - Guides that expose both. - Guides that expose no license at all. What's still not clear to me at the moment is *how* to proceed with that. -Steve [1] http://lists.openstack.org/pipermail/openstack-docs/2013-September/002904.ht... [2] https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#...
> > > The desired outcomes are: > > - every reader knows the license > > - all people (corporate contributors, publishers) know if and how to reuse > > the docs > > To be honest from previous discussions (which I believe kicked off Nick's > expedition) I thought we had this nailed but now I'm more confused than when > we started as it seems like we remain in complete limbo on this. Currently > we have: > > - Some books reporting ASL 2.0: E.g. > http://docs.openstack.org/high-availability-guide/content/ > - Some books reporting CC-BY-SA: E.g. > http://docs.openstack.org/openstack-ops/content/ > - Some books reporting BOTH: E.g. > http://docs.openstack.org/admin-guide-cloud/content/ > > ...and I have no idea which ones are correct. The earlier replies seemed to > indicate we should be displaying both, but more recent ones seem to indicate > we should be only displaying ASL 2.0. So in both my roles, as a downstream > and as a contributor I can now count myself as thoroughly confused. >
So sorry Steve, it _is_ confusing.
I'll give this my full attention when I'm back next week. Feel free to get more clarification here though! It's completely possible I'm not remembering everything.
Anne
> -Steve > > > - every contributor knows their rights when they write upstream docs > > - contributors are not held liable if the docs are wrong > > - use of the OpenStack brand and logo still go through normal brand > > guidelines > > > > That's all I can think of for now. Let me know if there are additional > > questions or difference in opinion on the outcomes we need. > > > > Anne > > > > _______________________________________________ > > OpenStack-docs mailing list > > OpenStack-docs@lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs > > > > -- > Steve Gordon, RHCE > Sr. Technical Product Manager, > Red Hat Enterprise Linux OpenStack Platform > > _______________________________________________ > OpenStack-docs mailing list > OpenStack-docs@lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs >
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
On Wed, Mar 18, 2015 at 4:47 PM, Steve Gordon <sgordon@redhat.com> wrote:
From: "Nick Chase" <nchase@mirantis.com> To: "Anne Gentle" <annegentle@gmail.com>, "Steve Gordon" < sgordon@redhat.com>
On 3/18/2015 4:51 PM, Anne Gentle wrote:
On Wed, Mar 18, 2015 at 12:42 PM, Steve Gordon <sgordon@redhat.com <mailto:sgordon@redhat.com>> wrote:
> Are we saying here that current contributors to the project have not signed > the CLA? I know this is potentially the case for authors who contributed to > books written in sprints using external tools (Ops Guide, Design Arch Guide) > but ultimately to get into e.g. openstack-manuals someone who has signed the > CLA has to contribute the patch(es) and in doing so grants copyright to the > "Project Manager" no? Maybe I am missing something but I don't understand > why we would need a second CLA here as the existing one doesn't specify a > license either, yet isn't it the mechanism we're using to distribute using > Apache 2.0 today?
First off, I can't speak to the Ops Guide but the Design Arch Guide was all people who'd signed the CLA, I believe, though that's by happenstance and not by any causation.
As far as what I remember about the previous expedition:
In order for us to officially change the license, we needed to find a way to:
a) Add the new license to the overall CLA and get everyone to sign it b) Get everyone to sign a separate new CLA that specified the new
----- Original Message ----- license
or c) Find a way to ensure that new contributors knew that their content was going under a different license than the code.
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.
Making things further complicated was the fact that some books (the API Guide?) have substantial amounts of code and need to ALSO have the ASL, even if we add the CC-BY for the prose part.
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).
And of course any license changes needed to be approved by the board, which is, I think, where we eventually ran aground.
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?
That, and I think the final question was, "Why do we need to do this, again?"
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 docs.openstack.org. We currently have examples of all of these cases:
- Guides that expose ASL 2.0. - Guides that expose CC-BY-SA 3.0. - Guides that expose both. - Guides that expose no license at all.
What's still not clear to me at the moment is *how* to proceed with that.
Okay, I think we're getting closer to what we want. Then we can put a plan in place for the outcomes. I personally want contributors to understand how their doc contributions get licensed, but perhaps the output is the only way to do that. Some guides will purposely expose both due to having code and content, is that problematic for you still Steve? 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: https://bugs.launchpad.net/openstack-manuals/+bug/1433868 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. I'll use https://wiki.openstack.org/wiki/Documentation/ContentSpecs 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. 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? Let me know your thoughts. Thanks all for the input. Anne
-Steve
[1] http://lists.openstack.org/pipermail/openstack-docs/2013-September/002904.ht... [2] https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#...
> > > The desired outcomes are: > > - every reader knows the license > > - all people (corporate contributors, publishers) know if and how to reuse > > the docs > > To be honest from previous discussions (which I believe kicked off Nick's > expedition) I thought we had this nailed but now I'm more confused than when > we started as it seems like we remain in complete limbo on this. Currently > we have: > > - Some books reporting ASL 2.0: E.g. > http://docs.openstack.org/high-availability-guide/content/ > - Some books reporting CC-BY-SA: E.g. > http://docs.openstack.org/openstack-ops/content/ > - Some books reporting BOTH: E.g. > http://docs.openstack.org/admin-guide-cloud/content/ > > ...and I have no idea which ones are correct. The earlier replies seemed to > indicate we should be displaying both, but more recent ones seem to indicate > we should be only displaying ASL 2.0. So in both my roles, as a downstream > and as a contributor I can now count myself as thoroughly
confused.
>
So sorry Steve, it _is_ confusing.
I'll give this my full attention when I'm back next week. Feel free to get more clarification here though! It's completely possible I'm not remembering everything.
Anne
> -Steve > > > - every contributor knows their rights when they write upstream docs > > - contributors are not held liable if the docs are wrong > > - use of the OpenStack brand and logo still go through normal brand > > guidelines > > > > That's all I can think of for now. Let me know if there are additional > > questions or difference in opinion on the outcomes we need. > > > > Anne > > > > _______________________________________________ > > OpenStack-docs mailing list > > OpenStack-docs@lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> > >
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
> > > > -- > Steve Gordon, RHCE > Sr. Technical Product Manager, > Red Hat Enterprise Linux OpenStack Platform > > _______________________________________________ > OpenStack-docs mailing list > OpenStack-docs@lists.openstack.org <mailto:OpenStack-docs@lists.openstack.org> >
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
_______________________________________________ OpenStack-docs mailing list OpenStack-docs@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
-- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
On Fri, Mar 20, 2015 at 09:26:59AM -0500, Anne Gentle wrote:
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?
It shouldn't be necessary (though maybe it would be a nice thing to do), assuming all contributions are associated with one or more CLAs, since the CLAs in use by the Foundation would permit incorporation in docs licensed outbound under CC BY. Richard
On 2015-03-20 09:26:59 -0500 (-0500), Anne Gentle wrote: [...]
I checked on the CC-By ability of the clouddocs-maven-plugin and it can do CC-by, but only 3.0 currently. [...]
Can you clarify why that's a problem? For example our wiki content all claims to be contributed/distributed under CC BY 3.0 explicitly, so if that's not actually what we wanted then we have a bit of a problem there too. Speaking of problems, the wiki edit screen's blurb about that links to a nonexistent page[1] for "details" so we should probably do something about that. I'd fix it myself immediately except this discussion now has me questioning what's supposed to be in it. :( [1] https://wiki.openstack.org/wiki/OpenStack:Copyrights -- Jeremy Stanley
----- Original Message -----
From: "Anne Gentle" <annegentle@gmail.com> To: "Steve Gordon" <sgordon@redhat.com> On Wed, Mar 18, 2015 at 4:47 PM, Steve Gordon < sgordon@redhat.com > wrote:
----- Original Message -----
From: "Nick Chase" < nchase@mirantis.com >
First off, I can't speak to the Ops Guide but the Design Arch Guide was
all people who'd signed the CLA, I believe, though that's by
happenstance and not by any causation.
As far as what I remember about the previous expedition:
In order for us to officially change the license, we needed to find a
way to:
a) Add the new license to the overall CLA and get everyone to sign it
b) Get everyone to sign a separate new CLA that specified the new license
or
c) Find a way to ensure that new contributors knew that their content
was going under a different license than the code.
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.
Making things further complicated was the fact that some books (the API
Guide?) have substantial amounts of code and need to ALSO have the ASL,
even if we add the CC-BY for the prose part.
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).
And of course any license changes needed to be approved by the board,
which is, I think, where we eventually ran aground.
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?
That, and I think the final question was, "Why do we need to do this,
again?"
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 docs.openstack.org . We currently have examples of all of these cases:
- Guides that expose ASL 2.0.
- Guides that expose CC-BY-SA 3.0.
- Guides that expose both.
- Guides that expose no license at all.
What's still not clear to me at the moment is *how* to proceed with that.
Okay, I think we're getting closer to what we want. Then we can put a plan in place for the outcomes.
I personally want contributors to understand how their doc contributions get licensed, but perhaps the output is the only way to do that.
Some guides will purposely expose both due to having code and content, is that problematic for you still Steve?
Per Richard I'm not sure it's *necessary* but I don't believe it's a problem either. Perhaps though if doing this it would be good to make it clear in the boilerplate what is licensed as CC-BY (the prose) and what is licensed as ASL (code samples) and use that across the board? Ideally what I would like to get away from is having inconsistent licensing headers across the docs suite leading to the question "is this intentional/reliable".
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: https://bugs.launchpad.net/openstack-manuals/+bug/1433868
My recollection is we were always after 3.0 so while future proofing the toolchain is good I think this is OK for now :).
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.
That would be great, I think this would be very helpful for framing where we go next.
I'll use https://wiki.openstack.org/wiki/Documentation/ContentSpecs 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.
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?
I'm also not sure on this, like Nick I think everyone who was involved in the Arch Design Guide, by co-incidence, had signed the CLA (we should verify this though) and this should alleviate this concern but I am unclear on whether the same holds for the Ops and Security guides. Thanks, Steve
Let me know your thoughts. Thanks all for the input.
Anne
-Steve
[1] http://lists.openstack.org/pipermail/openstack-docs/2013-September/002904.ht...
[2] https://wiki.openstack.org/wiki/Governance/Foundation/15Oct2012BoardMinutes#...
The desired outcomes are:
- every reader knows the license
- all people (corporate contributors, publishers) know if and
how to reuse
the docs
To be honest from previous discussions (which I believe kicked
off Nick's
expedition) I thought we had this nailed but now I'm more
confused than when
we started as it seems like we remain in complete limbo on this.
Currently
we have:
- Some books reporting ASL 2.0: E.g.
- Some books reporting CC-BY-SA: E.g.
- Some books reporting BOTH: E.g.
...and I have no idea which ones are correct. The earlier
replies seemed to
indicate we should be displaying both, but more recent ones seem
to indicate
we should be only displaying ASL 2.0. So in both my roles, as a
downstream
and as a contributor I can now count myself as thoroughly confused.
So sorry Steve, it _is_ confusing.
I'll give this my full attention when I'm back next week. Feel free to
get more clarification here though! It's completely possible I'm not
remembering everything.
Anne
-Steve
- every contributor knows their rights when they write
upstream docs
- contributors are not held liable if the docs are wrong
- use of the OpenStack brand and logo still go through normal
brand
guidelines
That's all I can think of for now. Let me know if there are
additional
questions or difference in opinion on the outcomes we need.
Anne
_______________________________________________
OpenStack-docs mailing list
OpenStack-docs@lists.openstack.org
<mailto: OpenStack-docs@lists.openstack.org >
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
--
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform
_______________________________________________
OpenStack-docs mailing list
OpenStack-docs@lists.openstack.org
<mailto: OpenStack-docs@lists.openstack.org >
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
--
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform
_______________________________________________
OpenStack-docs mailing list
OpenStack-docs@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
--
Steve Gordon, RHCE
Sr. Technical Product Manager,
Red Hat Enterprise Linux OpenStack Platform
-- -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform
participants (5)
-
Anne Gentle
-
Jeremy Stanley
-
Nick Chase
-
Richard Fontana
-
Steve Gordon