Legal Discuss
  1. Legal Discuss
  2. LEGAL-120

Is the Adobe RTMP specification license compatible?

    Details

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

      Description

      Someone has asked for a RTMP plugin for JMeter.

      The RTMP specification is available from [0]; the specification license is here [1].
      AIUI the license must be accepted before any implementation is distributed, so I assume that:

      • any implementation created by the ASF using the spec would need to abide by the license, and
      • any 3rd party implementation that used the spec would also need to abide by the license.

      Are there any terms in the license that are unacceptable for the ASF?

      [0] http://www.adobe.com/devnet/rtmp.html
      [1] http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/rtmp_specification_license_1.0.pdf

        Activity

        Hide
        Sebb added a comment -

        The document at [1] is the license for the spec, not the spec itself, so I don't understand why the link should be forbidden?

        Show
        Sebb added a comment - The document at [1] is the license for the spec, not the spec itself, so I don't understand why the link should be forbidden?
        Hide
        Robert Burrell Donkin added a comment -

        A rather curious document. Seemingly, the intention is that anyone who downloads [0] after reading [1] agrees to be bound by [1].

        Show
        Robert Burrell Donkin added a comment - A rather curious document. Seemingly, the intention is that anyone who downloads [0] after reading [1] agrees to be bound by [1] .
        Hide
        Robert Burrell Donkin added a comment -

        Anyone reading [0] and [1] seemingly agrees not to use implementations of the RTMP specification for some prohibited uses. Perhaps this restricts authors of derivative works. Or perhaps not.

        This one seems unusual enough to me to take to internal legal...

        Show
        Robert Burrell Donkin added a comment - Anyone reading [0] and [1] seemingly agrees not to use implementations of the RTMP specification for some prohibited uses. Perhaps this restricts authors of derivative works. Or perhaps not. This one seems unusual enough to me to take to internal legal...
        Hide
        Robert Burrell Donkin added a comment -

        I've pinged the list.

        Show
        Robert Burrell Donkin added a comment - I've pinged the list.
        Hide
        Sebb added a comment -

        Actually, [0] is the covering page, not the spec.; the spec. is linked from [0], as is the spec. license at [1].

        So generally the user will read [0] first; they may or may not read [1] before downloading the spec. itself.
        I've not downloaded or read the spec. itself, so I don't know if it has any license conditions at the start.

        Show
        Sebb added a comment - Actually, [0] is the covering page, not the spec.; the spec. is linked from [0] , as is the spec. license at [1] . So generally the user will read [0] first; they may or may not read [1] before downloading the spec. itself. I've not downloaded or read the spec. itself, so I don't know if it has any license conditions at the start.
        Hide
        Roy T. Fielding added a comment -

        I am an Adobe employee, but I am not commenting from the perspective of Adobe and don't have the right to make any additional license on Adobe's behalf. However, I can read legalese.

        There is no harm in reading the license or the spec. The specification license is a conditional patent license that provides a license to implementations that are compliant with the spec for those claims that Adobe owns that are necessarily infringed by implementing the spec. The conditions that are not licensed are listed in the license, but loosely summarized as implementations that attempt to intercept or circumvent DRM-protected content. You cannot lose any rights that you already have by accessing or reading the spec, since the license only gives you permission to do some things that otherwise might be forbidden due to Adobe's patents (I do not know which ones, nor do I know when they might expire, but in any case you won't need the license at all if no valid patents remain or if you don't happen to implement the spec).

        In other words, this is similar to the reciprocal patent clause that you will find in the Apache License except it is only given to compliant implementations (like the Java licenses), the only contributor in this case is Adobe, and it is only a patent license. The copyright license for the spec is very restrictive, but that would not impact your implementation unless you wanted to include the spec itself. (A protocol is entirely operative by nature and hence not itself copyrightable, IIRC.)

        The spec document has the same patent license on the first three pages and then a long plain-text document in PDF that appears to have been formatted like an Internet RFC but not submitted as one (i.e., this is an ugly spec, but folks who are familiar with IETF protocols will find it natural aside from the fact it is copyright Adobe).

        I have no comment on the protocol quality – never tried implementing it myself.

        Show
        Roy T. Fielding added a comment - I am an Adobe employee, but I am not commenting from the perspective of Adobe and don't have the right to make any additional license on Adobe's behalf. However, I can read legalese. There is no harm in reading the license or the spec. The specification license is a conditional patent license that provides a license to implementations that are compliant with the spec for those claims that Adobe owns that are necessarily infringed by implementing the spec. The conditions that are not licensed are listed in the license, but loosely summarized as implementations that attempt to intercept or circumvent DRM-protected content. You cannot lose any rights that you already have by accessing or reading the spec, since the license only gives you permission to do some things that otherwise might be forbidden due to Adobe's patents (I do not know which ones, nor do I know when they might expire, but in any case you won't need the license at all if no valid patents remain or if you don't happen to implement the spec). In other words, this is similar to the reciprocal patent clause that you will find in the Apache License except it is only given to compliant implementations (like the Java licenses), the only contributor in this case is Adobe, and it is only a patent license. The copyright license for the spec is very restrictive, but that would not impact your implementation unless you wanted to include the spec itself. (A protocol is entirely operative by nature and hence not itself copyrightable, IIRC.) The spec document has the same patent license on the first three pages and then a long plain-text document in PDF that appears to have been formatted like an Internet RFC but not submitted as one (i.e., this is an ugly spec, but folks who are familiar with IETF protocols will find it natural aside from the fact it is copyright Adobe). I have no comment on the protocol quality – never tried implementing it myself.
        Hide
        Lawrence Rosen added a comment -

        I agree generally with Roy's comments. Here is Adobe's own plain language interpretation of their specification license:

        "The RTMP specification document (above) and license cover the RTMP protocol only. They do not include information or license around any other Flash Media Server technology. By downloading the RTMP specification, you are agreeing to the RTMP license. To benefit customers who want to protect their content, the open RTMP specification does not include Adobe's unique secure RTMP measures, nor does the license that accompanies the specification allow developers to circumvent such measures. However, developers will be free to use their own technological measures to secure content. The RTMP specification does not provide any requirement or restrictions on a developer's own measures to secure content."
        http://www.adobe.com/devnet/rtmp.html

        The "Prohibited Uses" (i.e., circumvention of DRM) are not uses in which ASF itself will ever participate, but we obviously cannot vouch for downstream users. We should probably include something about this in the NOTICE file.

        My only concerns about this specification license are its precise definitions of "Essential Claim" and "Compliant Implementation" which are not as broad as we tried to make their equivalents in the Open Web Foundation Agreement. But they are typical of such patent grants from commercial companies.

        /Larry

        Show
        Lawrence Rosen added a comment - I agree generally with Roy's comments. Here is Adobe's own plain language interpretation of their specification license: "The RTMP specification document (above) and license cover the RTMP protocol only. They do not include information or license around any other Flash Media Server technology. By downloading the RTMP specification, you are agreeing to the RTMP license. To benefit customers who want to protect their content, the open RTMP specification does not include Adobe's unique secure RTMP measures, nor does the license that accompanies the specification allow developers to circumvent such measures. However, developers will be free to use their own technological measures to secure content. The RTMP specification does not provide any requirement or restrictions on a developer's own measures to secure content." http://www.adobe.com/devnet/rtmp.html The "Prohibited Uses" (i.e., circumvention of DRM) are not uses in which ASF itself will ever participate, but we obviously cannot vouch for downstream users. We should probably include something about this in the NOTICE file. My only concerns about this specification license are its precise definitions of "Essential Claim" and "Compliant Implementation" which are not as broad as we tried to make their equivalents in the Open Web Foundation Agreement. But they are typical of such patent grants from commercial companies. /Larry
        Hide
        Sam Ruby added a comment -

        Re: "The "Prohibited Uses" (i.e., circumvention of DRM) are not uses in which ASF itself will ever participate, but we obviously cannot vouch for downstream users. We should probably include something about this in the NOTICE file."

        I disagree with this.

        Short version is that while Adobe can believe anything they want, if we believe that there effectively are Field of Use restrictions, then the software is not Open Source. If we do not believe that there are Field of Use restrictions, then we should not effectively endorse Adobe's point of view by including a NOTICE.

        Long version can be found in the (unapproved) Special Order 5A in the following minutes:

        http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_07_21.txt

        Show
        Sam Ruby added a comment - Re: "The "Prohibited Uses" (i.e., circumvention of DRM) are not uses in which ASF itself will ever participate, but we obviously cannot vouch for downstream users. We should probably include something about this in the NOTICE file." I disagree with this. Short version is that while Adobe can believe anything they want, if we believe that there effectively are Field of Use restrictions, then the software is not Open Source. If we do not believe that there are Field of Use restrictions, then we should not effectively endorse Adobe's point of view by including a NOTICE. Long version can be found in the (unapproved) Special Order 5A in the following minutes: http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_07_21.txt
        Hide
        Lawrence Rosen added a comment -

        The Prohibited Uses identified in this specification license are things that would (I believe) be illegal anyway in the US and most other countries. It is sort of like the clauses in some early open source licenses that prohibited export of the software contrary to US export law.

        I agree that the Adobe language is ugly. The notion that they say they will let us use their specification only if we avoid certain prohibited uses is repulsive to many in open source. But if I consider that what Adobe is trying to prevent is something my friends and I are never going to do anyway, I treat such provisions as noise.

        What's wrong with announcing this noise in a NOTICE in case someone downstream thinks they are getting a patent license to do certain illegal things?

        /Larry

        Show
        Lawrence Rosen added a comment - The Prohibited Uses identified in this specification license are things that would (I believe) be illegal anyway in the US and most other countries. It is sort of like the clauses in some early open source licenses that prohibited export of the software contrary to US export law. I agree that the Adobe language is ugly. The notion that they say they will let us use their specification only if we avoid certain prohibited uses is repulsive to many in open source. But if I consider that what Adobe is trying to prevent is something my friends and I are never going to do anyway, I treat such provisions as noise. What's wrong with announcing this noise in a NOTICE in case someone downstream thinks they are getting a patent license to do certain illegal things? /Larry
        Hide
        Sam Ruby added a comment -

        Re: "What's wrong with announcing this noise in a NOTICE in case someone downstream thinks they are getting a patent license to do certain illegal things?"

        As indicated, we discussed similar NOTICE requirements in the past, and while we didn't get to the point where we agreed to specific wording on a resolution, there was substantial opposition to such NOTICES. The reason we didn't see this through to conclusion is that it became moot as we (specifically Geir in this case) resolved the issue (with Sun, re: Geronimo) so that all parties agreed that a NOTICE was not necessary. If somebody here believes that this is an issue worth working, I encourage them to follow Geir's lead.

        Meanwhile, unless we know of a specific patent, can identify a specific licensee who is legitimately confused, can positively identify some action that we have taken that contributes to that confusion, and can identify specific NOTICE text that addresses that confusion, I remain opposed to adding text to a NOTICE file that effectively would state that there might be patents that might be valid, enforceable, and have not expired that effectively would make the code that we provide to not be Open Source depending on the jurisdiction that you are in.

        Show
        Sam Ruby added a comment - Re: "What's wrong with announcing this noise in a NOTICE in case someone downstream thinks they are getting a patent license to do certain illegal things?" As indicated, we discussed similar NOTICE requirements in the past, and while we didn't get to the point where we agreed to specific wording on a resolution, there was substantial opposition to such NOTICES. The reason we didn't see this through to conclusion is that it became moot as we (specifically Geir in this case) resolved the issue (with Sun, re: Geronimo) so that all parties agreed that a NOTICE was not necessary. If somebody here believes that this is an issue worth working, I encourage them to follow Geir's lead. Meanwhile, unless we know of a specific patent, can identify a specific licensee who is legitimately confused, can positively identify some action that we have taken that contributes to that confusion, and can identify specific NOTICE text that addresses that confusion, I remain opposed to adding text to a NOTICE file that effectively would state that there might be patents that might be valid, enforceable, and have not expired that effectively would make the code that we provide to not be Open Source depending on the jurisdiction that you are in.
        Hide
        Lawrence Rosen added a comment -

        Sam Ruby wrote:
        > Meanwhile, unless we know of a specific patent, can identify a specific licensee
        > who is legitimately confused, can positively identify some action that we have taken
        > that contributes to that confusion, and can identify specific NOTICE text that addresses
        > that confusion, I remain opposed to adding text to a NOTICE file that effectively would
        > state that there might be patents that might be valid, enforceable, and have not expired
        > that effectively would make the code that we provide to not be Open Source depending
        > on the jurisdiction that you are in.

        Then which alternative are you suggesting?

        1. Implement the Adobe specification without providing any NOTICE to downstream users of a potential patent claim, based on our own lack of "legitimate" confusion.

        2. Don't implement the Adobe specification at all, thus denying ourselves whatever value there may be in that technology.

        /Larry

        Show
        Lawrence Rosen added a comment - Sam Ruby wrote: > Meanwhile, unless we know of a specific patent, can identify a specific licensee > who is legitimately confused, can positively identify some action that we have taken > that contributes to that confusion, and can identify specific NOTICE text that addresses > that confusion, I remain opposed to adding text to a NOTICE file that effectively would > state that there might be patents that might be valid, enforceable, and have not expired > that effectively would make the code that we provide to not be Open Source depending > on the jurisdiction that you are in. Then which alternative are you suggesting? 1. Implement the Adobe specification without providing any NOTICE to downstream users of a potential patent claim, based on our own lack of "legitimate" confusion. 2. Don't implement the Adobe specification at all, thus denying ourselves whatever value there may be in that technology. /Larry
        Hide
        Roy T. Fielding added a comment -

        I think we should answer the question that was asked, not a myriad of potential follow-on questions.

        The answer is that there is no harm in reading the spec or the license. Implementing the spec might run afoul of any number of potential patents, some subset of which might be owned by Adobe and thus fall into the licensed category. Regardless, the presence of that license does not change the open source nature of the resulting code, in any way whatsoever, since the constraints are inherent in the patents that may or may not exist regardless of the license.

        The existence of a patent claim DOES NOT make software less open source. Enforcing that claim might, depending on what license is required when it is enforced. AFAIK, Adobe has not requested any addition to NOTICE so long as the spec itself is not included in any redistribution. Furthermore, unlike the JSR cases that we have talked about in the past, this patent license to implement the protocol has no complex web of copyright/contract restrictions like the JSPA and thus does not impact our Apache License.

        In other words, this is no different than reading the HTTP spec and implementing HTTP.

        Show
        Roy T. Fielding added a comment - I think we should answer the question that was asked, not a myriad of potential follow-on questions. The answer is that there is no harm in reading the spec or the license. Implementing the spec might run afoul of any number of potential patents, some subset of which might be owned by Adobe and thus fall into the licensed category. Regardless, the presence of that license does not change the open source nature of the resulting code, in any way whatsoever, since the constraints are inherent in the patents that may or may not exist regardless of the license. The existence of a patent claim DOES NOT make software less open source. Enforcing that claim might, depending on what license is required when it is enforced. AFAIK, Adobe has not requested any addition to NOTICE so long as the spec itself is not included in any redistribution. Furthermore, unlike the JSR cases that we have talked about in the past, this patent license to implement the protocol has no complex web of copyright/contract restrictions like the JSPA and thus does not impact our Apache License. In other words, this is no different than reading the HTTP spec and implementing HTTP.
        Hide
        Robert Burrell Donkin added a comment -

        IMO The NOTICE would be the wrong place for dealing with patent claims: downstream consumers would be forced to retain the text, whether applicable to them or not.

        IMO For claims enforced by court, for which a reasonable license exists, the natural location for this license would be in the LICENSE document. This would leave downstream consumers free to remove the license if they wished.

        It might be convenient for downstream users to receive friendly (public, no-cost, RAND, say) patent licenses that Apache is aware of, even where claims has not been proved in court. This would need an appropriate disclaimer. Perhaps following the example of the CRYPTO read me, we could facilitate projects shipping a PATENTS read me by agreeing standard working for the disclaimer.

        Show
        Robert Burrell Donkin added a comment - IMO The NOTICE would be the wrong place for dealing with patent claims: downstream consumers would be forced to retain the text, whether applicable to them or not. IMO For claims enforced by court, for which a reasonable license exists, the natural location for this license would be in the LICENSE document. This would leave downstream consumers free to remove the license if they wished. It might be convenient for downstream users to receive friendly (public, no-cost, RAND, say) patent licenses that Apache is aware of, even where claims has not been proved in court. This would need an appropriate disclaimer. Perhaps following the example of the CRYPTO read me, we could facilitate projects shipping a PATENTS read me by agreeing standard working for the disclaimer.
        Hide
        Robert Burrell Donkin added a comment -

        @roy +1 (non-binding)

        Show
        Robert Burrell Donkin added a comment - @roy +1 (non-binding)
        Hide
        Sam Ruby added a comment -

        I'll attempt to summarize my understanding of the consensus so far.

        • There is no harm in reading the RTMP specification or the license thereof.
        • The RTMP specification license is effectively a conditional patent license. Such licenses may only benefit us and our downstream users.
        • At the current time, we no of no enforced claims of patents that read on any RTMP plugin for JMeter that we might develop.

        The situation would clearly change if we became aware of plans to enforce valid and unexpired patents that read on the plugin and furthermore are patents that we find are not licensed to us for any reason (including, but not limited to, us not meeting the conditions specified in the RTMP specification license).

        Show
        Sam Ruby added a comment - I'll attempt to summarize my understanding of the consensus so far. There is no harm in reading the RTMP specification or the license thereof. The RTMP specification license is effectively a conditional patent license. Such licenses may only benefit us and our downstream users. At the current time, we no of no enforced claims of patents that read on any RTMP plugin for JMeter that we might develop. The situation would clearly change if we became aware of plans to enforce valid and unexpired patents that read on the plugin and furthermore are patents that we find are not licensed to us for any reason (including, but not limited to, us not meeting the conditions specified in the RTMP specification license).
        Hide
        Sebb added a comment -

        Just to be perfectly clear, can I take it that:

        1) The JMeter project can implement a RTMP plugin based on the specification;

        and

        2) There is no requirement for the JMeter project to add anything to the NOTICE file;

        OK?

        What about the LICENSE file? Does anything need to be added to that? It would seem odd to me to add the spec license, as JMeter would not be providing the spec, but an implementation of the spec.

        Show
        Sebb added a comment - Just to be perfectly clear, can I take it that: 1) The JMeter project can implement a RTMP plugin based on the specification; and 2) There is no requirement for the JMeter project to add anything to the NOTICE file; OK? What about the LICENSE file? Does anything need to be added to that? It would seem odd to me to add the spec license, as JMeter would not be providing the spec, but an implementation of the spec.
        Hide
        Robert Burrell Donkin added a comment -

        @sam

        "At the current time, we no of no enforced claims of patents that read on any RTMP plugin for JMeter that we might develop." -> "At the current time, we know of no enforced claims of patents that read on any RTMP plugin for JMeter that we might develop."

        Otherwise +1

        Show
        Robert Burrell Donkin added a comment - @sam "At the current time, we no of no enforced claims of patents that read on any RTMP plugin for JMeter that we might develop." -> "At the current time, we know of no enforced claims of patents that read on any RTMP plugin for JMeter that we might develop." Otherwise +1
        Hide
        Robert Burrell Donkin added a comment -

        @sebb

        AIUI
        1. Yes
        2. No

        Show
        Robert Burrell Donkin added a comment - @sebb AIUI 1. Yes 2. No
        Hide
        Robert Burrell Donkin added a comment -

        @sebb

        If JMeter would like to pass on the conditional patent license kindly supplied by Adobe, don't use NOTICE or LICENSE. My suggestion would be in a PATENTS.txt but please open a new policy JIRA and ping the legal affairs team.

        Show
        Robert Burrell Donkin added a comment - @sebb If JMeter would like to pass on the conditional patent license kindly supplied by Adobe, don't use NOTICE or LICENSE. My suggestion would be in a PATENTS.txt but please open a new policy JIRA and ping the legal affairs team.
        Hide
        Sebb added a comment -

        @robert 17/Jan/12 20:29

        You wrote: "2. No" which I find ambiguous. Please advise?

        Does it mean:

        No, statement 2 is wrong

        or

        No, there is no requirement, i.e. statement 2 is correct.

        Show
        Sebb added a comment - @robert 17/Jan/12 20:29 You wrote: "2. No" which I find ambiguous. Please advise? Does it mean: No, statement 2 is wrong or No, there is no requirement, i.e. statement 2 is correct.
        Hide
        Robert Burrell Donkin added a comment -

        @sebb I see what you mean

        1) Yes, the JMeter project can implement a RTMP plugin based on the specification.
        2) No, there is no requirement for the JMeter project to add anything to the NOTICE file.

        Show
        Robert Burrell Donkin added a comment - @sebb I see what you mean 1) Yes, the JMeter project can implement a RTMP plugin based on the specification. 2) No, there is no requirement for the JMeter project to add anything to the NOTICE file.
        Hide
        Paul Gregoire added a comment -

        Obviously we over on the Red5 team reverse engineered the protocol initially, but once the spec came out we wanted to see if we had missed anything important. Initially I was apprehensive towards reading the spec because of the warnings, so I contacted a lawyer and this is his response:

        The license to the RTMP protocol allows you to use it to make software
        that defines, creates or processes data compliant with the requirements
        expressly stated in the RTMP Specification. Thus, it only allows you to
        use the RTMP specification for streaming video, audio and/or data
        content and not to make any software that: intercepts streaming
        video, audio and/or data content for storage in any device or medium; or
        (ii) circumvents technological measures for the protection of audio,
        video and/or data content. Thus, if the purpose of your reverse
        engineering is only to write software that streams video, audio and/or
        data content and not for the excluded purposes, then you are complying
        with the license.

        Warm regards,
        --Dan

        Daniel B. Ravicher, Legal Director
        Software Freedom Law Center (SFLC) and Moglen Ravicher LLC
        1995 Broadway, 17th Fl., New York, NY 10023
        (212) 461-1902 direct (212) 580-0800 main (212) 580-0898 fax
        ravicher@softwarefreedom.org www.softwarefreedom.org

        Show
        Paul Gregoire added a comment - Obviously we over on the Red5 team reverse engineered the protocol initially, but once the spec came out we wanted to see if we had missed anything important. Initially I was apprehensive towards reading the spec because of the warnings, so I contacted a lawyer and this is his response: The license to the RTMP protocol allows you to use it to make software that defines, creates or processes data compliant with the requirements expressly stated in the RTMP Specification. Thus, it only allows you to use the RTMP specification for streaming video, audio and/or data content and not to make any software that: intercepts streaming video, audio and/or data content for storage in any device or medium; or (ii) circumvents technological measures for the protection of audio, video and/or data content. Thus, if the purpose of your reverse engineering is only to write software that streams video, audio and/or data content and not for the excluded purposes, then you are complying with the license. Warm regards, --Dan Daniel B. Ravicher, Legal Director Software Freedom Law Center (SFLC) and Moglen Ravicher LLC 1995 Broadway, 17th Fl., New York, NY 10023 (212) 461-1902 direct (212) 580-0800 main (212) 580-0898 fax ravicher@softwarefreedom.org www.softwarefreedom.org
        Hide
        Lawrence Rosen added a comment -

        Dan Ravicher's analysis of the relevant patent portion of the Adobe RTMP license is accurate and helpful. I believe it is also now public information, because of how we archive our Jira questions and answers. Therefore, without treating Dan's comment as confidential legal advice, and with an appropriate disclaimer, I again recommend that we include something like that in our NOTICE file. It won't hurt anyone and it might help someone downstream to avoid infringing on possible "necessary claims" owned by Adobe.

        /Larry

        Show
        Lawrence Rosen added a comment - Dan Ravicher's analysis of the relevant patent portion of the Adobe RTMP license is accurate and helpful. I believe it is also now public information, because of how we archive our Jira questions and answers. Therefore, without treating Dan's comment as confidential legal advice, and with an appropriate disclaimer, I again recommend that we include something like that in our NOTICE file. It won't hurt anyone and it might help someone downstream to avoid infringing on possible "necessary claims" owned by Adobe. /Larry
        Hide
        Sebb added a comment -

        The JMeter RTMP plugin would almost certainly not be a streaming implementation, and would likely be able to store the the content.

        So that seems like the JMeter plugin would not be covered by the licence after all.

        Show
        Sebb added a comment - The JMeter RTMP plugin would almost certainly not be a streaming implementation, and would likely be able to store the the content. So that seems like the JMeter plugin would not be covered by the licence after all.
        Hide
        Sam Ruby added a comment -

        I continue to oppose any NOTICE requirement.

        Do we have reason to believe that there are "necessary claims" that either the ASF or our licensees will need to license depending on how this protocol is used?

        The RTMP license may grant us and our licensees permission that we don't need. There's no harm in that.

        If, however, this amounts to a Field of Use restriction, then this restriction is incompatible with Open Source, and our products should not ship code that implements this specification.

        Show
        Sam Ruby added a comment - I continue to oppose any NOTICE requirement. Do we have reason to believe that there are "necessary claims" that either the ASF or our licensees will need to license depending on how this protocol is used? The RTMP license may grant us and our licensees permission that we don't need. There's no harm in that. If, however, this amounts to a Field of Use restriction, then this restriction is incompatible with Open Source, and our products should not ship code that implements this specification.
        Hide
        Lawrence Rosen added a comment -

        Sam Ruby wrote:
        > If, however, this amounts to a Field of Use restriction, then this restriction is incompatible
        > with Open Source, and our products should not ship code that implements this specification.

        FYI, Mozilla Foundation has reached a new understanding about this:

        http://news.cnet.com/8301-30685_3-57397031-264/mozilla-execs-capitulate-in-h.264-web-video-war/

        This Jira issue does not propose anything near that drastic a change in philosophy by Apache, and please let's not broaden this Jira to discuss Mozilla's change of heart. (Start a new thread on that if you want to.) However, this Jira LEGAL-120 issue is at least a recognition of the possible effects of patents on our customers. By posting a NOTICE similar to what Dan Ravicher wrote, we allow downstream users of our software to make up their own minds with more information rather than less.

        To re-quote Sam, "There's no harm in that."

        /Larry

        Show
        Lawrence Rosen added a comment - Sam Ruby wrote: > If, however, this amounts to a Field of Use restriction, then this restriction is incompatible > with Open Source, and our products should not ship code that implements this specification. FYI, Mozilla Foundation has reached a new understanding about this: http://news.cnet.com/8301-30685_3-57397031-264/mozilla-execs-capitulate-in-h.264-web-video-war/ This Jira issue does not propose anything near that drastic a change in philosophy by Apache, and please let's not broaden this Jira to discuss Mozilla's change of heart. (Start a new thread on that if you want to.) However, this Jira LEGAL-120 issue is at least a recognition of the possible effects of patents on our customers. By posting a NOTICE similar to what Dan Ravicher wrote, we allow downstream users of our software to make up their own minds with more information rather than less. To re-quote Sam, "There's no harm in that." /Larry
        Hide
        Sam Ruby added a comment -

        We can certainly agree that this issue has nothing to do with H.264 or Mozilla.

        Per Sebb's comment above, we have been presented with a license that gives us access to unspecified IP under conditions that we, ourselves, don't meet.

        Show
        Sam Ruby added a comment - We can certainly agree that this issue has nothing to do with H.264 or Mozilla. Per Sebb's comment above, we have been presented with a license that gives us access to unspecified IP under conditions that we, ourselves, don't meet.
        Hide
        Lawrence Rosen added a comment -

        Sam Ruby wrote:
        > Per Sebb's comment above, we have been presented with a license that gives us
        > access to unspecified IP under conditions that we, ourselves, don't meet.

        I don't understand what conditions we don't meet. Are you interpreting the license correctly in light of the technology we're implementing? As Dan Ravicher wrote: "Thus, if the purpose of your reverse engineering is only to write software that streams video, audio and/or data content and not for the excluded purposes, then you are complying
        with the license." Our Apache software is not intercepting data streams for subsequent storage or circumventing technological measures for the protection of content, is it?

        /Larry

        Show
        Lawrence Rosen added a comment - Sam Ruby wrote: > Per Sebb's comment above, we have been presented with a license that gives us > access to unspecified IP under conditions that we, ourselves, don't meet. I don't understand what conditions we don't meet. Are you interpreting the license correctly in light of the technology we're implementing? As Dan Ravicher wrote: "Thus, if the purpose of your reverse engineering is only to write software that streams video, audio and/or data content and not for the excluded purposes, then you are complying with the license." Our Apache software is not intercepting data streams for subsequent storage or circumventing technological measures for the protection of content, is it? /Larry

          People

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

            Dates

            • Created:
              Updated:

              Development