JSON license

328 views
Skip to first unread message

Filipe Roque

unread,
Jul 25, 2023, 6:24:04 PM7/25/23
to jenkin...@googlegroups.com
I have not found any discussion on the mailing list about this.

JSON License has not been considered an open source license by Apache [1], Debian [2] and FSF [3] and is not OSI approved [4].

Douglas Crockford has relicensed org.json:json java library to be Public Domain starting with version 20220924 [5].

Jenkins requires plugins and its dependencies to be free and open source software [6][7].

I did some analysis on the latest Jenkins plugins usage of org.json:json [8]. I have found a total of 473 plugins that depend on org.json:json (directly or transitively), with 104 plugins being free versions, 67 plugins directly depend on non free versions of org.json:json.

Is this an actual concern for the Jenkins project ? If so, how to proceed ?

Filipe Roque

[8] https://docs.google.com/spreadsheets/d/1MWNi796iAovFa6GK7LJ0gilbQRwvb8Su3c7YgpH_fuc/edit?usp=sharing

Basil Crow

unread,
Jul 25, 2023, 7:13:24 PM7/25/23
to jenkin...@googlegroups.com
Ought to be made into a library plugin I think.

Mark Waite

unread,
Jul 25, 2023, 9:04:55 PM7/25/23
to Jenkins Developers
On Tuesday, July 25, 2023 at 4:24:04 PM UTC-6  Filipe Roque wrote:
I have not found any discussion on the mailing list about this.

JSON License has not been considered an open source license by Apache [1], Debian [2] and FSF [3] and is not OSI approved [4].

Douglas Crockford has relicensed org.json:json java library to be Public Domain starting with version 20220924 [5].

Jenkins requires plugins and its dependencies to be free and open source software [6][7].

I did some analysis on the latest Jenkins plugins usage of org.json:json [8]. I have found a total of 473 plugins that depend on org.json:json (directly or transitively), with 104 plugins being free versions, 67 plugins directly depend on non free versions of org.json:json.

Is this an actual concern for the Jenkins project ? If so, how to proceed ?

I think it is a concern for the Jenkins project.  Thanks for noting the issue.  I don't think the risk is high, but it is a concern that is worth some effort to assure that Jenkins remains free and open source.

I believe one concern is related to software that is in the public domain not using an OSI approved license.  We could extend the definition of licenses accepted by the Jenkins project to include OSI approved licenses and public domain software.  That would address the concerns of those who worry that "public domain" is not a license.

The other concern is how do we reduce the number of versions and encourage use of the public domain version instead of the not quite OSI approved license of the earlier versions.  I think that Basil's observation that the org.json:json should be made into a library plugin is the way to reduce the number of versions and encourage use of the public domain version.

With regards to the list of plugins, only 7 of the 67 plugins that directly depend on versions prior to 20220924 have more than 1000 installations.  Those seem like the first candidates to consider for either an upgrade of the library version or replacement of the library dependency with a plugin dependency.

With regards to the analysis, I'm not confident in my understanding of the specific details of the analysis.  Maybe you can help me understand more clearly.

I maintain the elastic axis plugin and it is on the list as having a transitive dependency on an older version of the json library.  The elastic axis plugin depends on the matrix project plugin.  The matrix project plugin depends on the junit plugin.  The junit plugin depends on the jackson2 api plugin.  The jackson2 api plugin bundles the jackson2 api jar file and the json-20230227.jar inside its hpi file.  I think that would cause jackson2 api calls to use the the json-20230227.jar that is bundled in the hpi file.

However, the analysis indicates that there is a dependency on json-20190722.  Is the analysis not detecting that the jackson2 api plugin already includes a newer version of the json library?  Am I misunderstanding how libraries are resolved?

I'll put the topic on the next agenda for the Jenkins governing board.

Thanks,
Mark Waite

Ullrich Hafner

unread,
Jul 26, 2023, 2:51:16 AM7/26/23
to JenkinsCI Developers


On Tuesday, July 25, 2023 at 4:24:04 PM UTC-6  Filipe Roque wrote:
I have not found any discussion on the mailing list about this.

JSON License has not been considered an open source license by Apache [1], Debian [2] and FSF [3] and is not OSI approved [4].

Douglas Crockford has relicensed org.json:json java library to be Public Domain starting with version 20220924 [5].

Jenkins requires plugins and its dependencies to be free and open source software [6][7].

I did some analysis on the latest Jenkins plugins usage of org.json:json [8]. I have found a total of 473 plugins that depend on org.json:json (directly or transitively), with 104 plugins being free versions, 67 plugins directly depend on non free versions of org.json:json. 

Is this an actual concern for the Jenkins project ? If so, how to proceed ?

I think it is a concern for the Jenkins project.  Thanks for noting the issue.  I don't think the risk is high, but it is a concern that is worth some effort to assure that Jenkins remains free and open source.

I believe one concern is related to software that is in the public domain not using an OSI approved license.  We could extend the definition of licenses accepted by the Jenkins project to include OSI approved licenses and public domain software.  That would address the concerns of those who worry that "public domain" is not a license.

That would make sense, yes.


The other concern is how do we reduce the number of versions and encourage use of the public domain version instead of the not quite OSI approved license of the earlier versions.  I think that Basil's observation that the org.json:json should be made into a library plugin is the way to reduce the number of versions and encourage use of the public domain version.

