License Considerations

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 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, 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. 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, 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 quite that complicated and there is a lot of automation to simplify places where there is complexity.

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 where what is in LICENSE is not sufficient. Although What Are Required Third-party Notices? suggests it is rarely necessary to modify this, we have found that most common licenses, including MIT, BSD, and Apache require attribution. This could be done by including every variant of every license where only the copyright clause is changed, but the resulting mega file (particularly for our binary dist) becomes hard to use: a reader would need to inspect manually the license to tell whether it is -- in most cases -- the stock MIT / BSD license etc. For this reason we put all attributions in NOTICE where a standard LICENSE is used.

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.

To some extent, this is automated, using scripts in brooklyn-dist/dist/licensing; but this must be manually run, and wherever source code is included or a project has insufficient information in its POM, you'll need to add project-specific metadata, as per the README.md in that project's folder.

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 brooklyn-core/server-cli project. For an example of a WAR file with customized LICENSE/NOTICE files, refer to the brooklyn-ui project.

In both these cases the scripts in brooklyn-dist/dist/licensing will generate them.

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. Again our scripts do this for us.

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. Thankfully, again, our scripts do this.