Availability of full Lombok sources in Maven Central + licence violation

[Thorsten Glaser]

Hi,

I regularily do licence analysis on dependencies, and Lombok is a
bit of a hard case, considering its… very special… build process.

As far as I could identify, Lombok JAR 1.18.18 contains code built from:

• the contents of its source JAR
• com.zwitserloot:cmdreader:1.2 (shaded into the JAR)
• org.projectlombok:lombok.patcher:0.40 (same)

org.projectlombok:lombok.patcher:0.40 then contains…

• org.ow2.asm:asm:9.0
• org.ow2.asm:asm-commons:9.0
• org.ow2.asm:asm-tree:9.0

There are two problems for me with this (and another for you):

① Figuring these out is a very manual process. I also don’t know
if I managed to find all sources (only know Maven, not Ant).

Perhaps you could help me by generating a list of everything
contained in a given binary release. The list doesn’t need to
be fancy — perhaps put a plaintext file into META-INF/ in the
JAR as part of your build process and you’d be all set³.

② Neither com.zwitserloot:cmdreader:1.2 nor lombok.patcher are
published in Maven Central, so we cannot acquire source JARs
for these. While the licence doesn’t mandate source availability
other project constraints can (e.g. if adding Lombok to a GPL’d
project would). ASM c̲a̲n̲ be retrieved from Central though³. Note
that cmdreader 1.5 is published in Central, but 1.2 which Lombok
includes isn’t.

Please publish all artefacts in Maven Central, including their
sources, not just the final Lombok.

③ This is not so much an issue for me but for you: you include
a copy of ASM in your JAR but the LICENSE file only contains
the Lombok licence, not the licence of ASM. This violates the
licence which requires you to…
// 2. Redistributions in binary form must reproduce the above copyright
// notice, this list of conditions and the following disclaimer in the
// documentation and/or other materials provided with the distribution.

Incidentally, Lombok also violates the licence of cmdreader:
https://github.com/rzwitserloot/com.zwitserloot.cmdreader/blob/1.2/LICENCE
has a copyright notice “2010 Reinier Zwitserloot” which is not present
in the LICENSE file contained in the Lombok JAR.

https://github.com/rzwitserloot/lombok.patcher does not even have a
conveniently available LICENCE file. Looking at individual files
indicates that it shares the terms of Lombok, though.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*************************************************

[Reinier Zwitserloot]

1. Yes, well, with a complicated build, that's how it goes. But, ivy is involved, ivy is an open standard, and you can ask it for a full, hierarchical dep tree. We have no intention of catering to systems that are not willing or capable to do that work. That's primarily a pragmatic point: You listed all the deps, and of all of those, they're all 'ours' (written by Roel or I), except ASM. Which you found. I do not understand what possible point there would be by writing a file in the META-INF dir that says 'we use ASM'. We'd just forget to update it if we add a new dep, so, not happening. We'll likely accept a PR that adds a simple and reliable step to the build to automatically determine this list from dependency files.

2.  cmdreader and patcher are published on github, which fits every open source license under the sun, no? If you cannot acquire source jars from github, then it feels like you should fix your tools instead of trying to convince us to publish artefacts that nobody should use. Maven Central is already overloaded with pointless cruft, after all.

3. The license has been addressed. Incidentally, I am quite convinced the authors of cmdreader have absolutely no issue with it, and the same goes for lombok.patcher, as you might imagine :)

Gracias for raising these points. However, I'm having a hard time figuring out what purpose this all serves, with the notable exception of our omission of ASM From our license file. Gracias to the PR that addressed this problem!

We could push lombok's cmdreader dep up to 1.5 if that helps, but it'd help me to figure out why I should spend a bunch of time on making your life easier. 'all deps used must have source jar hosted on maven central' is not, as far as I know, a clause in any open source license.

[Thorsten Glaser]

On Thu, 1 Apr 2021, Reinier Zwitserloot wrote:

> Gracias for raising these points. However, I'm having a hard time figuring
> out what purpose this all serves, with the notable exception of our

OK… imagine the requirement, incidentally not uncommon in the FOSS
world either, to acquire sources and/or ship them alongside the
binaries for everything that goes into a build.

Or even (more trivially) to analyse their licences (don’t tell me
about e.g. Maven metadata, I’ve seen POM files lie).

With mvn dependency:sources I’ve a mechanism that almost works,
keeping Central’s limitations (which are accepted, in those cases
I’m thinking of) in mind.

> 1. Yes, well, with a complicated build, that's how it goes. But, ivy is
> involved, ivy is an open standard, and you can ask it for a full,
> hierarchical dep tree. We have no intention of catering to systems that are

Oh. How?

Thanks,

//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH

Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/

[Roel Spilker]

Hi  Thorsten,

I still do not understand what problem you are trying to solve here? 

Please, I ask this because I want to help, I want to understand your problem, and see how we can mitigate it.

Do you have a legal issue?  

To me it sounds like you have some problem, found a way to solve that problem, that way created a new/different problem, and now you are looking at us to solve that.

I just think that you don't have a problem. I mean: Lombok is a plugin for the compiler. You should never ship lombok. Lombok is a single 1.9MB jar, that does its think during development and compilation.

So what are you afraid of?

Roel

[Moises Lejter]

Ah!  This points out that maybe I have been doing something wrong, all this time...

We are using lombok, so I installed it in my Eclipse, and also made it a Maven dependency with "compile" scope.

I don't have an explicit de-lombok step in my maven builds, since i don't care whether the source code keeps the lombok annotations in place.

And I don't need to do anything for compilation, as this happens automagically (right? lombok as an agent during maven compiles because it is in the classpath?).

I sort of thought it might also be needed during deployment - but I just never thought about it too much, just let the lombok dependency's "compile" scope include it in my deployment,

But it sounds like it really doesn't have to be there at runtime, and a Maven scope of "provided" (meaning make it available during Maven build and test phases, but let the runtime provide it - or not - during runtime) would be the right thing to do?

Thank you!

Moises

On Fri, Apr 2, 2021 at 9:55 AM Roel Spilker <r.sp...@gmail.com> wrote:

[...]

I just think that you don't have a problem. I mean: Lombok is a plugin for the compiler. You should never ship lombok. Lombok is a single 1.9MB jar, that does its think during development and compilation.

So what are you afraid of?

Roel

[...] 

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/b29a3fb6-822e-4189-a402-9e3d91a4b559n%40googlegroups.com.

[Roel Spilker]

Yes, "provided" it is: https://projectlombok.org/setup/maven

To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/CADGBLwk6r8q2Bvym43RYYAUBZ_BN2eevfx1Bi8FZMygs76xpdQ%40mail.gmail.com.