3.2b: "exposes and/or discloses Header File Information", where  "'Header File 
Information' means any header files supplied in connection with the Software" 
-- yeah, exactly my question. Do they mean making a few calls to functions 
described in the SDK, or are they only talking about reproducing portions of 
the header files themselves? (The latter sees to be the literal meaning.)

Paragraph 4: "You agree not to disseminate or in any way disclose the Software 
(or any portion thereof)." Indeed, that's not what we want to do at all. The 
rest of the paragraph talks about treating their confidential information 
properly, but I'm not sure how anything freely downloadable from their public 
web site could be considered confidential. These very paragraphs are the ones 
that I thought were anachronistic and probably date from a time that the whole 
SDK was only supplied under NDA. 

Also interestingly in paragraph 4: "Your obligations under this section with 
respect to the Software and support communications shall not apply when You can 
document that such information was (i) in the public domain at or subsequent to 
the time it was communicated to You by RED through no fault of Yours." So... 
considering that it's all in plain view on their web site... where does that 
leave us?

Anyway, yes, we agree -- this is incomprehensible, by all accounts appears to 
date from a time when they had a much more restricted availability of the SDK 
files, and it really doesn't explain how it might apply to open source packages.

Help us, Red! Say yes, say no, I don't really care. But please put us out of 
our misery by saying *anything* clear and intelligible that unambiguously 
applies in this situation.



