What is the license of a gradle plugins meta-plugin pom.xml?

Help/Discuss Plugin Portal
,
1

The new Gradle plugin system relies on a special pom that redirects to the actual plugin.

For example:

plugins {
  id "com.diffplug.gradle.spotless" version "3.13.0"
}

differs from:

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "com.diffplug.spotless:spotless-plugin-gradle:3.13.0"
  }
}

apply plugin: "com.diffplug.gradle.spotless"

by requiring https://plugins.gradle.org/m2/com/diffplug/gradle/spotless/com.diffplug.gradle.spotless.gradle.plugin/3.13.0/com.diffplug.gradle.spotless.gradle.plugin-3.13.0.pom which then depends on http://central.maven.org/maven2/com/diffplug/spotless/spotless-plugin-gradle/3.13.0/spotless-plugin-gradle-3.13.0.pom

Note that the com.diffplug.gradle.spotless.gradle.plugin-3.13.0.pom doesn’t contain a <license> block while spotless-plugin-gradle-3.13.0.pom does.

The company I work for has a whitelist for which licenses are approved and can be imported into the company and it seems as though plugins meta-plugin pom.xml don’t specify their license. Since they don’t specify their license, this blocks building any project using Gradle that uses the plugins block within the company.

Are these pom.xml generated by Gradle Inc. or by the plugin author?

  • If by Gradle Inc, can a license be set on these pom.xml?, should it be assumed that they are all Apache License 2.0 like the opensource portion of Gradle?
  • If by the author, could the pom.xml inherit the license from the plugins pom.xml?
2

These marker POM files are generated on-the-fly by the Gradle Plugin Portal. It’s a bit like licensing an API endpoint instead of a binary package. If we had to license it somehow, it would indeed by Apache License 2.0.

I don’t typically see license headers in POM files, even for Apache License 2.0 binaries, though I’m not sure if the POMs are considered part of the software so I don’t know if they should be.

I would hate for a <license> element in the “marker” POM to imply the license of the downstream software, so I’m not sure that fits either.

If what’s currently in those marker POMs isn’t sufficient, would some sort of public declaration of the license be sufficient instead?

Cheers,
Eric

3

Yes, a public declaration would work. Can you update your answer with a link to the location once the public declaration is available.

4

@eriwen it’s not about licensing the pom file itself. It’s about the pom file specifying the license of the plugin. We should indeed mirror whatever license the original plugin specifies so that automated license checkers still work. This should be fixed both in the java-gradle-plugin and the plugin portal.

5

My understanding is that the asker is questioning the license of the POM file itself.

I think the POM file specifying the license is a good idea, but a tricky one perhaps. The plugin portal doesn’t have license information for a plugin. We could rely on a new version of the java-gradle-plugin, but adoption will be slow here, and I don’t think it’ll solve the asker’s need anytime soon.

6

We know the license for plugins published with a properly filled out POM. Some users (Netflix for instance) did that using the undocumented POM hook. With the latest version of the plugin publish plugin (which reuses the POM from maven-publish), we’ll get even more. We could even start making it a requirement at some point.

7

Okay, so the situation is better than I feared.

We should make it a requirement. I would hate for users to expose themselves to unnecessary legal risk by adopting a plugin that doesn’t declare a license.

8

@eriwen is right. It is about the licensing of the meta pom since it seems to be generated during the plugin portal registration process and it was unclear what the license of the meta pom itself was.

Having the license of the actual plugin propagated to the meta pom is nice to have but unnecessary to solve my issue.