2

The ByteBuddy library (not intended for end-users, but for developpers) is distributed as a JAR file, which contains the compiled classes of ASM (https://asm.ow2.io/), licensed under the BSD 3-Clause. According to the second BSD clause, the ASM license should be included "in the documentation and/or other materials provided with the [ByteBuddy] distribution".

If the ASM license is included in the ByteBuddy JAR (a "binary"), is this sufficient to comply with the ASM license? According to BSD 3-Clause: where to place license for binary installation?, this might "fail the intention of providing user-visible attribution".

If not, should ByteBuddy be distributed instead as a zip file, containing the ByteBuddy JAR, plus "other materials", including the ASM license in a plain text file?

1

Here, the ByteBuddy library is Apache-licensed. The Apache license makes provisions for a NOTICE file that must be user-visible. The easiest way for ByteBuddy to simplify downstream compliance would be to include the ASM license notice in the NOTICE file. That way, downstream users don't have to care about the ASM license separately. The JAR can effectively be considered Apache-licensed, rather than the Apache/BSD mix that it actually is.

ByteBuddy already has a NOTICE file, but oddly it just contains a template for the Apache license dedication.

The Apache license gives the following options for showing the NOTICE file:

  • within a NOTICE text file distributed as part of the Derivative Works;
  • within the Source form or documentation, if provided along with the Derivative Works; or,
  • within a display generated by the Derivative Works, if and wherever such third-party notices normally appear.

For a library JAR, only the first two alternatives are available. Including the NOTICE within the JAR itself is a very good idea and likely already satisfies the license requirements (both Apache and BSD when the BSD notice is included in the Apache NOTICE file). However, this NOTICE should also be referenced in documentation material so that people know where to look for third party attribution notices.

Distributing the library as a ZIP that contains a JAR and documentation/notices does not provide significant value over including the license in the JAR, as a JAR already is exactly such a ZIP archive.

Downstream users that redistribute ByteBuddy will have to think about their license compliance requirements themselves. If they create applications with the library, they would likely have to show the NOTICE in the application's user interface or in documentation provided alongside the application. I do not think that relying on notices within the JAR is appropriate in an end user context. However, downstream compliance is out of scope for the ByteBuddy project itself.

The alternative that ByteBuddy seems to have chosen in the meanwhile – separately including the ASM license in the JAR – is also OK, especially since the ASM license is explicitly mentioned in the online documentation. However, centralizing all license notices into one NOTICE file would simplify downstream compliance.

For reference, you can also look at how other libraries do this. For example, the JAR for the Groovy language includes some ASM classes as well (checked in version 3.0.0-beta-3). Groovy is under the umbrella of the Apache foundation, so they should have a grip on licensing. They reference third-party projects in the NOTICE file inside the JAR, and include the third party license text in a license directory within the JAR. This is almost exactly the same approach as ByteBuddy has started using.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.