Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.12.0
    • Component/s: core
    • Labels:
      None

      Description

      If we update the version of jsr305 that we use, we also obtain clarity on the license of the artifact to assuage any concerns.

        Issue Links

          Activity

          Hide
          julianhyde Julian Hyde added a comment -

          Resolved in release 1.12.0 (2017-03-24).

          Show
          julianhyde Julian Hyde added a comment - Resolved in release 1.12.0 (2017-03-24).
          Hide
          elserj Josh Elser added a comment -

          Thanks for merging this in, Julian.

          Show
          elserj Josh Elser added a comment - Thanks for merging this in, Julian.
          Show
          julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/34df5a5a .
          Hide
          elserj Josh Elser added a comment -

          Thanks!

          Show
          elserj Josh Elser added a comment - Thanks!
          Hide
          julianhyde Julian Hyde added a comment -

          Thanks. I have merged the PR to julianhyde/master. I will push to apache/master after 1.11 has closed.

          Show
          julianhyde Julian Hyde added a comment - Thanks. I have merged the PR to julianhyde/master. I will push to apache/master after 1.11 has closed.
          Show
          elserj Josh Elser added a comment - https://github.com/apache/calcite/pull/346
          Hide
          elserj Josh Elser added a comment -

          There is another option, by the way: upgrade com.google.code.findbugs:jsr305 to 3.0.1. They have clarified the license.

          That sounds like a very happy middle ground. Will poke at this when I have a moment.

          Show
          elserj Josh Elser added a comment - There is another option, by the way: upgrade com.google.code.findbugs:jsr305 to 3.0.1. They have clarified the license. That sounds like a very happy middle ground. Will poke at this when I have a moment.
          Hide
          julianhyde Julian Hyde added a comment -

          There is another option, by the way: upgrade com.google.code.findbugs:jsr305 to 3.0.1. They have clarified the license.

          Show
          julianhyde Julian Hyde added a comment - There is another option, by the way: upgrade com.google.code.findbugs:jsr305 to 3.0.1. They have clarified the license .
          Hide
          elserj Josh Elser added a comment -

          I don't think anyone ever intended to release this under GPL or LGPL, and I don't think anyone believes that anyone released it under GPL or LGPL.

          I hate to get into such an argument, but I don't know that.

          To me, the pom accompanying the jar in maven central is much clearer evidence of intent than the text on the findbugs web site.

          This pom? http://search.maven.org/#artifactdetails%7Ccom.google.code.findbugs%7Cjsr305%7C1.3.9%7Cjar Maybe I'm missing something, but it seems awfully unclear (claims to be ASLv2, points to a website which says lgpl/gpl in the first paragraph, but actually is BSD).

          even though we know that there is no fire

          I don't agree with your analogy here, again, because I do not accept that it is clear-cut that it obviously is BSD licensed. Additionally, I'm calmly asking a question – no jumping at all

          There is a cost to transitioning to Stephen Colebourne's version: we stop using the javax.annotation package name, so we are no longer compliant with JSR-305.

          This is true – I'm not sure if/how it would affect the maven-findbugs-plugin or other static analysis tools.

          Show
          elserj Josh Elser added a comment - I don't think anyone ever intended to release this under GPL or LGPL, and I don't think anyone believes that anyone released it under GPL or LGPL. I hate to get into such an argument, but I don't know that. To me, the pom accompanying the jar in maven central is much clearer evidence of intent than the text on the findbugs web site. This pom? http://search.maven.org/#artifactdetails%7Ccom.google.code.findbugs%7Cjsr305%7C1.3.9%7Cjar Maybe I'm missing something, but it seems awfully unclear (claims to be ASLv2, points to a website which says lgpl/gpl in the first paragraph, but actually is BSD). even though we know that there is no fire I don't agree with your analogy here, again, because I do not accept that it is clear-cut that it obviously is BSD licensed. Additionally, I'm calmly asking a question – no jumping at all There is a cost to transitioning to Stephen Colebourne's version: we stop using the javax.annotation package name, so we are no longer compliant with JSR-305. This is true – I'm not sure if/how it would affect the maven-findbugs-plugin or other static analysis tools.
          Hide
          julianhyde Julian Hyde added a comment -

          The most likely explanation seems to be this: The findbugs project did not author this library. They just posted it to maven central under their group-id (because maven central will only allow you to upload artifacts under a group-id that you own). As a BSD library, they have a right to do that. They botched the license, accidentally labeling it ASL when it should be BSD. I don't think anyone ever intended to release this under GPL or LGPL, and I don't think anyone believes that anyone released it under GPL or LGPL.

          To me, the pom accompanying the jar in maven central is much clearer evidence of intent than the text on the findbugs web site.

          There is a cost to transitioning to Stephen Colebourne's version: we stop using the javax.annotation package name, so we are no longer compliant with JSR-305.

          And also, if we run when someone shouts "Fire!" in the movie theatre, even though we know that there is no fire, we are nevertheless adding to the panic.

          Show
          julianhyde Julian Hyde added a comment - The most likely explanation seems to be this: The findbugs project did not author this library. They just posted it to maven central under their group-id (because maven central will only allow you to upload artifacts under a group-id that you own). As a BSD library, they have a right to do that. They botched the license, accidentally labeling it ASL when it should be BSD. I don't think anyone ever intended to release this under GPL or LGPL, and I don't think anyone believes that anyone released it under GPL or LGPL. To me, the pom accompanying the jar in maven central is much clearer evidence of intent than the text on the findbugs web site. There is a cost to transitioning to Stephen Colebourne's version: we stop using the javax.annotation package name, so we are no longer compliant with JSR-305. And also, if we run when someone shouts "Fire!" in the movie theatre, even though we know that there is no fire, we are nevertheless adding to the panic.
          Hide
          elserj Josh Elser added a comment -

          https://lists.apache.org/thread.html/f229214afd75e07017c0ae17f1d23244946b2ba2fefbd1526427450c@%3Cdev.fluo.apache.org%3E was the email I was thinking of.

          The lineage of jsr305 from google code making it to https://github.com/amaembo/jsr-305 is also a little sketchy (do we know if this is actually the same author?). Personally, it's the sum of this ambiguity and the ease of a replacement which pushes me into the "just replace it" mindset.

          Show
          elserj Josh Elser added a comment - https://lists.apache.org/thread.html/f229214afd75e07017c0ae17f1d23244946b2ba2fefbd1526427450c@%3Cdev.fluo.apache.org%3E was the email I was thinking of. The lineage of jsr305 from google code making it to https://github.com/amaembo/jsr-305 is also a little sketchy (do we know if this is actually the same author?). Personally, it's the sum of this ambiguity and the ease of a replacement which pushes me into the "just replace it" mindset.
          Hide
          elserj Josh Elser added a comment -

          http://findbugs.sourceforge.net/ was one of the original sources of confusion.

          Looking at some of the source code is also worrisome https://github.com/findbugsproject/findbugs/blob/master/findbugs/src/java/edu/umd/cs/findbugs/annotations/CheckForNull.java

          A big problem is that the JAR contains no information and I've not had great success finding a de-facto explanation. There was an email from a guy who did some good digging showing it was (likely) ASLv2. I'll try to find that too.

          Show
          elserj Josh Elser added a comment - http://findbugs.sourceforge.net/ was one of the original sources of confusion. Looking at some of the source code is also worrisome https://github.com/findbugsproject/findbugs/blob/master/findbugs/src/java/edu/umd/cs/findbugs/annotations/CheckForNull.java A big problem is that the JAR contains no information and I've not had great success finding a de-facto explanation. There was an email from a guy who did some good digging showing it was (likely) ASLv2. I'll try to find that too.
          Hide
          julianhyde Julian Hyde added a comment -

          Can you provide some evidence? I saw HBASE-16321 but that just looks like people are being over-cautious.

          Show
          julianhyde Julian Hyde added a comment - Can you provide some evidence? I saw HBASE-16321 but that just looks like people are being over-cautious.

            People

            • Assignee:
              elserj Josh Elser
              Reporter:
              elserj Josh Elser
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development