Is anyone here aware of tooling that uses

pom.license.url

in addition to

pom.license.name

? We're considering removing the url from our poms because they duplicate information and make the pom validation somewhat harder: url can take many forms while

license.name

can point to a well defined SPDX id. Are we breaking someone's workflow by doing this?

The

com.github.jk1.dependency-license-report

plugin for example uses it in its report.

Does it break if I remove it or is the report less complete?

And also in match rules for normalization

match rules for normalization

Do you have a pointer for that?

report would be less complete, matching can be broken then, a.k.a. not match for normalization anymore what matched before

the normalization algorithm

Why would it not?

If it wasn't able to use our url before then removing it is fine

Sorry if I sound stubborn, but why should it not be able to before? (Besides that there are surely more code out there using the url)

A url is not really machine processable by default

It is matched with regexes, and the regexes are configurable by each user of the plugin

Devil advocate here but nothing prevents me to put the Apache license at https://example.com/license/MIT

Yes it is, but that's how it is. The plugin very much depends on heuristics. It also searches for some hard-coded license files within the jar to detect the used license.

SPDX is a thing now

Sure, make every 20 year old mature lib out there change their POM 😉

I'm talking about my own lib

Or the new libs coming out where maintainers are not aware of how to do it

Some of them are mature though 😄

Yes, I said "mature"

It'll take some time but feels like we can steer the ecosystem toward a more robust solution

"some" is very stretchy there 😄

I'm a belieber!

Aaand of course, using the SPDX for

name

is just a recommendation, so you can also not rely on that

Oh yea, I'm asking all of that from the point of view of a pom producer, not consumer

According to the specs, the description is

The official url of the license text.

It does not mention MUST or SHOULD. And it is optional… https://maven.apache.org/ref/3.9.9/maven-model/maven.html#class_license

I was a bit anxious Sonatype would mandate it but from my tests, they don't mind if license url is missing

For my projects, it’s is simple, I only use Apache 2, so I use the SPDX Id as name and the official url as url. But things will be complicated if you use another license, copy it and fill out the placeholders.

Yea, that's exactly our problem, the default url text contains placeholders so it's not really correct (we're using MIT)-

The license text actually does not contain placeholders, that would be a jurisdictional nightmare

In that cause I would put the url of your license into the field, because the text itself is not valid without filling the placeholders (like an empty formula). But on the other hand I would say, ignore it. You do express your intention to license your work under MIT and your! license is checked in in your repo (isn’t it?).

You do express your intention to license your work under MIT and your! license is checked in in your repo (isn’t it?).

That's my thinking too. The source of truth for the license text is the file itself alongside the code

Again, the license does not contain placeholders.

I'm talking abuot this: ou do express your intention to license your work under MIT and your! license is checked in in your repo (isn’t it?).

But the MIT license contains the copyright placeholder 🤔

Our pom currently contains this (which we are considering dropping): https://github.com/apollographql/apollo-kotlin/blob/main/LICENSE

Hm, well, I guess that is unlucky that this line is in the license text, or just that site is misleading. The copyright line should not be part of the license text. It just shows how you apply it to your file where you should contain the copyright line.

So you're saying maybe there's a MIT license url somewhere without the placholders?

I don't know whether there is, I'd hope so. But even if not, either way the copyright line is not part of the license

My current train of thought is "no information" => "no problem"

Hm, well, maybe I'm wrong in case of the MIT license actually. As the license text refers to the copyright line, it probably is considered part of the license. 🤷‍♂️

Well, add a link to the license file in your repo instead of the placeholdered one, problem solved too

Not really because tools get confused by that extra information

Well, not the problem that you might break consumers relying on the old one, but problem of missing url 🙂

Some other tools will miss information as they will not parse the name, or generate an url from the name

you might break consumers relying on the old one

Yep, that's the tradeoff. How many am I breaking vs how many am I fixing

Probably not fixing anyone by removing information. :-D

It's fixing https://github.com/cashapp/licensee/issues/137

I'd say, if a tool disallows urls, this is a bug in that tool. Especially as in the MIT case you are supposed to fill in placeholders, so should always link to your version. The MIT license also is not copyrighted itself, so you also can freely modify it to your needs.

I also do use licensee and IMHO adding the custom license url of a dependency to the list is just a one-time job 🤷🏻‍♂️

But tedious and unnecessary when the lib could provide the link to their version of the license.

Yea, if you have dozens of dependencies it can be a bit cumbersome I guess

Ah I mean when using the licensee plugin you have to white list any MIT licenses with a custom url. But that is a one time job, the license rarely change.

I think we'll try it out. It's not a huge deal either. Worst case users complain about it and have to stay on the n - 1 version until we do another release. It makes us look bad a little bit but at least we'll have our answer.

Interesting find: https://github.com/remy/mit-license You can do a

curl

request and end up with a personalized version like https://rem.mit-license.org/