nexus-jenkins-plugin bundles proprietary dependency

[daniel-beck]

Service(s)

Artifactory, Update center

Summary

https://search.maven.org/artifact/com.sonatype.nexus/nexus-platform-api/4.1.8-01/jar is published under a proprietary license and is part of https://plugins.jenkins.io/nexus-jenkins-plugin/

Therefore the plugin is ineligible for hosting by the Jenkins project per https://www.jenkins.io/project/governance/#license

We encourage hosted plugins to use the same MIT license, to simplify the story for users, but plugins are free to choose their own licenses, so long as it’s an OSI-approved open-source license.

This is not to be confused with proprietary plugins --- we recognize and encourage plugins that people write on their own for their internal use, without necessarily making the source code available. But no such plugins will be hosted by the Jenkins project.

and https://www.jenkins.io/doc/developer/publishing/preparation/#license

All plugins distributed by the Jenkins project need to be free and open source software. This applies to the plugin source code as well as all its dependencies.

Reproduction steps

No response

[daniel-beck]

jenkins-infra/update-center2#739 would suspend distribution.

FYI @eduard-tita as you seem to be a currently active maintainer.

[daniel-beck]

@MarkEWaite @NotMyFault @uhafner

[whyjustin]

Hi @daniel-beck and team. Thanks for bringing this to our attention. Unfortunately there is proprietary code leveraged by the plugin that cannot be open sourced. This particular code is relied upon by our plugin users to get accurate results. I would love to understand options or if you know other plugin developers who have faced similar problems.

In the near term I am hoping that you can provide some time for us to figure out how to respond. There is no simple technical solution to removing this code without greatly impairing the plugins functionality, therefore we'll need to plan and act given any information or experiences we can get from you and the team.

[daniel-beck]

I would love to understand options or if you know other plugin developers who have faced similar problems.

I'm aware that many years ago, a few vendors resolved this situation as follows:

• My (now) employer CloudBees provided a plugin that installed a vendor-hosted secondary update site in Jenkins, so the "real" plugin(s) could then be offered for installation: https://github.com/jenkinsci/cloudbees-plugin-gateway (note that the current code is the "tombstone" release that basically removed everything).
• Black Duck seems to have done something similar, some old docs: https://wiki.jenkins-ci.org/display/JENKINS/Black+Duck+Vulnerability+Installer+Plugin and the old releases including source jars (for inspiration): https://repo.jenkins-ci.org/artifactory/releases/org/jenkins-ci/plugins/blackduck-installer

[asaleemeadows]

One of my customers alerted me to this yesterday. @daniel-beck, could you provide clarity on why it was removed vs disabling updates and giving us time to resolve without breaking things? That seems to be in conflict with the project's governance on compatibility. "We recognize that users expect their existing data, accumulated under past versions (including Hudson up to 1.395) to continue working under future versions of Jenkins. This includes jobs configurations, build records, and plugin binaries that they are using." https://www.jenkins.io/project/governance/#compatibility-matters

[dduportal]

One of my customers alerted me to this yesterday. @daniel-beck, could you provide clarity on why it was removed vs disabling updates and giving us time to resolve without breaking things? That seems to be in conflict with the project's governance on compatibility. "We recognize that users expect their existing data, accumulated under past versions (including Hudson up to 1.395) to continue working under future versions of Jenkins. This includes jobs configurations, build records, and plugin binaries that they are using." https://www.jenkins.io/project/governance/#compatibility-matters

