openoffice-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 16:45:27 GMT
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

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 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 [] 
Sent: Tuesday, August 30, 2011 08:34
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

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



View raw message