Published as LGPL

[atschabu]

This plugin is exactly what I was looking for ... but I might not be able to use it company internal because of the license set in the pom file to LGPL.

Any chance you could re-publish under a different license or as dual license? For example the Apache 2.0 license seems to be something people are generally happy with.

[szpak]

@atschabu I wonder why LGPL is not open enough to use for the plugin which will not (as I suspect) be a part of produced source code or even deployed/delivered in binary version run in production?

[atschabu]

Unfortunately I'm not a lawyer, so I can't even speculate about the implications. All I know is, we have a list of "good" and "bad" licenses at our company. One common occurrence where some companies would package the binary up with the application (source) is when creating backups stored at an escrow facility, which is usually a requirement for long-living enterprise applications. Another example would be an (offline) installer provided to customers, where something like this plugin might come in handy.

[sebersole]

People generally "dislike" LGPL because of misunderstanding.

So the trouble with changing licensing after initial work is that technically I need to track down all "significant contributors" and ask their permission. Significant is open to interpretation unfortunately.

[lukecwik]

We are also interested in using this plugin as part of Apache Beam but Apache doesn't allow for LGPL licenses to be used, see:
https://www.apache.org/legal/resolved.html#category-x

Any possibility to swap to a category A or B license?
https://www.apache.org/legal/resolved.html#category-a

[szpak]

@lukecwik From the aforementioned document:

For example, using a GPL'ed tool during the build is OK, however including GPL'ed source code is not.

gradle-maven-publish-auth is not exactly a tool, but also is not a part of the binary distribution, nor something required to use it. It is just a tool included in a form of a plugin to do some work during a build (which could optionally be replaced with some other plugin without affecting the binary distribution). I wonder, if you consulted the Apache legal department if it is in fact forbidden - to use the LGPL-licensed build plugin - as I haven't found a point that precised it in one or an another way.

[tweise]

There is some related discussion here: https://issues.apache.org/jira/browse/LEGAL-324

Since ASF releases are source releases (binaries are optional, convenience), the source code cannot be built w/o the LGPL dependency, which does not meet the definition of "optional".

As mentioned in the discussion, companies tend to whitelist ASL as a permissive open source license and try to stay away from or require extra checking for LGPL. I think it would be great if this plugin could be available under one of the licenses @lukecwik suggested.

[sebersole]

As I have said already, companies "stay away from" LGPL for silly reasons. Apache has long maintained this silly stance. I cannot help them

[sebersole]

Unfortunately I'm not a lawyer, so I can't even speculate about the implications. All I know is, we have a list of "good" and "bad" licenses at our company. One common occurrence where some companies would package the binary up with the application (source) is when creating backups stored at an escrow facility, which is usually a requirement for long-living enterprise applications. Another example would be an (offline) installer provided to customers, where something like this plugin might come in handy.

None of those trigger the LGPL clause that these FUD people point to...