About Maven Central's Terms of Use
73 views
Skip to first unread message
admin
Jul 20, 2019, 12:41:06 PM7/20/19
to css4j
As mentioned in other posts, I do not agree to Maven Central's Terms of Use. Here is a more detailed account of why, so the situation can be better understood. Comments are welcome.
Introduction
To publish their artifacts on Maven Central, software developers have to agree to Sonatype's Terms of Use.
1. Maven Central is a monopoly
That centralized model implies a single point of failure (although Maven Central has a good track record of reliability and availability), and for example if you want to verify the integrity of the artifacts with checksums/signatures stored at a different location, you have to do that yourself (at least the last time I checked).
To compete against Maven Central, a company would need not only to convince end users to modify their Maven's settings.xml files to allow that, but also to replicate most of the artifacts contained at Central, currently more than four million. That is due to the centralized model, where the distribution is not cooperative (i.e. with different servers sharing the responsibility to distribute the artifacts). If users do not find all of their desired artifacts in your competing repository, they are unlikely to use it.
Given the fact that Central is the de-facto standard repository used by Java software projects, in practice, if a software artifact is not available from Central it is unlikely to be widely used (as has been mentioned already in other posts in this forum). That is the very definition of a monopoly, and a good reason to look at the legal issues very closely.
2. Overlapping Terms of Use
https://central.sonatype.org/pages/central-repository-producer-terms.html
That document contains four numbered items and a few non-numbered sections.
However, there is also another page containing wider Terms of Use that apply to the repository:
https://repo1.maven.org/terms.html
is located at the repository server itself and contains 13 numbered items. There is overlapping, and the "producer" Terms say:
which implies that the actual terms that govern the relationship between you and Central are a merge of documents that has to be interpreted. And it should not be forgotten that submitting an artifact involves the use of sonatype.org subdomains that presumably have its own terms.
3. Asymmetry of liability/indemnification
If they do not want to have liability, why do they want it (all of it and more) from me?
Concerning the end user, the "terms.html" document says:
which is good for the user that downloads the artifact, but its author/submitter is still giving warranty and liability to Sonatype. Other sites have similarly bad indemnification clauses, but at least establish some limits like "we give you sole control of the defence and settlement of the claim, demand, suit or proceeding". Here you do not even have that.
4. Automatic retroactive acceptance of modifications
The "central-repository-producer-terms.html" page says:
If a developer submits an artifact to Central, he/she does that under an agreement, and that agreement should be valid in the future. But here that agreement involves reviewing the Terms "from time to time", as otherwise you are retroactively accepting changes to the original agreement, and that happens by just using Central (and that presumably means any retrieval from the Central repository that is done by Apache Maven).
It is reasonable that a site establishes possible unilateral changes (like the possibility of closing the whole site) in its usage agreement, and if you use Apache Maven it is also unavoidable that the terms of use may change. But again, the overlapping between "submitting an artifact" and "using the repository" (point 2) is problematic.
And if the terms of use of the repository are changed, I expect at least to see a warning emitted by Maven. Most Maven users are probably unaware of the Terms of Use of the repository that they are using.
Finally, the "if you do not agree, don't use the Central Repository" seems fine, but do not forget that we are talking about a monopoly, with consequences that could be mitigated (for example, by introducing an optional direct download configuration in the 'dependency' section of the POM file).
I do not agree, so I do not use the Central Repository. I had little choice but to accept the (less bad) Github terms for a project that was already started, but that's all what I can reach.
Maven Central is a centralized software repository (mostly for the Java language/platform) containing pieces of software (called artifacts), that are available for download by a software called 'Apache Maven' developed by the Apache Software Foundation. It is operated by a company -Sonatype- which was co-founded by the developer that created Apache Maven.
To publish their artifacts on Maven Central, software developers have to agree to Sonatype's Terms of Use.
1. Maven Central is a monopoly
The Maven distribution model naturally leads to a monopoly. It has a central server where all the artifacts are located, instead of just storing metadata about them (like download URLs and hashes/signatures to verify the integrity of the files). I'm not against a server storing copies of the artifacts, but with the Maven centralized model all the distribution is done by the configured repository. Maven Central is configured by default in Apache Maven.
That centralized model implies a single point of failure (although Maven Central has a good track record of reliability and availability), and for example if you want to verify the integrity of the artifacts with checksums/signatures stored at a different location, you have to do that yourself (at least the last time I checked).
To compete against Maven Central, a company would need not only to convince end users to modify their Maven's settings.xml files to allow that, but also to replicate most of the artifacts contained at Central, currently more than four million. That is due to the centralized model, where the distribution is not cooperative (i.e. with different servers sharing the responsibility to distribute the artifacts). If users do not find all of their desired artifacts in your competing repository, they are unlikely to use it.
Given the fact that Central is the de-facto standard repository used by Java software projects, in practice, if a software artifact is not available from Central it is unlikely to be widely used (as has been mentioned already in other posts in this forum). That is the very definition of a monopoly, and a good reason to look at the legal issues very closely.
2. Overlapping Terms of Use
The guide to deploy artifacts at central (https://central.sonatype.org/pages/ossrh-guide.html) mentions that the "full terms of service" are at:
https://central.sonatype.org/pages/central-repository-producer-terms.html
That document contains four numbered items and a few non-numbered sections.
However, there is also another page containing wider Terms of Use that apply to the repository:
https://repo1.maven.org/terms.html
is located at the repository server itself and contains 13 numbered items. There is overlapping, and the "producer" Terms say:
"In the event of a direct conflict between the Central Repository Terms of Service and these Central Repository Producer Terms, the Central Repository Producer Terms will control."
which implies that the actual terms that govern the relationship between you and Central are a merge of documents that has to be interpreted. And it should not be forgotten that submitting an artifact involves the use of sonatype.org subdomains that presumably have its own terms.
3. Asymmetry of liability/indemnification
Liability of Sonatype is heavily limited (which is understandable for a free service), but in turn the 'Indemnity' clause is too broad and implies giving warranty (in fact more than warranty) to Sonatype, which goes against the liability-related provisions in many open source licences.
If they do not want to have liability, why do they want it (all of it and more) from me?
Concerning the end user, the "terms.html" document says:
"The applicable licenses or terms of use which accompany any Materials you download will govern your rights and obligations regarding such Materials, and you agree to be bound accordingly."
which is good for the user that downloads the artifact, but its author/submitter is still giving warranty and liability to Sonatype. Other sites have similarly bad indemnification clauses, but at least establish some limits like "we give you sole control of the defence and settlement of the claim, demand, suit or proceeding". Here you do not even have that.
4. Automatic retroactive acceptance of modifications
The "central-repository-producer-terms.html" page says:
"We may change the Terms of Service at any time without any notice to you. It is your responsibility to review the Terms of Service from time to time for any changes as it creates binding legal agreement between you and Sonatype. If you use the Central Repository or make submissions after we've changed any of the Terms of Service, you are agreeing to all of the changes. Again, if you do not agree, don't use the Central Repository."
If a developer submits an artifact to Central, he/she does that under an agreement, and that agreement should be valid in the future. But here that agreement involves reviewing the Terms "from time to time", as otherwise you are retroactively accepting changes to the original agreement, and that happens by just using Central (and that presumably means any retrieval from the Central repository that is done by Apache Maven).
It is reasonable that a site establishes possible unilateral changes (like the possibility of closing the whole site) in its usage agreement, and if you use Apache Maven it is also unavoidable that the terms of use may change. But again, the overlapping between "submitting an artifact" and "using the repository" (point 2) is problematic.
And if the terms of use of the repository are changed, I expect at least to see a warning emitted by Maven. Most Maven users are probably unaware of the Terms of Use of the repository that they are using.
Finally, the "if you do not agree, don't use the Central Repository" seems fine, but do not forget that we are talking about a monopoly, with consequences that could be mitigated (for example, by introducing an optional direct download configuration in the 'dependency' section of the POM file).
I do not agree, so I do not use the Central Repository. I had little choice but to accept the (less bad) Github terms for a project that was already started, but that's all what I can reach.
Reply all
Reply to author
Forward
0 new messages