-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adjusting some license texts. #7034
Conversation
@@ -1,6 +1,6 @@ | |||
Name: NetBeans processtreekiller | |||
Version: 2.0.1 | |||
License: MIT | |||
License: MIT-processtreekiller |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MIT is a generic template of the license, without copyright notices. This file is correct, but we should have the correct file in the nbbuild/licenses
database as well.
See the source license here:
https://github.com/matthiasblaesing/netbeans-processtreekiller/blob/master/LICENSE
@@ -1,10 +1,10 @@ | |||
Name: SLF4J | |||
Version: 1.7.36 | |||
License: MIT-slf4j | |||
License: MIT-slf4j-22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The source license for 1.7.36 is here:
https://raw.githubusercontent.com/qos-ch/slf4j/v_1.7.36/LICENSE.txt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file nbbuild/licenses/MIT-slf4j
could be removed. Not really a problem, but cleaning up now would IMHO make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
@@ -1,10 +1,10 @@ | |||
Name: SLF4J | |||
Version: 1.7.36 | |||
License: MIT-slf4j | |||
License: MIT-slf4j-22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The source license for 1.7.36 is here:
https://raw.githubusercontent.com/qos-ch/slf4j/v_1.7.36/LICENSE.txt
@@ -4,6 +4,7 @@ Version: 1.14.1 | |||
Origin: GitHub | |||
License: Apache-2.0 | |||
URL: https://github.com/timboudreau/simplevalidation/ | |||
Files: simplevalidation-1.14.1.jar simplevalidation-swing-1.14.1.jar |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of using two license files, lets try to only use one. This is to simplify using of the notice file.
@@ -0,0 +1,3 @@ | |||
ValidationAPI version 1.14.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An attempt to add copyright from here:
https://github.com/timboudreau/simplevalidation/blob/master/apache-license-2x.txt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined not to honor broken licenses. The Apache license explicitly states, that the file you have to look for as a user is NOTICE. If it is not there, I would ignore it, the user obiously was not interested in it either. There is also no NOTICE in the binary jar, further strengthening the point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, OK. I don't I like that (because the repository has a license file with the copyright), but I can probably live with this, at least for some time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If someone tells me he linceses his product under ALv2 and does not provide a NOTICE, I think the intention is obvious. If we assume that it is not ALv2, but an unnamed license derived from ALv2, then I suggest to make it "ALv2-simplevalidation" and use that, just as done with MIT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. I've dropped this from this patch. I guess that while you may be technically right, being nice also may provides some advantages.
@@ -0,0 +1,565 @@ | |||
Name: httpclient 4.5.14, as part of Maven distribution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The license for httpclient is not Apache 2.0 - it is Apache 2.0 + MPL 2.0, please see:
https://issues.apache.org/jira/browse/HTTPCLIENT-2317
https://issues.apache.org/jira/browse/MNG-8042
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I agree with your reading on this one. Or theirs? I would check with ASF legal on this, or if they did, because I don't see any reason that needs to be a dual licensed binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note it is not a dual license. There are parts that are Apache 2.0, and parts (specifically the 'mozilla/public-suffix-list.txt' file) that are under the MPL 2.0. It is not really different from NetBeans' various 3rd party stuff.
I think this:
https://www.apache.org/legal/release-policy.html#license-file
is pretty clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note from MPL.
3.3. Distribution of a Larger Work
You may create and distribute a Larger Work under terms of Your choice,
provided that You also comply with the requirements of this License for
the Covered Software. If the Larger Work is a combination of Covered
Software with a work governed by one or more Secondary Licenses, and the
Covered Software is not Incompatible With Secondary Licenses, this
License permits You to additionally distribute such Covered Software
under the terms of such Secondary License(s), so that the recipient of
the Larger Work may, at their option, further distribute the Covered
Software under the terms of either this License or such Secondary
License(s).
As far as I can see that file is downloaded (as it should be under Cat B), so shouldn't be included in the source license file. In binary form, it could all be under ASL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understand the complaint. This patch will not (to the best of my knowledge) make this part of the license for the source. It will make it part of the license for the binary. This is very similar to what we do e.g. here:
https://github.com/apache/netbeans/blob/b5bf037d91bc3f0fa4a09518ba4fd6c105f965c4/java/maven.embedder/external/apache-maven-3.9.6-javax.annotation-api-license.txt
(and for a somewhat similar license)
I wonder if there's some specific concern around MPL (or including MPL) that would warrant investigating alternative options? (Note that even the official binary distributed by Apache Commons has Apache 2.0 + MPL 2.0, it is just the specific artifact that is missing MPL.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For httpclient (both httpclient and httpcore) the license in the package is pure ALv2.0. I would suggest to stick with the upstream license and not pretend to know better. Once httpclient gets updated, I see no problem to follow though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not quite sure why this specific change is so problematic. The official package distributed by ASF does have the MPL in its LICENSE.txt:
https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-4.5.14-bin.tar.gz
Even the source repository lists it:
https://github.com/apache/httpcomponents-client/blob/master/LICENSE.txt
This binary obviously has the MPL-licensed file. It is just the LICENSE file in this specific file that is missing it. It is fairly obviously a mistake. Do we really want to keep distributing something that's wrong? (Or, at least, highly doubtful?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no problem updating this here.
BUT: I refuse to chase down the potential intention of a packager through multiple layers of packages. httpclient-4.5.14.jar
and httpcore-4.4.16.jar
in the apache-maven-3.9.6-bin.zip
both contain a LICENSE, both without MPL reference. It seems, that the maven central binaries are missing that part. This is an issue in apache maven. Next time this is updated, we will see a regression if it is not fixed in apache http client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The license file in the source tree is wrong. The license file in the Maven binary might not be wrong. MPL gives the right to redistribute that artefact under ASL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed this change to avoid the controversy.
Note that I've filled bugs against httpclient and Maven. So, while there's a potential for a regression on update, I think I did a lot to avoid that in the future. (And updating licenses is, sadly, not automatic when upgrading a library, so there's also an opposite risk - that Maven is fixed, but NetBeans is not.)
No sure I understand the argument of "they have it wrong, so it is OK for us to have it wrong". (While I hear Neil's idea about distributing under Apache 2.0 - noone has confirmed that would be what ASF could or would want to do.)
@@ -1,5 +1,5 @@ | |||
Name: Javax Annotation API | |||
Version: 3.9.6 | |||
Version: 1.3.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifying more appropriate version, to reduce confusion.
@@ -1,6 +1,6 @@ | |||
Name: slf4j | |||
Description: Part of Apache Maven Distribution | |||
Version: 3.9.6 | |||
Version: 1.7.36 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specifying more appropriate version, to reduce confusion.
@@ -1,7 +1,7 @@ | |||
Name: Knockout4J | |||
Version: 1.8.1 | |||
Description: Knockout4J | |||
License: Apache-2.0 | |||
License: Apache-2.0-ko4j |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating the ko4j license to the version that is inside the binary - includes license terms for the Knockout library, in addition to the Apache 2.0 terms.
@@ -1,39 +1,421 @@ | |||
Name: icu4j | |||
Description: icu4j license | |||
License: MIT-icu4j | |||
License: MIT-icu4j-58 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updating the license text to the text that is inside the binary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for looking into this. I left some inline comments.
@@ -1,10 +1,10 @@ | |||
Name: SLF4J | |||
Version: 1.7.36 | |||
License: MIT-slf4j | |||
License: MIT-slf4j-22 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file nbbuild/licenses/MIT-slf4j
could be removed. Not really a problem, but cleaning up now would IMHO make sense.
@@ -0,0 +1,3 @@ | |||
ValidationAPI version 1.14.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm inclined not to honor broken licenses. The Apache license explicitly states, that the file you have to look for as a user is NOTICE. If it is not there, I would ignore it, the user obiously was not interested in it either. There is also no NOTICE in the binary jar, further strengthening the point.
@@ -0,0 +1,565 @@ | |||
Name: httpclient 4.5.14, as part of Maven distribution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For httpclient (both httpclient and httpcore) the license in the package is pure ALv2.0. I would suggest to stick with the upstream license and not pretend to know better. Once httpclient gets updated, I see no problem to follow though.
5d60f9f
to
2928a01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good to go. Thank you for the updates.
would this be ready to merge or is it still baking? |
I'll merge sometime soon, unless there are objections. |
2928a01
to
08b8b68
Compare
The proposal here is to adjust some license texts (+one notice), which I hope will be relatively uncontroversial. I'll try to add comments with details inline.
Some more tweaks to license files may come in the future.