Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

What is this page?

This page contains a consolidated summary of what we need to do for AOO.  It is based on questions asked and answered on legal-discuss, the posted Apache guidance and discussions on ooo-dev.  This page applies the guidance from these other sources and puts them into the context of OpenOffice.  Nothing on this page should contradict any other official Apache guidance or policy.   If you find information that contradicts what is on the page, then we should discuss on ooo-dev.

General Guidance

  1. License categorization information is here:
  2. Archives of the legal-discuss mailing list are here:
  3. Requirements for license headers and copyright notices are here:
  4. Requirements for Podling IP Clearance is here:
  5. Apache RAT (Release Audit Tool) is useful for verifying the licenses in our source tree:

Guidance for Source Releases

  1. Although we may think the focus of the project is on the binary release, we are required to have a source release as well.  This is required of all Apache projects.
  2. The source release may contain only ALv2 source code or code with a compatible license (MIT, BSD, etc., the "category-a" licenses).  A source release cannot contain copyleft (category-x, such as LGPL or GPL) or weak copyleft (category-b such as EPL or MPL) source.
  3. If we have source code that is not under one of the categorized licenses, we need to ask on the legal-discuss mailing list for the license to be categorized.
  4. A consumer of our source release should be able to download the source release, build it, and run OpenOffice without requiring the installation, inclusion or linkage of copyleft or weak copyleft components. Producing a copy-left-free binary should be what our build scripts do by default.
  5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL).  When this flag is used, it could trigger the automated download of such modules.  But this should require an explicit, informed choice from the user.  They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
  6. We should segregate the category-b code we use in SVN.  The current mechanism, of storing the unmodified source tarballs of the MPL components, and applying patches at build time, is acceptable,
  7. However, we need to make a better effort to offer these patches upstream.  This helps us and is also a good ecosystem thing to do.  Although the patches may not always be accepted upstream, we do need to make a good faith effort to try contributing them.
  8. We may use common copyleft tools (GNU tools, for example) at build time.  These will likely be "system available" on Linux but might be pre-req's or installed via Cygwin for Windows.  But these tools are not included in our source or binary releases. 

Guidance for Binary Releases

  1. In binary releases, category-b "weak copyleft" components (for example, MPL and EPL) are permitted
  2. It is permissible for our binary releases to dynamically link to common "system available" platform copyleft modules.
  3. A binary release, when installed, may allow the end-user to download additional extension modules, dictionaries, templates,etc., under any license.  But we should not be downloading additional components without the user's consent.