The same page (https://www.jenkins.io/project/governance/#license) also states @asaleemeadows

This is not to be confused with proprietary plugins --- we recognize and encourage plugins that people write on their own for their internal use, without necessarily making the source code available. But no such plugins will be hosted by the Jenkins project.

[daniel-beck]

could you provide clarity on why it was removed vs disabling updates

Existing Jenkins instances continue running. Only newly set up instances will not be able to receive the plugin through update sites.

That seems to be in conflict with the project's governance on compatibility.

It's not. No current or future Jenkins release rejects the already installed plugin with a license-related error, admins can install whatever they want and it will likely continue to work for a long time (there are rare cases of typically carefully considered larger-scale changes that could require adaptation). They just don't receive it from Jenkins-project hosted update sites. It can still be manually distributed and installed.

(It's admittedly a bit awkward that there's a deprecation warning linking to this issue, but there is no other way for us to communicate why a plugin is no longer being distributed. It seemed preferable over it just being gone.)

I suggest you look into finding a technical solution. Personally I'd be OK with restoring distribution for a (very) limited period of time while whatever work towards a solution is ongoing. If you want, you could also reach out to the board via email to see whether they see this differently (note that two members approved the suspension PR).

[rcfja]

@whyjustin or @asaleemeadows What is the plan?

[PayBas]

Yeah I know we can manually get the latest compiled .hpi version from https://help.sonatype.com/iqserver/product-information/download-and-compatibility#DownloadandCompatibility-Jenkins and install it manually, but this constant "deprecated" banner is starting to annoy me.

This needs to be resolved. Or at least some progress-update.

[HokieGeek]

@daniel-beck hello there! we've implemented a solution for our customers to gain reliable access to our plugin. would it be possible to update this page to link to our documentation? if not, could we have the page removed?

[daniel-beck]

@HokieGeek What's your solution? Could you provide those links you mention?

[HokieGeek]

@daniel-beck We stood up a custom plugin update site. The documentation directs customers to use the UpdateSites Manager to add that site to their Jenkins Plugin Manager.

Link to the document: https://help.sonatype.com/en/sonatype-platform-plugin-for-jenkins.html
The specific section can be found under the heading Install through the Jenkins Plugin Manager:
https://help.sonatype.com/en/sonatype-platform-plugin-for-jenkins.html#install-through-the-jenkins-plugin-manager

[daniel-beck]

Thanks for the references. That seems like a pragmatic solution.

---

In terms of next steps, I see a few things we need to address:

1. The deprecation warning. That was never a great vehicle for the message, but it's the best we had. Going forward I think it's preferable to have no such notice at all, than one that directs users to your new docs, since it would still show up even for users who have already followed your migration instructions. Resulting reduced discoverability for your users/customers you can probably address through your own product docs?
2. The GitHub repo. If we no longer distribute the plugin, but you do, it should be part of your GH org, not Jenkins's. We can host an archive for older releases with compliant license, if any, but otherwise it doesn't make sense IMO to continue to have this in jenkinsci.
3. The previous releases. We need to remove any releases with closed source dependencies from our Artifactory.

Re items 2 and 3, do you know whether any past releases did not bundle proprietary libraries?

If you have suggestions for these items, please let us know. Otherwise, please do not act on any of these for now. This isn't a common situation for which we have a runbook so it'll take us a bit.

[HokieGeek]

@daniel-beck sounds good. we will move the repository to our organization and let you know when we have done it

[daniel-beck]

@HokieGeek As I wrote, please hold off acting on this until we're in agreement on our side. (I think you may be lacking that permission anyway.)

[Abbasi-Alain]

Do we have any update on the plugin development?

The current lack of clarity is significantly impacting our plans for Nexus integration within our CI/CD pipelines. If support for Jenkins cannot be provided under an MIT license, we may need to explore alternative solutions for future projects. Adopting an MIT license would encourage the community to develop and contribute to new open-source tools, benefiting everyone involved.

Thank you for your attention to this matter.

[MarkEWaite]

The Jenkins board has discussed the issue and agrees that the proposed steps are the right steps to take.

[HokieGeek]

Thank you for the update, @MarkEWaite !
I have submitted a PR to the README with a notice that development will be moving to a private repo: jenkinsci/nexus-platform-plugin#313
@daniel-beck please feel free to archive this repository at your earliest convenience.

[daniel-beck]

@MarkEWaite Thanks for confirmation, I'll proceed implementing, probably tomorrow.

[daniel-beck]

• GH repo: Closed open issues and PRs, changed default branch to a readme. Archival in a few days to provide an opportunity for readme wording changes.
• Update sites: Remove "deprecation" notice for nexus-jenkins-plugin update-center2#783 implements removal of the "deprecation" message.
• Artifactory: Copied all past releases to the (private) Maven repo helpdesk-3742-nexus and deleted the public artifacts.
• RPU: Had already previous disabled upload with reference to this issue.

All that's left is archival of the repo once Sonatype folks are OK with the placeholder readme.

[HokieGeek]

@daniel-beck that readme works for us. feel free to archive the GH repo. thank you

[timja]

I've archived it