incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject RE: An example of the license problems we're going to face
Date Tue, 30 Aug 2011 20:54:38 GMT
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: [] On Behalf Of Rob Weir
Sent: Tuesday, August 30, 2011 10:28
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
<> 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
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: [] On Behalf Of Rob Weir
> Sent: Tuesday, August 30, 2011 10:05
> To:
> 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
> <> 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 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 []
>> Sent: Tuesday, August 30, 2011 08:34
>> To:
>> 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 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]
>> [2]
>> [3]

View raw message