Repository: incubator-brooklyn Updated Branches: refs/heads/master c4ca5b683 -> 7b97cee1e
Add Licensing Considerations page to the developer's guide Project: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/repo Commit: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/commit/5ae0d4ec Tree: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/tree/5ae0d4ec Diff: http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/diff/5ae0d4ec Branch: refs/heads/master Commit: 5ae0d4ec830119f613b8915c1bdaa7e097a306d5 Parents: 4338a8f Author: Richard Downer <[email protected]> Authored: Thu Apr 16 15:49:56 2015 +0100 Committer: Richard Downer <[email protected]> Committed: Thu Apr 16 16:01:00 2015 +0100 ---------------------------------------------------------------------- docs/guide/dev/code/licensing.md | 116 ++++++++++++++++++++++++++++++++++ docs/guide/dev/index.md | 1 + 2 files changed, 117 insertions(+) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/5ae0d4ec/docs/guide/dev/code/licensing.md ---------------------------------------------------------------------- diff --git a/docs/guide/dev/code/licensing.md b/docs/guide/dev/code/licensing.md new file mode 100644 index 0000000..e2a7ef5 --- /dev/null +++ b/docs/guide/dev/code/licensing.md @@ -0,0 +1,116 @@ +--- +title: License Considerations +layout: website-normal +--- + +The Apache Software Foundation, quite rightly, place a high standard on code provenance and license compliance. The +Apache license is flexible and compatible with many other types of license, meaning there is generally little problem +with incorporating other open source works into Brooklyn (with GPL being the notable exception). However diligence is +required to ensure that the project is legally sound, and third parties are rightfully credited where appropriate. + +This page is an interpretation of the [Apache Legal Previously Asked Questions](http://www.apache.org/legal/resolved.html) +page as it specifically applies to the Brooklyn project, such as how we organise our code and the releases that we make. +However this page is not authoritative; if there is any conflict between this page and the Previously Asked Questions or +other Apache Legal authority, they will take precedence over this page. + +If you have any doubt, please ask on the Brooklyn mailing list, and/or the Apache Legal mailing list. + + +What code licenses can we bundle? +--------------------------------- + +Apache Legal maintains the ["Category A" list](http://www.apache.org/legal/resolved.html#category-a), which is a list +of licenses that are compatible with the Apache License; that is, code under these licenses can be imported into +Brooklyn without violating Brooklyn's Apache License nor the code's original license (subject to correctly modifying +the `LICENSE` and/or `NOTICE` files; see below). + +Apache Legal also maintain the ["Category X" list](http://www.apache.org/legal/resolved.html#category-x). Code licensed +under a Category X license **cannot** be imported into Brooklyn without violating either Brooklyn's Apache license or +the code's original license. + +There is also a ["Category B" list](http://www.apache.org/legal/resolved.html#category-b), which are licenses that are +compatible with the Apache license only under certain circumstances. In practice, this means that we can declare a +dependency on a library licensed under a Category B license, and bundle the binary build of the library in our binary +builds, but we cannot import its source code into the Brooklyn codebase. + +If the code you are seeking to import does not appear on any of these lists, check to see if the license content is the +same as a known license. For example, many projects actually use a BSD license but do not label it as "The BSD License". +If you are still not certain about the license, please ask on the Brooklyn mailing list, and/or the Apache Legal mailing +list. + + +About LICENSE and NOTICE files +------------------------------ + +Apache Legal requires that *each* artifact that the project releases contains a `LICENSE` and `NOTICE` file that is +*accurate for the contents of that artifact*. This means that, potentially, **every artifact that Brooklyn releases may +contain a different `LICENSE` and `NOTICE` file**. In practice, it's not usually that complicated and there are only a +few variations of these files needed. + +Furthermore, *accurate* `LICENSE` and `NOTICE` files means that it correctly attributes the contents of the artifact, +and it does not contain anything unnecessary. This provision is what prevents us creating a mega LICENSE file and using +it in every single artifact we release, because in many cases it will contain information that is not relevant to an +artifact. + +What is a correct `LICENSE` and `NOTICE` file? + +* A correct `LICENSE` file is one that contains the text of the licence of any part of the code. The Apache Software + License V2 will naturally be the first part of this file, as it's the license which we use for all the original code + in Brooklyn. If some *Category A* licensed third-party code is bundled with this artifact, then the `LICENSE` file + should identify what the third-party code is, and include a copy of its license. For example, if jquery is bundled + with a web app, the `LICENSE` file would include a note jquery.js, its copyright and its license (MIT), and include a + full copy of the MIT license. +* A correct `NOTICE` file contains notices required by bundled third-party code above and beyond that which we have + already noted in `LICENSE`. In practice modifying `NOTICE` is rarely required beyond the initial note about Apache + Brooklyn. See [What Are Required Third-party Notices?](http://www.apache.org/legal/resolved.html#required-third-party-notices) + for more information + + +Applying LICENSE and NOTICE files to Brooklyn +--------------------------------------------- + +When the Brooklyn project makes a release, we produce and release the following types of artifacts: + +1. One source release artifact +2. One binary release artifact +3. A large number of Maven release artifacts + +Therefore, our source release, our binary release, and every one of our Maven release artifacts, must **each** have +their own, individually-tailored, `LICENSE` and `NOTICE` files. + +### Maven artifacts + +Each Maven module will generally produce a JAR file from code under `src/main`, and a JAR file from code under +`src/test`. (There are some exceptions which may produce different artifacts.) + +If the contents of the module are purely Apache Brooklyn original code, and the outputs are JAR files, then *no action +is required*. The default build process will incorporate a general-purpose `LICENSE` and `NOTICE` file into all built +JAR files. `LICENSE` will contain just a copy of the Apache Software License v2, and `NOTICE` will contain just the +module's own notice fragment. + +However you will need to take action if either of these conditions are true: + +* the module produces an artifact that is **not** a JAR file - for example, the jsgui project produces a WAR file; +* the module bundles third-party code that requires a change to `LICENSE` and/or `NOTICE`. + +In this case you will need to disable the automatic insertion of `LICENSE` and `NOTICE` and insert your own versions +instead. + +For an example of a JAR file with customized `LICENSE`/`NOTICE` files, refer to the `usage/cli` project. +For an example of a WAR file with customized `LICENSE`/`NOTICE` files, refer to the `usage/jsgui` project. + +### The source release + +In practice, the source release contains nothing that isn't in the individual produced Maven artifacts (the obvious +difference about it being source instead of binary isn't relevant). Therefore, the source release `LICENSE` and `NOTICE` +can be considered to be the union of every Maven artifact's `LICENSE` and `NOTICE`. The amalgamated files are kept in +the root of the repository. + +### The binary release + +This is the trickiest one to get right. The binary release includes everything that is in the source and Maven releases, +**plus every Java dependency of the project**. This means that the binary release is pulling in many additional items, +each of which have their own license, and which will therefore impact on `LICENSE` and `NOTICE`. + +Therefore you must inspect every file that is present in the binary distribution, ascertain its license status, and +ensure that `LICENSE` and `NOTICE` are correct. http://git-wip-us.apache.org/repos/asf/incubator-brooklyn/blob/5ae0d4ec/docs/guide/dev/index.md ---------------------------------------------------------------------- diff --git a/docs/guide/dev/index.md b/docs/guide/dev/index.md index a4f6ef9..95f278e 100644 --- a/docs/guide/dev/index.md +++ b/docs/guide/dev/index.md @@ -10,6 +10,7 @@ children: - code/ - { link: "http://github.com/apache/incubator-brooklyn";, title: "GitHub" } - code/tests.md +- code/licensing.md - tips/ - tips/logging.md - tips/debugging-remote-brooklyn.md