I think it would be easier when the plugins (if they are still maintained) would bump their version to the latest public domain version. Using a library plugin needs someone to maintain the library and all plugins need to upgrade their baselines and modernize the plugins (so it would be better to use a library but will cause more work). Maybe this is something for Hacktoberfest?


With regards to the list of plugins, only 7 of the 67 plugins that directly depend on versions prior to 20220924 have more than 1000 installations.  Those seem like the first candidates to consider for either an upgrade of the library version or replacement of the library dependency with a plugin dependency.

With regards to the analysis, I'm not confident in my understanding of the specific details of the analysis.  Maybe you can help me understand more clearly.


What do the colors mean in the spreadsheet?

I maintain the elastic axis plugin and it is on the list as having a transitive dependency on an older version of the json library.  The elastic axis plugin depends on the matrix project plugin.  The matrix project plugin depends on the junit plugin.  The junit plugin depends on the jackson2 api plugin.  The jackson2 api plugin bundles the jackson2 api jar file and the json-20230227.jar inside its hpi file.  I think that would cause jackson2 api calls to use the the json-20230227.jar that is bundled in the hpi file.

However, the analysis indicates that there is a dependency on json-20190722.  Is the analysis not detecting that the jackson2 api plugin already includes a newer version of the json library?  Am I misunderstanding how libraries are resolved?

I'll put the topic on the next agenda for the Jenkins governing board.

Thanks,
Mark Waite
 

-- 
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d84bbf01-6d3c-495c-81fb-a715377c89e4n%40googlegroups.com.

Filipe Roque

unread,
Jul 26, 2023, 2:55:13 PM7/26/23
to jenkin...@googlegroups.com

What do the colors mean in the spreadsheet?

I have updated the spreadsheet, but green is depends on free version and red is direct dependency on non-free version.

With regards to the analysis, I'm not confident in my understanding of the specific details of the analysis.  Maybe you can help me understand more clearly.

I maintain the elastic axis plugin and it is on the list as having a transitive dependency on an older version of the json library.  The elastic axis plugin depends on the matrix project plugin.  The matrix project plugin depends on the junit plugin.  The junit plugin depends on the jackson2 api plugin.  The jackson2 api plugin bundles the jackson2 api jar file and the json-20230227.jar inside its hpi file.  I think that would cause jackson2 api calls to use the the json-20230227.jar that is bundled in the hpi file.

However, the analysis indicates that there is a dependency on json-20190722.  Is the analysis not detecting that the jackson2 api plugin already includes a newer version of the json library?  Am I misunderstanding how libraries are resolved?

I only looked into the tree provided by Maven, with the dependency plugin, taking the pom.xml file embedded in the hpi file.

I know that at runtime Jenkins may use updated versions, but that would complicate the analysis for me.

So, for the elastic-axis:

unzip -q elastic-axis.hpi -d elastic-axis
/opt/maven/apache-maven-3.8.4/bin/mvn \
  -s /tmp/tmp.VLcrje6TDb/settings.xml \
  -f elastic-axis/META-INF/maven/org.jenkins-ci.plugins/elastic-axis/pom.xml \
  --quiet \
  org.apache.maven.plugins:maven-dependency-plugin:3.6.0:tree \
  -Dincludes=org.json \
  -DoutputFile=tree.txt
cat elastic-axis/META-INF/maven/org.jenkins-ci.plugins/elastic-axis/tree.txt
org.jenkins-ci.plugins:elastic-axis:hpi:464.va_7ed499b_9d75
\- org.jenkins-ci.plugins:matrix-project:jar:789.v57a_725b_63c79:compile
   \- org.jenkins-ci.plugins:junit:jar:1189.v1b_e593637fa_e:compile
      \- org.jenkins-ci.plugins:jackson2-api:jar:2.14.2-319.v37853346a_229:compile
         \- com.fasterxml.jackson.datatype:jackson-datatype-json-org:jar:2.14.2:compile
            \- org.json:json:jar:20190722:compile

Filipe Roque

James Nord

unread,
Jul 26, 2023, 5:47:23 PM7/26/23
to jenkin...@googlegroups.com
If you are obtaining the pom from the hpi, then as you have the hpi why not just see what version if any is in the plugin (WEB-INF/lib/)?

Transitive or not if the jar is provided by another plugin then it really doesn't matter and as you said  maven doesn't understand the Jenkins plugin dependent chain.
Either the library is bundled in the plugin or we don't care, unless maven shading is going on, but shading wouldn't show in a dependency tree either.

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DB8PR04MB66490FC5F452F3757EEEAA30D300A%40DB8PR04MB6649.eurprd04.prod.outlook.com.

Filipe Roque

unread,
Jul 27, 2023, 9:28:33 AM7/27/23
to jenkin...@googlegroups.com
If you are obtaining the pom from the hpi, then as you have the hpi why not just see what version if any is in the plugin (WEB-INF/lib/)?

Did not think of that. It actually seems a better approach. I have added a second sheet with results from this to the spreadsheet.

Filipe Roque

Mark Waite

unread,
Dec 14, 2023, 10:40:45 AM12/14/23
to Jenkins Developers
Now available as API plugins (thanks to Valentin Delaye!)
They are included in the plugin bill of materials (2643 and 2641).  Pull requests have been opened to several plugins that were consuming those APIs.

Basil Crow

unread,
Dec 14, 2023, 2:04:11 PM12/14/23
to jenkin...@googlegroups.com
We have also explicitly clarified that public domain dedications and
public-domain-equivalent licenses are acceptable in the project
governance document.
Reply all
Reply to author
Forward
0 new messages