Versions Compared

Old Version 1

changes.mady.by.user Rob Weir

Saved on

compared with

New Version 2

changes.mady.by.user Rob Weir

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. License categorization information is here:  http://www.apache.org/legal/resolved.htmlImage Removed
  2. Archives of the legal-discuss mailing list are here:  http://apache.markmail.org/search/legal-discuss+list:org.apache.legal-discussImage Removed
  3. Requirements for license headers and copyright notices are here:  http://www.apache.org/legal/src-headers.htmlImage Removed
  4. Requirements for Podling IP Clearance is here:  http://incubator.apache.org/guides/mentor.html#initial-ip-clearanceImage Removed
  5. Apache RAT (Release Audit Tool) is useful for verifying the licenses in our source tree:  http://incubator.apache.org/rat/Image Removed

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. This 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.