Require license information in poms published to Clojars

[pmonks]

Maven Central has long required that all artifacts published there include licensing information (non-empty <licenses><license><*> tags) in their effective poms (either the artifact's immediate pom, or somewhere up the parent pom chain of that artifact's pom). This greatly assists downstream consumers in verifying license compliance in their own projects via tooling that consumes those published artifacts.

Clojars does not currently have the same requirement, which limits the ability for equivalent Clojure tooling to provide this same capability. Might this (breaking) enhancement be worth considering?

License hygiene is an important part of open source development but often overlooked or dismissed by less legally-knowledgeable developers, and artifact repositories (like Maven Central and Clojars and so forth) can play an important role in helping developers follow best practices.

[danielcompton]

A few thoughts:

• It might be easier to start enforcing this on artifacts that have never been published before. Not sure how I feel about making this a breaking change
• Perhaps we could show a warning on Clojars for missing license information and a link to docs on how to add it
• Do you have any idea what proportion of poms are missing license tags? I would have expected most of them to have it via Leiningen's EPL license default.

[pmonks]

• Agreed. I would envisage this as only being enforced from a given point forward. Trying to retrospectively "fix" artifacts that were previously published seems to me to be both very complicated and low value. Despite that, I'd still consider this a breaking change since some folks' builds that previously worked will stop working.
• Yeah a grace period to help mitigate the impact of this breaking change is a great idea. I do however think that at some point this should be enforced at the time a new artifact (or version) is published to Clojars i.e. deployments of poms without license information are rejected by Clojars. Humans quickly become desensitised to warnings that can be bypassed.
• tl;dr: around 28%. Long version: funnily enough I happen to have a snapshot of Clojars' poms as of 2023-07-13, and at that time there were 265,483 poms on the site, representing 30,488 distinct projects (i.e. groupId+artifactId). Parsing the pom for just the latest version of each of those 30,488 unique projects resulted in 2 unparseable (not well-formed) poms, and of the remainder 22,059 had at least one <licenses><license> block in it. Note that this count does not take parent pom relationships into account (I don't have code ready-at-hand for that - sorry!), though I suspect the parent pom mechanism isn't used all that often in the Clojure ecosystem (since afaik it's not supported OOTB by either Leiningen or tools.build).

[danielcompton]

Agreed. I would envisage this as only being enforced from a given point forward. Trying to retrospectively "fix" artifacts that were previously published seems to me to be both very complicated and low value. Despite that, I'd still consider this a breaking change since some folks' builds that previously worked will stop working.

To clarify, my proposal would be that all existing projects on Clojars could continue publishing without a license block, but any projects that were starting new would need to set a license. This should avoid any breaking changes for existing projects.

Do you have any samples of projects missing licenses, especially ones that are widely used? My base assumption is that the projects without a license would be projects that aren't really used by anyone.

[pmonks]

I think it's worth considering giving existing projects a grace period (with clear warnings about what's coming), but then still requiring license information from them from a second point-in-time forward. I don't think there should be any exemptions in the long term, so as to align with Maven Central (not to mention open source best practices).

Here's the list of GAs (latest versions only) that are missing licenses (as of 2023-07-13, and ignoring licenses in the parent pom chain): poms-without-licenses.txt

Note that some of them are missing <artifactId>, <groupId> and/or <version> tags, which should probably also be rejected by Clojars (such poms are invalid, unless they have a parent that defines them), along with poms that aren't even well-formed (though there are only 2 of those out of the 30,488 projects I'm looking at). Those two are org.clojars.originalsurfmex.processing/gluegen-rt@2.1 and mpjct/jmp@0.2.0.

[tobias]

Thanks for bringing this up @pmonks! I agree that this is something we need to address.

To clarify, my proposal would be that all existing projects on Clojars could continue publishing without a license block, but any projects that were starting new would need to set a license. This should avoid any breaking changes for existing projects.

I think it's worth considering giving existing projects a grace period (with clear warnings about what's coming), but then still requiring license information from them from a second point-in-time forward. I don't think there should be any exemptions in the long term, so as to align with Maven Central (not to mention open source best practices).

I think this is a good proposal. It would be straightforward to implement initially for new projects, then have a date where we enable it for all versions (maybe with a three month grace period?)

We would want to announce the change in a few places:

• the clojure@ mailing list
• a post on clojureverse.org
• a mention in #announcements and #clojure in the clojurians slack
• other places?

Perhaps we could show a warning on Clojars for missing license information and a link to docs on how to add it

Agreed. We'll want to add something to the wiki about licenses anyway that we can link from the error message we return when a new project doesn't include license info, so can just link to that.

Note that some of them are missing <artifactId>, <groupId> and/or <version> tags, which should probably also be rejected by Clojars (such poms are invalid, unless they have a parent that defines them), along with poms that aren't even well-formed (though there are only 2 of those out of the 30,488 projects I'm looking at). Those two are org.clojars.originalsurfmex.processing/gluegen-rt@2.1 and mpjct/jmp@0.2.0.

We do require well-formed poms (and require that the gav in the pom matches the gav included in the route), but haven't always, so I suspect these two were deployed before we had that validation in place.

[tobias]

The first phase of this has been released. It differs slightly from the proposal above. It requires all new projects to provide a license, but also requires any new version to have a license if the prior version (chronologically) had a license. This means that projects that use a license must continue to do so.

I plan to require licenses for all as a follow-on change on or after 2024-01-01.

[tobias]

Clojars now requires a license for all releases, so this issue is complete!