> On Jul 22, 2019, at 10:50 PM, Colin Doncaster <[email protected]> wrote:
> 
> Hi Larry, 
> 
> 3.2b and 4 at https://www.red.com/legal/red-r3d-sdk-license-agreement 
> <https://www.red.com/legal/red-r3d-sdk-license-agreement> feel fairly 
> restrictive.  Even if you don’t ship the SDK you’re still giving away header 
> information which I also interpret as making the contents of the API openly 
> available (see 1.5 as the definition of header files) and also violates the 
> confidential information. 
> 
> I agree - it likely hasn’t been updated since being freely available, my 
> apologies for digressing the thread. 
> 
> Colin
> 
> 
> 
>> On Jul 22, 2019, at 9:31 PM, Larry Gritz <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Colin, I'm looking at the R3D SDK license agreement right now, and I see no 
>> such thing. It says that you can't use their trademarks to market your 
>> products or imply that they endorse it, but that's totally ordinary and in 
>> fact is also stipulated by the BSD open source license. It wouldn't prevent 
>> a bland factual statement that you support the format.
>> 
>> The license is not all that awful, it's just ambiguous. The problem, as I 
>> see it, is that it says it covers "[using] the Software for the sole purpose 
>> of internally developing Developer Programs," and also that "'Developer 
>> Programs' means compiled code generated using the Software, or any part 
>> thereof, designed to function with RED Products." I'm just not sure what 
>> that means or how to interpret this in an open source context where we are 
>> only distributing source code, and none of it is their source code.
>> 
>> I suspect that the license itself dates from before the SDK was freely 
>> downloadable on the web. It's got language that is more appropriate to 
>> confidential information. Maybe the SDK itself used to be available only 
>> under NDA? And after they made it so that anybody can download and inspect 
>> it, they never updated the license?
>> 
>> Remember that the idea is that OIIO would not redistribute any part of the 
>> SDK at all, not one byte. That's quite different than shipping a binary 
>> product that would necessarily have parts of the SDK embedded in it. Is it 
>> "using" the software to have program source code text that makes calls to 
>> the R3D API? Or is it "using" the software only if you are the studio who 
>> builds OIIO in the presence of the installed R3D libraries or that runs the 
>> software that makes the calls (i.e., actually USING the software that Red 
>> makes)?
>> 
>> This should be a conceptually simple thing to clear up if I can find a human 
>> to talk to. I just need a clear yes or no to "is it ok for an open source 
>> program to make calls to their SDK, if no part of the SDK itself is 
>> distributed?"
>> 
>> Like I said, if anybody knows someone at Red, please put me in touch.
>> 
>>      -- lg
>> 
>> 
>>> On Jul 22, 2019, at 8:50 PM, Colin Doncaster <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> I realize that OIIO isn’t a part of the ASWF but I wonder if leveraging 
>>> connections amongst members might come in handy?   
>>> 
>>> Based on the license agreement, the way it reads is that even if OIIO did 
>>> support R3d files you’d wouldn’t be able to talk about it - it’s pretty 
>>> much fight club. 
>>> 
>>> 
>>>> On Jul 22, 2019, at 8:36 PM, Larry Gritz <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> Coincidentally, I was just looking into this a couple weeks ago.
>>>> 
>>>> You can download their SDK for free, and while you obviously can't 
>>>> redistribute it, ordinarily there would be no particular reason why you 
>>>> couldn't link against it if you built the software yourself (i.e., an 
>>>> optional dependency that would enable r3d support if the r3d SDK was found 
>>>> on the system and presumably properly licensed by the studio at the time 
>>>> that they built their in-house copy of OIIO).
>>>> 
>>>> But, reading their license, I found it ambiguously worded to the point of 
>>>> being incomprehensible. It was just not clear if they disallowed only 
>>>> distribution of their code (which would be expected) or if they were 
>>>> trying to disallow even *calling* its API (which would be very unusual). 
>>>> It seemed clear that it was OK to call it for in-house software, but the 
>>>> wording was such that it didn't spell out the rules for open source 
>>>> software. It's not a matter of trade secrets; like I said, anybody can 
>>>> download their SDK and headers from their site.
>>>> 
>>>> I wrote them a letter explaining the situation and asking for 
>>>> clarification, but never got a reply at all.
>>>> 
>>>> If anybody knows somebody there who could be put in touch with me, please 
>>>> let me know. I would think that in a reasonable world, they would 
>>>> recognize that OIIO support could only help their customers and would be 
>>>> of no particular help to their competitors. So I can't even fathom what 
>>>> the objection would be. But I won't do it if I can't get a clear word from 
>>>> them that it's not violating their license.
>>>> 
>>>>    -- lg
>>>> 
>>>> 
>>>>> On Jul 22, 2019, at 6:19 PM, Colin Doncaster <[email protected] 
>>>>> <mailto:[email protected]>> wrote:
>>>>> 
>>>>> If I recall R3D requires a specific license from Red to use and there 
>>>>> might be sticky specifics about integrating into open source libraries, 
>>>>> this could be the reason why libraw may have discontinued updates?
>>>>> 
>>>>>> On Jul 22, 2019, at 6:07 PM, Alex Hughes <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> 
>>>>>> Hey I was wondering if OIIO supports reading r3d files.
>>>>>> 
>>>>>> I was looking through the release notes for libraw and that states that 
>>>>>> it could read r3d files.
>>>>>> https://www.libraw.org/node/1299 <https://www.libraw.org/node/1299>
>>>>>> 
>>>>>> However, that was in 2011 and I would imagine things could have changed 
>>>>>> since then.
>>>>>> 
>>>>>> My oiiotool seems to seg fault when I try to read r3d files and I was 
>>>>>> wondering if ti was even supposed to support r3d or if my build was just 
>>>>>> broken in some way.
>>>>>> 
>>>>>> I know Red likes to sell their SDK, but I was sort of hoping that LibRaw 
>>>>>> had an implementation that we could rely on.
>>>>>> 
>>>>>> Thanks
>>>>>> -Alex
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> [email protected] <mailto:[email protected]>
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
>>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>>> 
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
>>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>>> 
>>>> --
>>>> Larry Gritz
>>>> [email protected] <mailto:[email protected]>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
>>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>>> 
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> [email protected] <mailto:[email protected]>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org 
>>> <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org>
>> 
>> --
>> Larry Gritz
>> [email protected] <mailto:[email protected]>
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Oiio-dev mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]




_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to