openoffice-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [CONF] Apache Community > IP Plan for Apache OpenOffice
Date Thu, 17 Nov 2011 19:13:00 GMT
Space: Apache Community (
Page: IP Plan for Apache OpenOffice (

Added by Rob Weir:
h2. 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.

h2. General Guidance

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

h2. Guidance for Source Releases

# 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.
# 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.
# 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.
# 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. This should be what our build scripts do by default.
# 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
# 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,
# 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.

h2. Guidance for Binary Releases

# In binary releases, category-b "weak copyleft" components (for example, MPL and EPL) are
# It is permissible for our binary releases to dynamically link to common "system available"
platform copyleft modules.

Change your notification preferences:

View raw message