Details

    • Type: Question Question
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      Description

      The JCR API jar file is available under the terms of the Day spec license [1] and the addendum [2]. The essential part of the addendum says:

      In addition to the permissions granted under the Specification
      License, Day Management AG hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      license to reproduce, publicly display, publicly perform,
      sublicense, and distribute unmodified copies of the Content
      Repository for Java Technology API (JCR 1.0) Java Archive (JAR)
      file ("jcr-1.0.jar") and to make, have made, use, offer to sell,
      sell, import, and otherwise transfer said file on its own or
      as part of a larger work that makes use of the JCR API.

      This is pretty much similar to the LEGAL-36 case where broad rights are given to redistribute unmodified versions of the file. The consensus seems to be that such dependencies are OK and can be embedded in binaries, but that such unmodifiable files should not be kept in our svn.

      [1] http://www.day.com/maven/jsr170/licenses/day-spec-license.htm
      [2] http://www.day.com/maven/jsr170/jars/LICENSE.txt

        Activity

        Jukka Zitting created issue -
        Hide
        Henri Yandell added a comment -

        Spec license, so I see why it wants to limit modification. I don't see a huge urge on our part to want to modify it - but it's feasible that the JSR could go stagnant and we want to fix a bug. Really it's only the public API of the spec that should remain unmodified and we should have the right to modify the internal private code.

        We need to have http://www.day.com/maven/jsr170/licenses/day-spec-license.htm looked at. I'll admit to not understanding it all. Sections 1, 2, 3 and 4 all confuse me; though it is nice to see a spec jar under a spec discussing license.

        Show
        Henri Yandell added a comment - Spec license, so I see why it wants to limit modification. I don't see a huge urge on our part to want to modify it - but it's feasible that the JSR could go stagnant and we want to fix a bug. Really it's only the public API of the spec that should remain unmodified and we should have the right to modify the internal private code. We need to have http://www.day.com/maven/jsr170/licenses/day-spec-license.htm looked at. I'll admit to not understanding it all. Sections 1, 2, 3 and 4 all confuse me; though it is nice to see a spec jar under a spec discussing license.
        Hide
        Jukka Zitting added a comment -

        AFAIUI the JSPA prevents a spec lead from licensing a spec jar under terms that allow modification.

        See JCR-592 for some past discussion that later led to the creation of the license addendum. The addendum was added to avoid many of the restrictions in the original spec license.

        Show
        Jukka Zitting added a comment - AFAIUI the JSPA prevents a spec lead from licensing a spec jar under terms that allow modification. See JCR-592 for some past discussion that later led to the creation of the license addendum. The addendum was added to avoid many of the restrictions in the original spec license.
        Hide
        Jukka Zitting added a comment -

        Any more comments on this? I'd like to resolve this by extending the solution of LEGAL-36 to cover also standard APIs that can be freely redistributed in unmodified form.

        Show
        Jukka Zitting added a comment - Any more comments on this? I'd like to resolve this by extending the solution of LEGAL-36 to cover also standard APIs that can be freely redistributed in unmodified form.
        Hide
        Niclas Hedhman added a comment -

        The LICENSE.txt is a bit bizarre. I have the right to sublicense an unmodified copy of the JAR. But if I then sublicense under Apache License the next user is allowed to modify it.

        I would like to be practical in this case. Clearly the "intent" from Day and the spec lead is to try and make sure that the specification doesn't fork, yet allow any licensing terms on the implementation. Considering that Day is just like "family", I think we safely can go ahead. If there is something we are doing wrong, I am sure a nudge from Day will push us in the right direction. Especially since I guess it is mostly Day employees that will be working on this...

        Show
        Niclas Hedhman added a comment - The LICENSE.txt is a bit bizarre. I have the right to sublicense an unmodified copy of the JAR. But if I then sublicense under Apache License the next user is allowed to modify it. I would like to be practical in this case. Clearly the "intent" from Day and the spec lead is to try and make sure that the specification doesn't fork, yet allow any licensing terms on the implementation. Considering that Day is just like "family", I think we safely can go ahead. If there is something we are doing wrong, I am sure a nudge from Day will push us in the right direction. Especially since I guess it is mostly Day employees that will be working on this...
        Hide
        Jukka Zitting added a comment -

        > I have the right to sublicense an unmodified copy of the JAR. But if I then sublicense
        > under Apache License the next user is allowed to modify it.

        You can only sublicense the jar under terms that prevents it from being modified.

        Show
        Jukka Zitting added a comment - > I have the right to sublicense an unmodified copy of the JAR. But if I then sublicense > under Apache License the next user is allowed to modify it. You can only sublicense the jar under terms that prevents it from being modified.
        Hide
        Henri Yandell added a comment -

        Not a huge fan of JSR spec licenses, but I'm happy to consider this license as fine for the JCR API jar - "jcr-1.0.jar".

        Suggested action item is to add this as a specific item to resolved.html.

        Show
        Henri Yandell added a comment - Not a huge fan of JSR spec licenses, but I'm happy to consider this license as fine for the JCR API jar - "jcr-1.0.jar". Suggested action item is to add this as a specific item to resolved.html.
        Hide
        Henri Yandell added a comment -

        svn ci -m "Adding the JCR jars as unmodifieds that shouldn't be in SVN - LEGAL-50"
        Sending docs/legal/resolved.html
        Sending xdocs/legal/resolved.xml
        Transmitting file data ..
        Committed revision 944124.

        Show
        Henri Yandell added a comment - svn ci -m "Adding the JCR jars as unmodifieds that shouldn't be in SVN - LEGAL-50 " Sending docs/legal/resolved.html Sending xdocs/legal/resolved.xml Transmitting file data .. Committed revision 944124.
        Henri Yandell made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Jukka Zitting
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development