You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2011/08/30 17:34:29 UTC
An example of the license problems we're going to face
As far as I know, all Apache projects have source releases. Some also
have binary releases. I expect we will have both.
OOo, since it was LGPL, could assume a copyleft orientation for
source, documentation, templates, binaries, etc. Everything was
copyleft, meaning if someone modified these materials, any
distributions of it must be accompanied by the changes, and have the
same copyleft license.
With Apache, our releases are under the Apache 2.0 license. This is
not a copyleft license. Apache code can be modified and republished
without making the changes also available under an open source
license.
The Oracle SGA puts the Apache 2.0 license on the files from OOo that
Sun/Oracle had rights to under the various forms of their contributor
agreements. This predominantly covered source code. But it did not
cover project documentation. Documentation was generally under the
copyleft Public Documentation License (PDL) or CC BY-A.
This is going to cause us problems. A specific example. The main
build instructions for OpenOffice.org are in a PDL-licensed Building
Guide document [1]. This means that our own source code releases are
unable to be accompanied by instructions on how to build the product.
This is quite odd, compared to most other projects, say SVN, which
include build instructions with their source releases [2].
Of course, we can have a README file in our source releases that
points to the PDL Building Guide. That may seem to solve the problem,
but it really doesn't. We've now placed copyleft restrictions on
downstream consumers that might want to modify the source code, and as
part of those modifications also modify the build instructions. We've
now placed additional constraints on them, beyond Apache 2.0, for how
they can use the release.
This is not an isolated occurrence. If I'm reading this [3]
correctly, there are thousands of pieces of documentation that are
under PDL. This is not all "community" or "wiki" stuff that we can
just pass off as something that loosely affiliated folks do in an
uncoordinated fashion, without joining the project, under a license of
their preference This is the core blood of the project, how to use
the product, how to build the product, how to test the product, how to
customize the product, etc.
As I've said before, we can't change the past. But we can prevent
repeating past mistakes. We need to ensure that in the future that
the core project documentation is developed and maintained under the
ALv2 license. A good question to ask is this: If a downstream
consumer wanted to use our source release, to build and distribute a
customized version of AOOo, could they do that successfully? Or would
they be severely constrained and find that our releases are actually
missing essential documentation files without which AOOo cannot be
used?
-Rob
[1] http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide
[2] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
[3] http://ooo-wiki.apache.org/wiki/Category:PDL_License
Re: An example of the license problems we're going to face
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 08/30/2011 05:34 PM, schrieb Rob Weir:
> As far as I know, all Apache projects have source releases. Some also
> have binary releases. I expect we will have both.
In the past we had also a source release for every binary release. But
the download number were as small as you can think of. Unfortunately,
I've no longer any numbers but you can believe me, it wasn't more than a
few hundreds compared with then ten thousands of the binarty files.
So, the very most interested people are developers. These people do not
download a source tarball but the most recent revision or the respective
release tag; so a "svn co ..." is their favorite to get it.
IMHO we do not need to release anything as source. A pointer on a
webpage how to get it from SVN is sufficient. But it could be also
integrated into SVN to get it AL2 compatible.
Marcus
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Of course, concerning CC-BY 2.0. And we can choose to view CC-BY 2.0 as toxic for the purposes of this project, I suppose. But either way, third-party rules apply.
And we should deal with concrete cases in hand rather than hypotheticals. I agree that "deal with it" is snippy and I apologize to all.
- Dennis
-----Original Message-----
From: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
Sent: Wednesday, August 31, 2011 06:31
To: ooo-dev@incubator.apache.org; dennis.hamilton@acm.org
Subject: Re: An example of the license problems we're going to face
On Tue, Aug 30, 2011 at 1:22 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Rob, this is really simple.
>
> We have no rights other than what are conferred by the licenses and notices on those works you wish to be able to include in distributions.
>
> Since you believe they don't permit what you want, we can't do what you want with them.
>
> Deal with it.
This is not the style of interpersonal interaction I like seeing here.
> Now, if you propose to keep those works off of the incubator web site because they are toxic (let's suppose), then there is another reason for making sure that http://openoffice.org stays up and alive so the materials can continue to be found there until satisfactory alternatives appear, if ever.
This question fundamentally is about what the ASF is all about. Truth
be told, there are *lots* of wonderful licenses out there. We can't
stop people from using them. Nor should we, as I said there are lots
of wonderful licenses out there, each wonderful in their own precious
and unique way.
The ASF isn't about those other licenses. The ASF is about the Apache
License. We've worked hard to establish uniform expectations across
our set of products as to what you can and can not do with the
releases that we produce.
At the ASF we have zero problems with the idea that a project creates
a vibrant eco-system which includes data contained elsewhere that may
be of another license and quality. That can be a huge win for
everybody.
But as to the assets that are released and hosted by the ASF, we have
high standards. We will make pragmatic exceptions, sometimes even on
a case by case basis, based on specific circumstances.
But meanwhile, don't assume that the fact that we previously didn't
notice that this clause was in CC-By 2.0 that that means that CC-by
3.0 is OK. It might be that the way we decide to fix that bug is to
remove CC-By 2.0 from the list.
> - Dennis
- Sam Ruby
Re: An example of the license problems we're going to face
Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Aug 30, 2011 at 1:22 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Rob, this is really simple.
>
> We have no rights other than what are conferred by the licenses and notices on those works you wish to be able to include in distributions.
>
> Since you believe they don't permit what you want, we can't do what you want with them.
>
> Deal with it.
This is not the style of interpersonal interaction I like seeing here.
> Now, if you propose to keep those works off of the incubator web site because they are toxic (let's suppose), then there is another reason for making sure that http://openoffice.org stays up and alive so the materials can continue to be found there until satisfactory alternatives appear, if ever.
This question fundamentally is about what the ASF is all about. Truth
be told, there are *lots* of wonderful licenses out there. We can't
stop people from using them. Nor should we, as I said there are lots
of wonderful licenses out there, each wonderful in their own precious
and unique way.
The ASF isn't about those other licenses. The ASF is about the Apache
License. We've worked hard to establish uniform expectations across
our set of products as to what you can and can not do with the
releases that we produce.
At the ASF we have zero problems with the idea that a project creates
a vibrant eco-system which includes data contained elsewhere that may
be of another license and quality. That can be a huge win for
everybody.
But as to the assets that are released and hosted by the ASF, we have
high standards. We will make pragmatic exceptions, sometimes even on
a case by case basis, based on specific circumstances.
But meanwhile, don't assume that the fact that we previously didn't
notice that this clause was in CC-By 2.0 that that means that CC-by
3.0 is OK. It might be that the way we decide to fix that bug is to
remove CC-By 2.0 from the list.
> - Dennis
- Sam Ruby
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Perhaps the subject line is no longer appropriate then.
Either way, I have said all I need to say on this thread.
- Dennis
-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Tuesday, August 30, 2011 10:28
To: ooo-dev@incubator.apache.org
Subject: Re: An example of the license problems we're going to face
On Tue, Aug 30, 2011 at 1:22 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Rob, this is really simple.
>
> We have no rights other than what are conferred by the licenses and notices on those works you wish to be able to include in distributions.
>
> Since you believe they don't permit what you want, we can't do what you want with them.
>
> Deal with it.
>
Since you are not the content author of any OOo documentation, you can
safely assume that I would not waste my time debating you on that
particular topic. I'm talking about preventing this situation
occurring with future contributions. I think I've said that 4 or 5
times now.
> Now, if you propose to keep those works off of the incubator web site because they are toxic (let's suppose), then there is another reason for making sure that http://openoffice.org stays up and alive so the materials can continue to be found there until satisfactory alternatives appear, if ever.
>
That was not what I was proposing. That was what you were proposing.
I'm talking about future contributions of content.
How about holding back on further instant/flash responses and go back
and read what I've already written? So far you seem to be reading
every other line or something. If there is something I've actually
said that is unclear, then let me know. But simply repeating yourself
is not useful. And it is not useful for me to repeat myself either.
> - Dennis
>
> -----Original Message-----
> From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
> Sent: Tuesday, August 30, 2011 10:05
> To: ooo-dev@incubator.apache.org
> Subject: Re: An example of the license problems we're going to face
>
> On Tue, Aug 30, 2011 at 12:45 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> I think these are non-problems in the sense that we do not have the rights to do anything with works not under the SGA beyond what are provided for in the notices and licenses on those works.
>>
>
> There is a problem. Let me spell it out, in case it was not clear:
>
> 1) We should be aiming for releases, including source code releases,
> that are useful as releases, meaning that the recipients of such
> releases can make practical use of these releases under the rights
> given to them by the ALv2.
>
> 2) Some of the pieces that necessary to make practical use of the
> releases are under incompatible licenses, including copyleft licenses.
> This includes source code modules, but also documentation.
>
> 3) Such incompatibly licensed materials, where necessarily for
> successful use of a release, whether source or documentation, need to
> be identified and replaced.
>
> 4) We also need procedures in place to ensure that source and
> documentation are not in future contaminated by incompatibly (or
> ambiguously) licensed contributions. We seem to have adequate
> safeguards in place for source code. The same is not true for
> documentation.
>
>
>> If we want anything else, we need to refer to them (as you observe), request a grant of some form, request republishing of those works under a friendly license by their authors, or produce our own non-infringing works.
>>
>
> Correct.
>
>> From our perspective, these are all third party works and we simply have to deal with it, just like we deal with third-party code in the OpenOffice.org code base that is not acceptable in an ASF release.
>>
>
> I'm not disputed the existence of the status quo. I'm arguing for
> changes going forward,
>
>> This is an ordinary situation. It is not a podling IP clearance problem the way that the initial code contribution is.
>>
>
> To the extent such material is necessary to the successful use of a
> release and exercise of the ALv2 license, it is an issue. So if some
> random piece of documentation on "10 neat things about OOo" is on the
> community wiki, under PDL, then I don't have a problem with that. But
> when the build instructions are under PDL, then this is a problem,
> since without that no one can make effective use of a source release.
>
>> Regardless of the extent to which we would rather be gifted such material under a permissive license grant, it is that ambition which is a problem if it blinds us to dealing with these cases in the flexible manner that this state of affairs always requires.
>>
>
> If by "flexible" you mean that we would have essential documentation
> needed to make use of a release under an incompatible license, then
> yes, I would urge less flexibility.
>
>
>> I say support preservation of the materials where they are, loosely couple to/with them, and foster small steps to moving the boundaries in ways that serve us, the broad external community, and the will of the third parties as we mature the podling toward incubation.
>>
>
> That is fine. But I'd separate the content migration from the
> procedural migrations. I think we want to immediately institute such
> changes necessary to ensure that future core documentation
> contributions are under a compatible license. The existing content
> may move over to that license, with permission of the original
> authors, where they can be identified, or replaced over time.
>
>> - Dennis
>>
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Tuesday, August 30, 2011 08:34
>> To: ooo-dev@incubator.apache.org
>> Subject: An example of the license problems we're going to face
>>
>> As far as I know, all Apache projects have source releases. Some also
>> have binary releases. I expect we will have both.
>>
>> OOo, since it was LGPL, could assume a copyleft orientation for
>> source, documentation, templates, binaries, etc. Everything was
>> copyleft, meaning if someone modified these materials, any
>> distributions of it must be accompanied by the changes, and have the
>> same copyleft license.
>>
>> With Apache, our releases are under the Apache 2.0 license. This is
>> not a copyleft license. Apache code can be modified and republished
>> without making the changes also available under an open source
>> license.
>>
>> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
>> Sun/Oracle had rights to under the various forms of their contributor
>> agreements. This predominantly covered source code. But it did not
>> cover project documentation. Documentation was generally under the
>> copyleft Public Documentation License (PDL) or CC BY-A.
>>
>> This is going to cause us problems. A specific example. The main
>> build instructions for OpenOffice.org are in a PDL-licensed Building
>> Guide document [1]. This means that our own source code releases are
>> unable to be accompanied by instructions on how to build the product.
>> This is quite odd, compared to most other projects, say SVN, which
>> include build instructions with their source releases [2].
>>
>> Of course, we can have a README file in our source releases that
>> points to the PDL Building Guide. That may seem to solve the problem,
>> but it really doesn't. We've now placed copyleft restrictions on
>> downstream consumers that might want to modify the source code, and as
>> part of those modifications also modify the build instructions. We've
>> now placed additional constraints on them, beyond Apache 2.0, for how
>> they can use the release.
>>
>> This is not an isolated occurrence. If I'm reading this [3]
>> correctly, there are thousands of pieces of documentation that are
>> under PDL. This is not all "community" or "wiki" stuff that we can
>> just pass off as something that loosely affiliated folks do in an
>> uncoordinated fashion, without joining the project, under a license of
>> their preference This is the core blood of the project, how to use
>> the product, how to build the product, how to test the product, how to
>> customize the product, etc.
>>
>> As I've said before, we can't change the past. But we can prevent
>> repeating past mistakes. We need to ensure that in the future that
>> the core project documentation is developed and maintained under the
>> ALv2 license. A good question to ask is this: If a downstream
>> consumer wanted to use our source release, to build and distribute a
>> customized version of AOOo, could they do that successfully? Or would
>> they be severely constrained and find that our releases are actually
>> missing essential documentation files without which AOOo cannot be
>> used?
>>
>> -Rob
>>
>>
>> [1] http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide
>> [2] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
>> [3] http://ooo-wiki.apache.org/wiki/Category:PDL_License
>>
>>
>
>
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@robweir.com>.
On Tue, Aug 30, 2011 at 1:22 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Rob, this is really simple.
>
> We have no rights other than what are conferred by the licenses and notices on those works you wish to be able to include in distributions.
>
> Since you believe they don't permit what you want, we can't do what you want with them.
>
> Deal with it.
>
Since you are not the content author of any OOo documentation, you can
safely assume that I would not waste my time debating you on that
particular topic. I'm talking about preventing this situation
occurring with future contributions. I think I've said that 4 or 5
times now.
> Now, if you propose to keep those works off of the incubator web site because they are toxic (let's suppose), then there is another reason for making sure that http://openoffice.org stays up and alive so the materials can continue to be found there until satisfactory alternatives appear, if ever.
>
That was not what I was proposing. That was what you were proposing.
I'm talking about future contributions of content.
How about holding back on further instant/flash responses and go back
and read what I've already written? So far you seem to be reading
every other line or something. If there is something I've actually
said that is unclear, then let me know. But simply repeating yourself
is not useful. And it is not useful for me to repeat myself either.
> - Dennis
>
> -----Original Message-----
> From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
> Sent: Tuesday, August 30, 2011 10:05
> To: ooo-dev@incubator.apache.org
> Subject: Re: An example of the license problems we're going to face
>
> On Tue, Aug 30, 2011 at 12:45 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> I think these are non-problems in the sense that we do not have the rights to do anything with works not under the SGA beyond what are provided for in the notices and licenses on those works.
>>
>
> There is a problem. Let me spell it out, in case it was not clear:
>
> 1) We should be aiming for releases, including source code releases,
> that are useful as releases, meaning that the recipients of such
> releases can make practical use of these releases under the rights
> given to them by the ALv2.
>
> 2) Some of the pieces that necessary to make practical use of the
> releases are under incompatible licenses, including copyleft licenses.
> This includes source code modules, but also documentation.
>
> 3) Such incompatibly licensed materials, where necessarily for
> successful use of a release, whether source or documentation, need to
> be identified and replaced.
>
> 4) We also need procedures in place to ensure that source and
> documentation are not in future contaminated by incompatibly (or
> ambiguously) licensed contributions. We seem to have adequate
> safeguards in place for source code. The same is not true for
> documentation.
>
>
>> If we want anything else, we need to refer to them (as you observe), request a grant of some form, request republishing of those works under a friendly license by their authors, or produce our own non-infringing works.
>>
>
> Correct.
>
>> From our perspective, these are all third party works and we simply have to deal with it, just like we deal with third-party code in the OpenOffice.org code base that is not acceptable in an ASF release.
>>
>
> I'm not disputed the existence of the status quo. I'm arguing for
> changes going forward,
>
>> This is an ordinary situation. It is not a podling IP clearance problem the way that the initial code contribution is.
>>
>
> To the extent such material is necessary to the successful use of a
> release and exercise of the ALv2 license, it is an issue. So if some
> random piece of documentation on "10 neat things about OOo" is on the
> community wiki, under PDL, then I don't have a problem with that. But
> when the build instructions are under PDL, then this is a problem,
> since without that no one can make effective use of a source release.
>
>> Regardless of the extent to which we would rather be gifted such material under a permissive license grant, it is that ambition which is a problem if it blinds us to dealing with these cases in the flexible manner that this state of affairs always requires.
>>
>
> If by "flexible" you mean that we would have essential documentation
> needed to make use of a release under an incompatible license, then
> yes, I would urge less flexibility.
>
>
>> I say support preservation of the materials where they are, loosely couple to/with them, and foster small steps to moving the boundaries in ways that serve us, the broad external community, and the will of the third parties as we mature the podling toward incubation.
>>
>
> That is fine. But I'd separate the content migration from the
> procedural migrations. I think we want to immediately institute such
> changes necessary to ensure that future core documentation
> contributions are under a compatible license. The existing content
> may move over to that license, with permission of the original
> authors, where they can be identified, or replaced over time.
>
>> - Dennis
>>
>>
>> -----Original Message-----
>> From: Rob Weir [mailto:robweir@apache.org]
>> Sent: Tuesday, August 30, 2011 08:34
>> To: ooo-dev@incubator.apache.org
>> Subject: An example of the license problems we're going to face
>>
>> As far as I know, all Apache projects have source releases. Some also
>> have binary releases. I expect we will have both.
>>
>> OOo, since it was LGPL, could assume a copyleft orientation for
>> source, documentation, templates, binaries, etc. Everything was
>> copyleft, meaning if someone modified these materials, any
>> distributions of it must be accompanied by the changes, and have the
>> same copyleft license.
>>
>> With Apache, our releases are under the Apache 2.0 license. This is
>> not a copyleft license. Apache code can be modified and republished
>> without making the changes also available under an open source
>> license.
>>
>> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
>> Sun/Oracle had rights to under the various forms of their contributor
>> agreements. This predominantly covered source code. But it did not
>> cover project documentation. Documentation was generally under the
>> copyleft Public Documentation License (PDL) or CC BY-A.
>>
>> This is going to cause us problems. A specific example. The main
>> build instructions for OpenOffice.org are in a PDL-licensed Building
>> Guide document [1]. This means that our own source code releases are
>> unable to be accompanied by instructions on how to build the product.
>> This is quite odd, compared to most other projects, say SVN, which
>> include build instructions with their source releases [2].
>>
>> Of course, we can have a README file in our source releases that
>> points to the PDL Building Guide. That may seem to solve the problem,
>> but it really doesn't. We've now placed copyleft restrictions on
>> downstream consumers that might want to modify the source code, and as
>> part of those modifications also modify the build instructions. We've
>> now placed additional constraints on them, beyond Apache 2.0, for how
>> they can use the release.
>>
>> This is not an isolated occurrence. If I'm reading this [3]
>> correctly, there are thousands of pieces of documentation that are
>> under PDL. This is not all "community" or "wiki" stuff that we can
>> just pass off as something that loosely affiliated folks do in an
>> uncoordinated fashion, without joining the project, under a license of
>> their preference This is the core blood of the project, how to use
>> the product, how to build the product, how to test the product, how to
>> customize the product, etc.
>>
>> As I've said before, we can't change the past. But we can prevent
>> repeating past mistakes. We need to ensure that in the future that
>> the core project documentation is developed and maintained under the
>> ALv2 license. A good question to ask is this: If a downstream
>> consumer wanted to use our source release, to build and distribute a
>> customized version of AOOo, could they do that successfully? Or would
>> they be severely constrained and find that our releases are actually
>> missing essential documentation files without which AOOo cannot be
>> used?
>>
>> -Rob
>>
>>
>> [1] http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide
>> [2] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
>> [3] http://ooo-wiki.apache.org/wiki/Category:PDL_License
>>
>>
>
>
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Rob, this is really simple.
We have no rights other than what are conferred by the licenses and notices on those works you wish to be able to include in distributions.
Since you believe they don't permit what you want, we can't do what you want with them.
Deal with it.
Now, if you propose to keep those works off of the incubator web site because they are toxic (let's suppose), then there is another reason for making sure that http://openoffice.org stays up and alive so the materials can continue to be found there until satisfactory alternatives appear, if ever.
- Dennis
-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Tuesday, August 30, 2011 10:05
To: ooo-dev@incubator.apache.org
Subject: Re: An example of the license problems we're going to face
On Tue, Aug 30, 2011 at 12:45 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I think these are non-problems in the sense that we do not have the rights to do anything with works not under the SGA beyond what are provided for in the notices and licenses on those works.
>
There is a problem. Let me spell it out, in case it was not clear:
1) We should be aiming for releases, including source code releases,
that are useful as releases, meaning that the recipients of such
releases can make practical use of these releases under the rights
given to them by the ALv2.
2) Some of the pieces that necessary to make practical use of the
releases are under incompatible licenses, including copyleft licenses.
This includes source code modules, but also documentation.
3) Such incompatibly licensed materials, where necessarily for
successful use of a release, whether source or documentation, need to
be identified and replaced.
4) We also need procedures in place to ensure that source and
documentation are not in future contaminated by incompatibly (or
ambiguously) licensed contributions. We seem to have adequate
safeguards in place for source code. The same is not true for
documentation.
> If we want anything else, we need to refer to them (as you observe), request a grant of some form, request republishing of those works under a friendly license by their authors, or produce our own non-infringing works.
>
Correct.
> From our perspective, these are all third party works and we simply have to deal with it, just like we deal with third-party code in the OpenOffice.org code base that is not acceptable in an ASF release.
>
I'm not disputed the existence of the status quo. I'm arguing for
changes going forward,
> This is an ordinary situation. It is not a podling IP clearance problem the way that the initial code contribution is.
>
To the extent such material is necessary to the successful use of a
release and exercise of the ALv2 license, it is an issue. So if some
random piece of documentation on "10 neat things about OOo" is on the
community wiki, under PDL, then I don't have a problem with that. But
when the build instructions are under PDL, then this is a problem,
since without that no one can make effective use of a source release.
> Regardless of the extent to which we would rather be gifted such material under a permissive license grant, it is that ambition which is a problem if it blinds us to dealing with these cases in the flexible manner that this state of affairs always requires.
>
If by "flexible" you mean that we would have essential documentation
needed to make use of a release under an incompatible license, then
yes, I would urge less flexibility.
> I say support preservation of the materials where they are, loosely couple to/with them, and foster small steps to moving the boundaries in ways that serve us, the broad external community, and the will of the third parties as we mature the podling toward incubation.
>
That is fine. But I'd separate the content migration from the
procedural migrations. I think we want to immediately institute such
changes necessary to ensure that future core documentation
contributions are under a compatible license. The existing content
may move over to that license, with permission of the original
authors, where they can be identified, or replaced over time.
> - Dennis
>
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Tuesday, August 30, 2011 08:34
> To: ooo-dev@incubator.apache.org
> Subject: An example of the license problems we're going to face
>
> As far as I know, all Apache projects have source releases. Some also
> have binary releases. I expect we will have both.
>
> OOo, since it was LGPL, could assume a copyleft orientation for
> source, documentation, templates, binaries, etc. Everything was
> copyleft, meaning if someone modified these materials, any
> distributions of it must be accompanied by the changes, and have the
> same copyleft license.
>
> With Apache, our releases are under the Apache 2.0 license. This is
> not a copyleft license. Apache code can be modified and republished
> without making the changes also available under an open source
> license.
>
> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
> Sun/Oracle had rights to under the various forms of their contributor
> agreements. This predominantly covered source code. But it did not
> cover project documentation. Documentation was generally under the
> copyleft Public Documentation License (PDL) or CC BY-A.
>
> This is going to cause us problems. A specific example. The main
> build instructions for OpenOffice.org are in a PDL-licensed Building
> Guide document [1]. This means that our own source code releases are
> unable to be accompanied by instructions on how to build the product.
> This is quite odd, compared to most other projects, say SVN, which
> include build instructions with their source releases [2].
>
> Of course, we can have a README file in our source releases that
> points to the PDL Building Guide. That may seem to solve the problem,
> but it really doesn't. We've now placed copyleft restrictions on
> downstream consumers that might want to modify the source code, and as
> part of those modifications also modify the build instructions. We've
> now placed additional constraints on them, beyond Apache 2.0, for how
> they can use the release.
>
> This is not an isolated occurrence. If I'm reading this [3]
> correctly, there are thousands of pieces of documentation that are
> under PDL. This is not all "community" or "wiki" stuff that we can
> just pass off as something that loosely affiliated folks do in an
> uncoordinated fashion, without joining the project, under a license of
> their preference This is the core blood of the project, how to use
> the product, how to build the product, how to test the product, how to
> customize the product, etc.
>
> As I've said before, we can't change the past. But we can prevent
> repeating past mistakes. We need to ensure that in the future that
> the core project documentation is developed and maintained under the
> ALv2 license. A good question to ask is this: If a downstream
> consumer wanted to use our source release, to build and distribute a
> customized version of AOOo, could they do that successfully? Or would
> they be severely constrained and find that our releases are actually
> missing essential documentation files without which AOOo cannot be
> used?
>
> -Rob
>
>
> [1] http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide
> [2] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
> [3] http://ooo-wiki.apache.org/wiki/Category:PDL_License
>
>
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@robweir.com>.
On Tue, Aug 30, 2011 at 12:45 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I think these are non-problems in the sense that we do not have the rights to do anything with works not under the SGA beyond what are provided for in the notices and licenses on those works.
>
There is a problem. Let me spell it out, in case it was not clear:
1) We should be aiming for releases, including source code releases,
that are useful as releases, meaning that the recipients of such
releases can make practical use of these releases under the rights
given to them by the ALv2.
2) Some of the pieces that necessary to make practical use of the
releases are under incompatible licenses, including copyleft licenses.
This includes source code modules, but also documentation.
3) Such incompatibly licensed materials, where necessarily for
successful use of a release, whether source or documentation, need to
be identified and replaced.
4) We also need procedures in place to ensure that source and
documentation are not in future contaminated by incompatibly (or
ambiguously) licensed contributions. We seem to have adequate
safeguards in place for source code. The same is not true for
documentation.
> If we want anything else, we need to refer to them (as you observe), request a grant of some form, request republishing of those works under a friendly license by their authors, or produce our own non-infringing works.
>
Correct.
> From our perspective, these are all third party works and we simply have to deal with it, just like we deal with third-party code in the OpenOffice.org code base that is not acceptable in an ASF release.
>
I'm not disputed the existence of the status quo. I'm arguing for
changes going forward,
> This is an ordinary situation. It is not a podling IP clearance problem the way that the initial code contribution is.
>
To the extent such material is necessary to the successful use of a
release and exercise of the ALv2 license, it is an issue. So if some
random piece of documentation on "10 neat things about OOo" is on the
community wiki, under PDL, then I don't have a problem with that. But
when the build instructions are under PDL, then this is a problem,
since without that no one can make effective use of a source release.
> Regardless of the extent to which we would rather be gifted such material under a permissive license grant, it is that ambition which is a problem if it blinds us to dealing with these cases in the flexible manner that this state of affairs always requires.
>
If by "flexible" you mean that we would have essential documentation
needed to make use of a release under an incompatible license, then
yes, I would urge less flexibility.
> I say support preservation of the materials where they are, loosely couple to/with them, and foster small steps to moving the boundaries in ways that serve us, the broad external community, and the will of the third parties as we mature the podling toward incubation.
>
That is fine. But I'd separate the content migration from the
procedural migrations. I think we want to immediately institute such
changes necessary to ensure that future core documentation
contributions are under a compatible license. The existing content
may move over to that license, with permission of the original
authors, where they can be identified, or replaced over time.
> - Dennis
>
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Tuesday, August 30, 2011 08:34
> To: ooo-dev@incubator.apache.org
> Subject: An example of the license problems we're going to face
>
> As far as I know, all Apache projects have source releases. Some also
> have binary releases. I expect we will have both.
>
> OOo, since it was LGPL, could assume a copyleft orientation for
> source, documentation, templates, binaries, etc. Everything was
> copyleft, meaning if someone modified these materials, any
> distributions of it must be accompanied by the changes, and have the
> same copyleft license.
>
> With Apache, our releases are under the Apache 2.0 license. This is
> not a copyleft license. Apache code can be modified and republished
> without making the changes also available under an open source
> license.
>
> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
> Sun/Oracle had rights to under the various forms of their contributor
> agreements. This predominantly covered source code. But it did not
> cover project documentation. Documentation was generally under the
> copyleft Public Documentation License (PDL) or CC BY-A.
>
> This is going to cause us problems. A specific example. The main
> build instructions for OpenOffice.org are in a PDL-licensed Building
> Guide document [1]. This means that our own source code releases are
> unable to be accompanied by instructions on how to build the product.
> This is quite odd, compared to most other projects, say SVN, which
> include build instructions with their source releases [2].
>
> Of course, we can have a README file in our source releases that
> points to the PDL Building Guide. That may seem to solve the problem,
> but it really doesn't. We've now placed copyleft restrictions on
> downstream consumers that might want to modify the source code, and as
> part of those modifications also modify the build instructions. We've
> now placed additional constraints on them, beyond Apache 2.0, for how
> they can use the release.
>
> This is not an isolated occurrence. If I'm reading this [3]
> correctly, there are thousands of pieces of documentation that are
> under PDL. This is not all "community" or "wiki" stuff that we can
> just pass off as something that loosely affiliated folks do in an
> uncoordinated fashion, without joining the project, under a license of
> their preference This is the core blood of the project, how to use
> the product, how to build the product, how to test the product, how to
> customize the product, etc.
>
> As I've said before, we can't change the past. But we can prevent
> repeating past mistakes. We need to ensure that in the future that
> the core project documentation is developed and maintained under the
> ALv2 license. A good question to ask is this: If a downstream
> consumer wanted to use our source release, to build and distribute a
> customized version of AOOo, could they do that successfully? Or would
> they be severely constrained and find that our releases are actually
> missing essential documentation files without which AOOo cannot be
> used?
>
> -Rob
>
>
> [1] http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide
> [2] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
> [3] http://ooo-wiki.apache.org/wiki/Category:PDL_License
>
>
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think these are non-problems in the sense that we do not have the rights to do anything with works not under the SGA beyond what are provided for in the notices and licenses on those works.
If we want anything else, we need to refer to them (as you observe), request a grant of some form, request republishing of those works under a friendly license by their authors, or produce our own non-infringing works.
>From our perspective, these are all third party works and we simply have to deal with it, just like we deal with third-party code in the OpenOffice.org code base that is not acceptable in an ASF release.
This is an ordinary situation. It is not a podling IP clearance problem the way that the initial code contribution is.
Regardless of the extent to which we would rather be gifted such material under a permissive license grant, it is that ambition which is a problem if it blinds us to dealing with these cases in the flexible manner that this state of affairs always requires.
I say support preservation of the materials where they are, loosely couple to/with them, and foster small steps to moving the boundaries in ways that serve us, the broad external community, and the will of the third parties as we mature the podling toward incubation.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Tuesday, August 30, 2011 08:34
To: ooo-dev@incubator.apache.org
Subject: An example of the license problems we're going to face
As far as I know, all Apache projects have source releases. Some also
have binary releases. I expect we will have both.
OOo, since it was LGPL, could assume a copyleft orientation for
source, documentation, templates, binaries, etc. Everything was
copyleft, meaning if someone modified these materials, any
distributions of it must be accompanied by the changes, and have the
same copyleft license.
With Apache, our releases are under the Apache 2.0 license. This is
not a copyleft license. Apache code can be modified and republished
without making the changes also available under an open source
license.
The Oracle SGA puts the Apache 2.0 license on the files from OOo that
Sun/Oracle had rights to under the various forms of their contributor
agreements. This predominantly covered source code. But it did not
cover project documentation. Documentation was generally under the
copyleft Public Documentation License (PDL) or CC BY-A.
This is going to cause us problems. A specific example. The main
build instructions for OpenOffice.org are in a PDL-licensed Building
Guide document [1]. This means that our own source code releases are
unable to be accompanied by instructions on how to build the product.
This is quite odd, compared to most other projects, say SVN, which
include build instructions with their source releases [2].
Of course, we can have a README file in our source releases that
points to the PDL Building Guide. That may seem to solve the problem,
but it really doesn't. We've now placed copyleft restrictions on
downstream consumers that might want to modify the source code, and as
part of those modifications also modify the build instructions. We've
now placed additional constraints on them, beyond Apache 2.0, for how
they can use the release.
This is not an isolated occurrence. If I'm reading this [3]
correctly, there are thousands of pieces of documentation that are
under PDL. This is not all "community" or "wiki" stuff that we can
just pass off as something that loosely affiliated folks do in an
uncoordinated fashion, without joining the project, under a license of
their preference This is the core blood of the project, how to use
the product, how to build the product, how to test the product, how to
customize the product, etc.
As I've said before, we can't change the past. But we can prevent
repeating past mistakes. We need to ensure that in the future that
the core project documentation is developed and maintained under the
ALv2 license. A good question to ask is this: If a downstream
consumer wanted to use our source release, to build and distribute a
customized version of AOOo, could they do that successfully? Or would
they be severely constrained and find that our releases are actually
missing essential documentation files without which AOOo cannot be
used?
-Rob
[1] http://ooo-wiki.apache.org/wiki/Documentation/Building_Guide
[2] http://svn.apache.org/repos/asf/subversion/trunk/INSTALL
[3] http://ooo-wiki.apache.org/wiki/Category:PDL_License
Re: An example of the license problems we're going to face
Posted by Jean Weber <je...@gmail.com>.
On Wed, Aug 31, 2011 at 02:45, Dennis E. Hamilton
<de...@acm.org> wrote:
> I believe that is correct. I have seen Jean Hollis Weber mention CC-BY-SA, but I recall only seeing CC-BY (with GPL as dual license). That is continuing with the LibreOffice editions, which are under GPL 3+ and CC-BY 3+.
In the English user guides, there is one chapter in the Calc Guide (Ch
8, on DataPilot) that is CC-BY-SA because it is a (now heavily
modified) translation of a German document that had the CC-BY-SA
license. All other chapters are CC-BY (with, as you note, GPL as dual
license).
I believe that some of the docs in other languages (such as German)
may be under CC-BY-SA, but I don't know; I've never had any need to
find out.
--Jean
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I believe that is correct. I have seen Jean Hollis Weber mention CC-BY-SA, but I recall only seeing CC-BY (with GPL as dual license). That is continuing with the LibreOffice editions, which are under GPL 3+ and CC-BY 3+.
There is an odd trip-wire in CC-BY that has been there since CC-BY 2.0, having to do with a requirement on delivery by means having DRM constraints, but that has not impeded viewing CC-BY as Category A.
In any case those are all third-party works and we get to deal with them accordingly.
- Dennis
-----Original Message-----
From: Frank Peters [mailto:fpe.mlists@googlemail.com]
Sent: Tuesday, August 30, 2011 09:01
To: ooo-dev@incubator.apache.org
Cc: Rob Weir
Subject: Re: An example of the license problems we're going to face
[...]
> With Apache, our releases are under the Apache 2.0 license. This is
> not a copyleft license. Apache code can be modified and republished
> without making the changes also available under an open source
> license.
>
> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
> Sun/Oracle had rights to under the various forms of their contributor
> agreements. This predominantly covered source code. But it did not
> cover project documentation. Documentation was generally under the
> copyleft Public Documentation License (PDL) or CC BY-A.
IIRC CC licensed docs are under CC-BY, not CC-BY-SA,
hence not copylefted, see
http://ooo-wiki.apache.org/wiki/Category:CC-BY_License
> This is going to cause us problems. A specific example. The main
> build instructions for OpenOffice.org are in a PDL-licensed Building
> Guide document [1]. This means that our own source code releases are
> unable to be accompanied by instructions on how to build the product.
> This is quite odd, compared to most other projects, say SVN, which
> include build instructions with their source releases [2].
We could just rewrite the building guide and put it under AL.
[...]
> As I've said before, we can't change the past. But we can prevent
> repeating past mistakes. We need to ensure that in the future that
In the past, this was no mistake but a prerequisite for docs.
> the core project documentation is developed and maintained under the
> ALv2 license.
I thought this was a given anyway?
As to user docs produced by the ODFAuthors we need to ask them to
dual-license as they did for OOo, but I am not sure if their
current practice to publish under CC-BY would be sufficient anyway
(see above).
Frank
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@robweir.com>.
On Tue, Aug 30, 2011 at 1:15 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Let me get this straight,
>
> I store all of my OpenOffice.org materials, downloaded user guides and whatnot on an encrypted hard drive, and that places me in violation of the CC-BY?
>
> That's ridiculous.
>
That would be ridiculous. But if you read the license you would see
that the issue is with publication. So if you published the work on a
device that had tamper proof storage (sealed storage) that prevented
access to the files accepted through a given trusted process, then
that would be a violation.
> Since none of the materials we are talking about, made available under CC-BY, are considered secret, why do we care that a secure system might include such materials in its storage. Those are black holes and we will not know nor ever care that they happen to have thrown digital copies of OpenOffice.org User Guides in there along with all of the proprietary digital materials for operation and support for those highly-secured systems (if they actually do comingle non-secret materials that way).
>
Again, the issue is with publication, not with what someone does in
the privacy of their own office.
> There is no problem. This is an ordinary situation. The only problem is wanting such materials contributed to the Apache OpenOffice.org project under ALv2 and being unwilling to tolerate that some good material is not so available and will probably continue to not be so available no matter what our desires are in the matter.
>
This is not an ordinary situation. Show me another Apache project,
out of the 100+ out there, where the build instructions cannot be
included in their own source releases, because of license
incompatibility. This is not normal.
> When push comes to shove (and we are not anywhere close to that), we can work around the same way we work around in order to IP sanitize the code base. There's no reason to make this an urgent situation and front-load an already-struggling podling.
>
A light goes on. Thank you. That is what I've been saying.
Fortunately, the people who work predominately on documentation are
not the same as the people who work predominately on the source code,
so these can be parallel activities.
> - Dennis
>
> -----Original Message-----
> From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
> Sent: Tuesday, August 30, 2011 09:53
> To: ooo-dev@incubator.apache.org
> Subject: Re: An example of the license problems we're going to face
>
> On Tue, Aug 30, 2011 at 12:41 PM, Simon Phipps <si...@webmink.com> wrote:
>> On Tue, Aug 30, 2011 at 5:39 PM, Rob Weir <ro...@apache.org> wrote:
>>
>>> On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
>>> > On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
>>> >
>>> >> Suppose someone wants to take parts of
>>> >> the AOOo code, along with the associated documentation, and create an
>>> >> iPhone app from it. The ALv2 would permit them to do this with the
>>> >> source code, but CC-BY 3.0 would not allow the same for the
>>> >> documentation. Similarly, one could not take the documentation, add
>>> >> value to with additional content, and then sell it for $0.99 for the
>>> >> Amazon Kindle.
>>> >>
>>> >
>>> > Please can you explain why you believe this to be so?
>>> >
>>>
>>> "You may not impose any effective technological measures on the Work
>>> that restrict the ability of a recipient of the Work from You to
>>> exercise the rights granted to that recipient under the terms of the
>>> License."
>>>
>>> IANAL, but that was the clause that got attention on legal-discuss
>>> when reviewing CC-BY 3.0.
>>>
>>>
>> Ah, so Kindle-specific. Thanks.
>>
>
> Not really. That is the consumer side of it, certainly. But the
> application of "sealed storage' goes far beyond consumer applications.
> For high security applications, for example, you might want to
> restrict access to applications and associated static data files.
> Interestingly today there are reports of the Australian Department of
> Defense doing a trial of OpenOffice.org They would probably disagree
> with any assertion that only book publishers have an interest in such
> "technological measures".
>
>
>> S.
>>
>
>
Re: An example of the license problems we're going to face
Posted by Eike Rathke <oo...@erack.de>.
Hi Dennis,
On Tuesday, 2011-08-30 10:15:06 -0700, Dennis E. Hamilton wrote:
> Let me get this straight,
>
> I store all of my OpenOffice.org materials, downloaded user guides and whatnot on an encrypted hard drive, and that places me in violation of the CC-BY?
>
> That's ridiculous.
What gives you this impression? You as the recipient of the work can do
whatever you want with the work, including storing it on an encrypted
drive. You still have the right to decrypt your hard drive and use,
study, modify and pass along the work.
This is totally different with Kindle and such.
Eike
--
PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Let me get this straight,
I store all of my OpenOffice.org materials, downloaded user guides and whatnot on an encrypted hard drive, and that places me in violation of the CC-BY?
That's ridiculous.
Since none of the materials we are talking about, made available under CC-BY, are considered secret, why do we care that a secure system might include such materials in its storage. Those are black holes and we will not know nor ever care that they happen to have thrown digital copies of OpenOffice.org User Guides in there along with all of the proprietary digital materials for operation and support for those highly-secured systems (if they actually do comingle non-secret materials that way).
There is no problem. This is an ordinary situation. The only problem is wanting such materials contributed to the Apache OpenOffice.org project under ALv2 and being unwilling to tolerate that some good material is not so available and will probably continue to not be so available no matter what our desires are in the matter.
When push comes to shove (and we are not anywhere close to that), we can work around the same way we work around in order to IP sanitize the code base. There's no reason to make this an urgent situation and front-load an already-struggling podling.
- Dennis
-----Original Message-----
From: rabastus@gmail.com [mailto:rabastus@gmail.com] On Behalf Of Rob Weir
Sent: Tuesday, August 30, 2011 09:53
To: ooo-dev@incubator.apache.org
Subject: Re: An example of the license problems we're going to face
On Tue, Aug 30, 2011 at 12:41 PM, Simon Phipps <si...@webmink.com> wrote:
> On Tue, Aug 30, 2011 at 5:39 PM, Rob Weir <ro...@apache.org> wrote:
>
>> On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
>> > On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
>> >
>> >> Suppose someone wants to take parts of
>> >> the AOOo code, along with the associated documentation, and create an
>> >> iPhone app from it. The ALv2 would permit them to do this with the
>> >> source code, but CC-BY 3.0 would not allow the same for the
>> >> documentation. Similarly, one could not take the documentation, add
>> >> value to with additional content, and then sell it for $0.99 for the
>> >> Amazon Kindle.
>> >>
>> >
>> > Please can you explain why you believe this to be so?
>> >
>>
>> "You may not impose any effective technological measures on the Work
>> that restrict the ability of a recipient of the Work from You to
>> exercise the rights granted to that recipient under the terms of the
>> License."
>>
>> IANAL, but that was the clause that got attention on legal-discuss
>> when reviewing CC-BY 3.0.
>>
>>
> Ah, so Kindle-specific. Thanks.
>
Not really. That is the consumer side of it, certainly. But the
application of "sealed storage' goes far beyond consumer applications.
For high security applications, for example, you might want to
restrict access to applications and associated static data files.
Interestingly today there are reports of the Australian Department of
Defense doing a trial of OpenOffice.org They would probably disagree
with any assertion that only book publishers have an interest in such
"technological measures".
> S.
>
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@robweir.com>.
On Tue, Aug 30, 2011 at 12:41 PM, Simon Phipps <si...@webmink.com> wrote:
> On Tue, Aug 30, 2011 at 5:39 PM, Rob Weir <ro...@apache.org> wrote:
>
>> On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
>> > On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
>> >
>> >> Suppose someone wants to take parts of
>> >> the AOOo code, along with the associated documentation, and create an
>> >> iPhone app from it. The ALv2 would permit them to do this with the
>> >> source code, but CC-BY 3.0 would not allow the same for the
>> >> documentation. Similarly, one could not take the documentation, add
>> >> value to with additional content, and then sell it for $0.99 for the
>> >> Amazon Kindle.
>> >>
>> >
>> > Please can you explain why you believe this to be so?
>> >
>>
>> "You may not impose any effective technological measures on the Work
>> that restrict the ability of a recipient of the Work from You to
>> exercise the rights granted to that recipient under the terms of the
>> License."
>>
>> IANAL, but that was the clause that got attention on legal-discuss
>> when reviewing CC-BY 3.0.
>>
>>
> Ah, so Kindle-specific. Thanks.
>
Not really. That is the consumer side of it, certainly. But the
application of "sealed storage' goes far beyond consumer applications.
For high security applications, for example, you might want to
restrict access to applications and associated static data files.
Interestingly today there are reports of the Australian Department of
Defense doing a trial of OpenOffice.org They would probably disagree
with any assertion that only book publishers have an interest in such
"technological measures".
> S.
>
Re: An example of the license problems we're going to face
Posted by Simon Phipps <si...@webmink.com>.
On Tue, Aug 30, 2011 at 5:39 PM, Rob Weir <ro...@apache.org> wrote:
> On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
> > On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
> >
> >> Suppose someone wants to take parts of
> >> the AOOo code, along with the associated documentation, and create an
> >> iPhone app from it. The ALv2 would permit them to do this with the
> >> source code, but CC-BY 3.0 would not allow the same for the
> >> documentation. Similarly, one could not take the documentation, add
> >> value to with additional content, and then sell it for $0.99 for the
> >> Amazon Kindle.
> >>
> >
> > Please can you explain why you believe this to be so?
> >
>
> "You may not impose any effective technological measures on the Work
> that restrict the ability of a recipient of the Work from You to
> exercise the rights granted to that recipient under the terms of the
> License."
>
> IANAL, but that was the clause that got attention on legal-discuss
> when reviewing CC-BY 3.0.
>
>
Ah, so Kindle-specific. Thanks.
S.
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@robweir.com>.
On Tue, Aug 30, 2011 at 12:57 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Yes, it did receive attention. It does not seem to have exercised the folks on legal-discuss over-much. The question was whether this, being noticed in CC-BY 3.0 was a blocker, but it turns out the provision has been in there since CC-BY 2.0 and those licenses are still on the good-guy list, AFAIK.
>
> However, the way a DRM delivery satisfies the CC-BY requirement is to provide notice that the work is available under a CC-BY license and identify its source in non-DRM form.
>
> This seems most bothersome for sound recordings and works in the performing arts, multi-media, etc., where the DRM delivers a performance. The Kindle example is easy, because the original copyright and license information can be visibly included as part of the work. If Amazon worked around that, they would void their use of the work under CC-BY. I suppose on videos, it could go right up there with the FBI and Interpol notices.
>
> I think this is FUD, Rob.
>
Not at all. I can take any Apache project, modify it and publish it,
without making any source code available. There is no requirement
that I make it possible to copy my application or link to the source
code. This has nothing to do with the irrelevancies like performance
of sound or video recordings. This is the essence of the Apache
License. I should be able to take Apache code, use it on a Tivo,
protected by access restrictions, or embedded on a USB stick protected
with password. I should be able to write it into soft ram for a
quick-booting netbook. We should not setting additional constraints,
above ALv2, that restrict the innovations that downstream consumers
might want to implement.
> - Dennis
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Tuesday, August 30, 2011 09:39
> To: ooo-dev@incubator.apache.org
> Subject: Re: An example of the license problems we're going to face
>
> On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
>> On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
>>
>>> Suppose someone wants to take parts of
>>> the AOOo code, along with the associated documentation, and create an
>>> iPhone app from it. The ALv2 would permit them to do this with the
>>> source code, but CC-BY 3.0 would not allow the same for the
>>> documentation. Similarly, one could not take the documentation, add
>>> value to with additional content, and then sell it for $0.99 for the
>>> Amazon Kindle.
>>>
>>
>> Please can you explain why you believe this to be so?
>>
>
> "You may not impose any effective technological measures on the Work
> that restrict the ability of a recipient of the Work from You to
> exercise the rights granted to that recipient under the terms of the
> License."
>
> IANAL, but that was the clause that got attention on legal-discuss
> when reviewing CC-BY 3.0.
>
> -Rob
>
>
>> S.
>>
>
>
RE: An example of the license problems we're going to face
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Yes, it did receive attention. It does not seem to have exercised the folks on legal-discuss over-much. The question was whether this, being noticed in CC-BY 3.0 was a blocker, but it turns out the provision has been in there since CC-BY 2.0 and those licenses are still on the good-guy list, AFAIK.
However, the way a DRM delivery satisfies the CC-BY requirement is to provide notice that the work is available under a CC-BY license and identify its source in non-DRM form.
This seems most bothersome for sound recordings and works in the performing arts, multi-media, etc., where the DRM delivers a performance. The Kindle example is easy, because the original copyright and license information can be visibly included as part of the work. If Amazon worked around that, they would void their use of the work under CC-BY. I suppose on videos, it could go right up there with the FBI and Interpol notices.
I think this is FUD, Rob.
- Dennis
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Tuesday, August 30, 2011 09:39
To: ooo-dev@incubator.apache.org
Subject: Re: An example of the license problems we're going to face
On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
> On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
>
>> Suppose someone wants to take parts of
>> the AOOo code, along with the associated documentation, and create an
>> iPhone app from it. The ALv2 would permit them to do this with the
>> source code, but CC-BY 3.0 would not allow the same for the
>> documentation. Similarly, one could not take the documentation, add
>> value to with additional content, and then sell it for $0.99 for the
>> Amazon Kindle.
>>
>
> Please can you explain why you believe this to be so?
>
"You may not impose any effective technological measures on the Work
that restrict the ability of a recipient of the Work from You to
exercise the rights granted to that recipient under the terms of the
License."
IANAL, but that was the clause that got attention on legal-discuss
when reviewing CC-BY 3.0.
-Rob
> S.
>
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@apache.org>.
On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <si...@webmink.com> wrote:
> On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
>
>> Suppose someone wants to take parts of
>> the AOOo code, along with the associated documentation, and create an
>> iPhone app from it. The ALv2 would permit them to do this with the
>> source code, but CC-BY 3.0 would not allow the same for the
>> documentation. Similarly, one could not take the documentation, add
>> value to with additional content, and then sell it for $0.99 for the
>> Amazon Kindle.
>>
>
> Please can you explain why you believe this to be so?
>
"You may not impose any effective technological measures on the Work
that restrict the ability of a recipient of the Work from You to
exercise the rights granted to that recipient under the terms of the
License."
IANAL, but that was the clause that got attention on legal-discuss
when reviewing CC-BY 3.0.
-Rob
> S.
>
Re: An example of the license problems we're going to face
Posted by Simon Phipps <si...@webmink.com>.
On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <ro...@apache.org> wrote:
> Suppose someone wants to take parts of
> the AOOo code, along with the associated documentation, and create an
> iPhone app from it. The ALv2 would permit them to do this with the
> source code, but CC-BY 3.0 would not allow the same for the
> documentation. Similarly, one could not take the documentation, add
> value to with additional content, and then sell it for $0.99 for the
> Amazon Kindle.
>
Please can you explain why you believe this to be so?
S.
Re: An example of the license problems we're going to face
Posted by Rob Weir <ro...@apache.org>.
On Tue, Aug 30, 2011 at 12:00 PM, Frank Peters
<fp...@googlemail.com> wrote:
> [...]
>
>> With Apache, our releases are under the Apache 2.0 license. This is
>> not a copyleft license. Apache code can be modified and republished
>> without making the changes also available under an open source
>> license.
>>
>> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
>> Sun/Oracle had rights to under the various forms of their contributor
>> agreements. This predominantly covered source code. But it did not
>> cover project documentation. Documentation was generally under the
>> copyleft Public Documentation License (PDL) or CC BY-A.
>
> IIRC CC licensed docs are under CC-BY, not CC-BY-SA,
> hence not copylefted, see
> http://ooo-wiki.apache.org/wiki/Category:CC-BY_License
>
You are correct. ODFAuthors is dual licensed, including CC-BY 3.0.
However, CC-BY 3.0 is on the approved list for Apache. I raised this
to the legal-discuss list a while ago for review. It is still
unresolved. My impression from following that discussion was that
there were some issues with CC-BY 3.0, in particular the anti-DRM
provision. In any case, I don't see why we want to be clever with
license choice for future documentation contributions. We should be
seeking ALv2 for everything.
>> This is going to cause us problems. A specific example. The main
>> build instructions for OpenOffice.org are in a PDL-licensed Building
>> Guide document [1]. This means that our own source code releases are
>> unable to be accompanied by instructions on how to build the product.
>> This is quite odd, compared to most other projects, say SVN, which
>> include build instructions with their source releases [2].
>
> We could just rewrite the building guide and put it under AL.
>
Yes, that is probably true. But then what do we do to ensure that it
remains under ALv2, i.e., that no one contributes to it under other
licenses? It is similar to the code cleanliness issue: we can accept
small contributions (patches) under ALv2, and larger contributions
with a signed iCLA.
> [...]
>
>> As I've said before, we can't change the past. But we can prevent
>> repeating past mistakes. We need to ensure that in the future that
>
> In the past, this was no mistake but a prerequisite for docs.
>
True, at the time, when OOo was only LGPL it was a reasonable choice.
My point is that the situation is now different and the prior choices
will lead to problems.
>> the core project documentation is developed and maintained under the
>> ALv2 license.
>
> I thought this was a given anyway?
>
I'm not seeing this as generally acknowledged. I'm hearing some
project members argue that the community wiki should remain outside of
the project, not subject to ALv2 and committer review. That's why I'm
raising this point, with a concrete example of the build instructions.
The wiki was not used just for random community contributions. It
was used pervasively throughout the project, for core functions as
well.
Just as we are reviewing the source code to remove/replace
incompatibly licensed software libraries, we should be thinking of the
documentation set that should be part of a release, and ensure that we
have a set that we may include in a release.
> As to user docs produced by the ODFAuthors we need to ask them to
> dual-license as they did for OOo, but I am not sure if their
> current practice to publish under CC-BY would be sufficient anyway
> (see above).
>
As mentioned, the CC-BY 3.0 license was under review on the
legal-discuss list. But some issues were raised with the anti-DRM
provisions. ALv2 does not have that restriction. A hypothetical for
why this could be important: Suppose someone wants to take parts of
the AOOo code, along with the associated documentation, and create an
iPhone app from it. The ALv2 would permit them to do this with the
source code, but CC-BY 3.0 would not allow the same for the
documentation. Similarly, one could not take the documentation, add
value to with additional content, and then sell it for $0.99 for the
Amazon Kindle. Things like that. Although CC-BY is not copyleft, it
does have some restrictions that put constraints on users that go
beyond ALv2.
> Frank
>
Re: An example of the license problems we're going to face
Posted by Jean Weber <je...@gmail.com>.
On Wed, Aug 31, 2011 at 02:00, Frank Peters <fp...@googlemail.com> wrote:
>
>> As I've said before, we can't change the past. But we can prevent
>> repeating past mistakes. We need to ensure that in the future that
>
> In the past, this was no mistake but a prerequisite for docs.
>
>> the core project documentation is developed and maintained under the
>> ALv2 license.
>
> I thought this was a given anyway?
>
> As to user docs produced by the ODFAuthors we need to ask them to
> dual-license as they did for OOo, but I am not sure if their
> current practice to publish under CC-BY would be sufficient anyway
> (see above).
>
If user guides are considered to be "core documentation", then their
licensing may be an issue. If they are not "core", then it isn't. IMO
they are not "core" but we had that discussion before and IIRC Rob's
view was that they are core.
As I've noted before, tracking down past contributors to get agreement
on changing the license of existing material would be difficult and in
some cases impossible. Given that the existing material is the obvious
place to start when producing user guides updated/amended for AOO,
then the license of that existing material is relevant. AFAIK, we
can't just take the material, revise it, and change the license; so
the books would need to be completely rewritten. IMO that would be
very impractical, because the available people barely keep up with
minor updates.
BTW, I think the user guides could do with a major overhaul, and if
enough skilled technical writers turned up to do that job, I would be
absolutely delighted. Alas, I can't see that happening, so all I can
see (at least for the next year) is either a minor update to the
existing books (under a compatible, but non-Apache, license) or... no
books at all.
--Jean
Re: An example of the license problems we're going to face
Posted by Frank Peters <fp...@googlemail.com>.
[...]
> With Apache, our releases are under the Apache 2.0 license. This is
> not a copyleft license. Apache code can be modified and republished
> without making the changes also available under an open source
> license.
>
> The Oracle SGA puts the Apache 2.0 license on the files from OOo that
> Sun/Oracle had rights to under the various forms of their contributor
> agreements. This predominantly covered source code. But it did not
> cover project documentation. Documentation was generally under the
> copyleft Public Documentation License (PDL) or CC BY-A.
IIRC CC licensed docs are under CC-BY, not CC-BY-SA,
hence not copylefted, see
http://ooo-wiki.apache.org/wiki/Category:CC-BY_License
> This is going to cause us problems. A specific example. The main
> build instructions for OpenOffice.org are in a PDL-licensed Building
> Guide document [1]. This means that our own source code releases are
> unable to be accompanied by instructions on how to build the product.
> This is quite odd, compared to most other projects, say SVN, which
> include build instructions with their source releases [2].
We could just rewrite the building guide and put it under AL.
[...]
> As I've said before, we can't change the past. But we can prevent
> repeating past mistakes. We need to ensure that in the future that
In the past, this was no mistake but a prerequisite for docs.
> the core project documentation is developed and maintained under the
> ALv2 license.
I thought this was a given anyway?
As to user docs produced by the ODFAuthors we need to ask them to
dual-license as they did for OOo, but I am not sure if their
current practice to publish under CC-BY would be sufficient anyway
(see above).
Frank