incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <...@robweir.com>
Subject Re: An example of the license problems we're going to face
Date Tue, 30 Aug 2011 17:22:56 GMT
On Tue, Aug 30, 2011 at 1:15 PM, Dennis E. Hamilton
<dennis.hamilton@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 <simon@webmink.com> wrote:
>> On Tue, Aug 30, 2011 at 5:39 PM, Rob Weir <robweir@apache.org> wrote:
>>
>>> On Tue, Aug 30, 2011 at 12:34 PM, Simon Phipps <simon@webmink.com> wrote:
>>> > On Tue, Aug 30, 2011 at 5:31 PM, Rob Weir <robweir@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.
>>
>
>

Mime
View raw message