Legal Discuss
  1. Legal Discuss
  2. LEGAL-24

Scripts, source, and Reciprocal Licenses

    Details

    • Type: Question Question
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      The current draft of the Third Party Licensing Policy (0.53) contains the following text under the section concerning Reciprocal Licenses:

      Note that works written in a scripting language without a binary form cannot be included in any ASF product under one of these licenses (see Transition and Exceptions).

      We need to decide if this truly is necessary.

        Issue Links

          Activity

          Hide
          Henri Yandell added a comment -

          I think the main reason for this was that there is less likelyhood of a binary being modified, therefore much less times in which we'd have to be concerned about how much of our code was under another license. The manifests in category B licenses is a good example; they are under the copyleft license but shrug we didn't care.

          So for a javascript MPL file, I think we would be happy for any modifications to that file to remain under MPL. No big deal imo. As long as things are very well described, and we avoid building a new product on that MPL library, tis good. So I think we want to discourage forking, even more than usual, and that every file under a category B should be listed in the README.

          Questions from the above for brevity:

          • What reasons do we have to say no to Category B source?
          • Any value in strongly discouraging forking/modifications?
          • Do we need any higher level of documentation in the project to point out the licensing of the file?
          Show
          Henri Yandell added a comment - I think the main reason for this was that there is less likelyhood of a binary being modified, therefore much less times in which we'd have to be concerned about how much of our code was under another license. The manifests in category B licenses is a good example; they are under the copyleft license but shrug we didn't care. So for a javascript MPL file, I think we would be happy for any modifications to that file to remain under MPL. No big deal imo. As long as things are very well described, and we avoid building a new product on that MPL library, tis good. So I think we want to discourage forking, even more than usual, and that every file under a category B should be listed in the README. Questions from the above for brevity: What reasons do we have to say no to Category B source? Any value in strongly discouraging forking/modifications? Do we need any higher level of documentation in the project to point out the licensing of the file?
          Hide
          Sam Ruby added a comment -

          Not only is it not clear that we have consensus on this, I believe it to be controversial. When stated as a hypothetical, people tend to take "principled" stances – on both sides.

          My experience is that when faces with an actual, tangible project with real needs, people tend to be pragmatic. As such, I would prefer that this issue either remain open (or alternatively, be closed with a status of Later or somesuch) until such use cases arise.

          Show
          Sam Ruby added a comment - Not only is it not clear that we have consensus on this, I believe it to be controversial. When stated as a hypothetical, people tend to take "principled" stances – on both sides. My experience is that when faces with an actual, tangible project with real needs, people tend to be pragmatic. As such, I would prefer that this issue either remain open (or alternatively, be closed with a status of Later or somesuch) until such use cases arise.
          Hide
          Henri Yandell added a comment -

          From Sam on an FCKEditor thread last Jan 08:

          "Roy said it a while back a lot more eloquently than I ever could, but when we are dealing with artifacts are customarily provided and consumed in source form, then us blindly applying a rule that we avoid licenses that requires that such artifacts be provided in source form is nonsensical and counter-productive. "

          I agree. We want to say "don't modify", and we allow binary because there is less chance of modification. The risk of modification for a category B license is that our modifications go out under that license (as with the OSGI changes that we've allowed). How about the following:

          • Category B. Use unmodified. Raise on legal-discuss or open a JIRA if you wish to add to or modify one of these works. See the following list of allowed modifications:
            • OSGi example.

          I'm also thinking that modifications should be noted clearly in the NOTICE of the Apache project.

          Show
          Henri Yandell added a comment - From Sam on an FCKEditor thread last Jan 08: "Roy said it a while back a lot more eloquently than I ever could, but when we are dealing with artifacts are customarily provided and consumed in source form, then us blindly applying a rule that we avoid licenses that requires that such artifacts be provided in source form is nonsensical and counter-productive. " I agree. We want to say "don't modify", and we allow binary because there is less chance of modification. The risk of modification for a category B license is that our modifications go out under that license (as with the OSGI changes that we've allowed). How about the following: Category B. Use unmodified. Raise on legal-discuss or open a JIRA if you wish to add to or modify one of these works. See the following list of allowed modifications: OSGi example. I'm also thinking that modifications should be noted clearly in the NOTICE of the Apache project.
          Hide
          Henri Yandell added a comment -

          Sam said:

          "Not sure where that text goes, but I support the idea.

          I'd suggest leaving the text requesting a "prominent label". I'd also
          suggest that the requirement for object/binary form shouldn't
          completely go away, merely that it be demoted to a suggestion, and
          "where possible/appropriate" or somesuch be added."

          Show
          Henri Yandell added a comment - Sam said: "Not sure where that text goes, but I support the idea. I'd suggest leaving the text requesting a "prominent label". I'd also suggest that the requirement for object/binary form shouldn't completely go away, merely that it be demoted to a suggestion, and "where possible/appropriate" or somesuch be added."
          Hide
          Jukka Zitting added a comment -

          Agreed with Henri above, though again with a concern about using the NOTICE file for such remarks.

          We may want to encourage projects (that have a build process) to keep such "don't modify" sources in packaged format in svn and source releases, and only unpack them into resulting binaries as a part of the build process.

          Show
          Jukka Zitting added a comment - Agreed with Henri above, though again with a concern about using the NOTICE file for such remarks. We may want to encourage projects (that have a build process) to keep such "don't modify" sources in packaged format in svn and source releases, and only unpack them into resulting binaries as a part of the build process.

            People

            • Assignee:
              Unassigned
              Reporter:
              Sam Ruby
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development