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
