Question about licensing of the project

[JoanaPedrosoDiconium]

Hello!

As far as I can see in Maven Central, AspectJ Weaver is licensed under an EPL-2.0.

We are using spring-data-starter which uses your project and our legal department raised an issue that there's one class in AspectJ Weaver project that still uses the Apache-1.1 license which is creating some problems since apparently from a legal perspective Apache-1.1 is not compatible with EPL-2.0.

Are you indeed using a different license just for this class in particular or could this be some mistake?

Thank you in advance!

Best regards
Joana Pedroso

[kriegaex]

@aclement, can you maybe enlighten us? That was way before my time. It looks as if @JoanaPedrosoDiconium might be right.

[iskaleade]

Hi @kriegaex and @aclement we also stumbled across this licensing situation. Also, it seems that it is not just one class but many files in the bcel-builder directory (e.g. "generic").

From the Apache-1.1 perspective the acknowledgement obligation seems to be met already in the AspectJ project (see also #185).

Since bcel seems to be Apache-2.0 now maybe you can find a way to relicense bcel-builder to Apache-2.0 including the original code and your contributions? The import of BCEL seems to have happened just a month before BCEL relicensed to Apache-2.0 - according to the commit history, import happened on Nov 18, 2004. Relicensing of BCEL happened Dec. 15, 2004 (see https://github.com/apache/commons-bcel/commits/master/?since=2004-11-09&until=2004-12-15) and it seems that there were no commits in between, meaning the entire original code of BCEL may most likely be used under Apache-2.0 anyways. You might just have to clarify whether all of the contributions you made under Apache-1.1 after the import may be used under Apache-2.0 as well, i.e. relicense to Apache-2.0 (potentially requires permission by whoever contributed to the AspectJ bcel-builder under Apache-1.1).

Other option might be an official exception statement with regards to the possible incompatibility caused by the acknowledgement obligation in the Apache-1.1 along the lines of "The Eclipse foundation permits you to combine EPL-2.0 licensed code of AspectJ with Apache-1.1 licensed code of bcel-builder which remains under the Apache-1.1 license" or similar - did you already have a chance to discuss this?

Thanks!

[aclement]

I'll try to find a minute to look into this.

[aclement]

Let me prefix this with the obvious, I am not a license expert :)

I've been exploring this with a bit of help from the Eclipse folks. Yes indeed the BCEL we have is Apache 1.1, but we aren't trying to hide or relicense that with an EPL-2.0 (as you say they are not compatible like that) - so effectively we are saying "Here is AspectJ, its mostly EPL-2.0 but there are some pieces under Apache 1.1 and there is an asm in there too which is under Apache-2.0". And projects can do that, as the comments above suggest (and the issues they link to) but we need the right attribution in place.

Now I need to fully check we are doing the attribution but I think we are from the discussion in #185. However, maybe it can be even more clear/explicit with appropriate SPDX entries (or something like that) placed somewhere.

If I was going to make changes - I probably wouldn't attempt to track down the committers who have contributed since the original copy in order to switch the original to Apache 2.0. Instead I would either rip out that whole module and replace it with an up to date Apache 2.0 BCEL (not trivial, but would be great fun!) or, if doing open heart surgery like that, use asm instead so we aren't utilizing two bytecode toolkits in different parts of AspectJ.

Does that all make sense?

[kriegaex]

@aclement, if you could really invest the cycles to remove BCEL in favour of ASM, this would be way out of scope of this issue, but as you brought it up already: I find it a great idea! ASM is already used as an external dependency in the build process (only package names get relocated, AFAIR) and regularly refreshed. I think, it is quite popular as far as byte code engineering tools are concerned, e.g. Byte Buddy (BB) is based on it.

It might even be an option to replace both BCEL and plain ASM by BB, because it would permit us to use its high-level API where appropriate and still leave us the option to use pure ASM, because BB carries it in its belly, also relocated to its namespace. I have done that before in a mocking tool I developed privately. It mostly used BB, but in a few situations also ASM when I needed a more low level API.