I'm not a lawyer, this is not legal advice. But if you work full time for a tech or entertainment company, you probably (I would go so far as to say, almost certainly) have a contract or employee IP assignment that makes all your IP output owned by the company, even done on your own time, unless you are SURE you have it in writing or in your contract that this is not the case. This is why CLAs are vital.
> On Oct 21, 2020, at 10:30 PM, Anders Langlands <[email protected]> > wrote: > > Yeah I’m doing this on my own time but I should probably clear it with > upstairs anyway to be on the safe side. > > On Thu, 22 Oct 2020 at 18:18, Larry Gritz <[email protected] > <mailto:[email protected]>> wrote: > By the way, if anyone working on this project who will be sending nontrivial > amounts of code and is working for a company that might have claims on their > IP output (which is to say, almost any tech or entertainment company, unless > they have some special agreement in place), they'll need to send a CLA before > I can merge their code. > > (Anders, I already have a CLA on file from your company.) > > -- lg > > >> On Oct 21, 2020, at 9:25 PM, Anders Langlands <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks Larry. I'll have that PR for a first pass submitted in a few hours. >> The only one that's come up so far is the geterror() mechanism (returning a >> string, which means caching it with a thread_local in the C layer) but I'll >> write more about that later. >> >> Cheers, >> Anders >> >> On Thu, 22 Oct 2020 at 17:13, Larry Gritz <[email protected] >> <mailto:[email protected]>> wrote: >> I just want to make sure you know... >> >> If you see something in the APIs that is "too C++" in the sense that it is >> extremely reliant on very C++-specific idioms, not only in expression but >> also conceptually, and therefore difficult to map to C or the way any other >> language would see things, then by all means make suggestions or even add >> something new on the C++ API to make the C wrappers easier. Don't feel like >> the C++ API is 100% set in stone and a sacred item that can't be changed. >> Your design space can extend into the existing interfaces if there are ways >> to improve them. >> >> >>> On Oct 20, 2020, at 8:33 PM, Anders Langlands <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Sounds good Scott. Once I’ve sketched out something and we all agree on a >>> general approach let’s split the bindings into small chunks we can each >>> tackle and PR piece wise and do the same for the Rust crate? >>> >>> On Wed, 21 Oct 2020 at 14:49, Scott Wilson <[email protected] >>> <mailto:[email protected]>> wrote: >>> That works for me. I'll start contributing bindings once Anders sends in >>> the first PR. >>> >>> On Tue, Oct 20, 2020 at 5:39 PM Larry Gritz <[email protected] >>> <mailto:[email protected]>> wrote: >>>> On Oct 20, 2020, at 1:56 PM, Anders Langlands <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Ok so then what I think I’ll do is port the C part of my rust crate over >>>> to oiio proper, implementing just enough to add a simple round-trip test, >>>> is load an image, add an attribute to the header, write it out as an exr. >>>> Then I’ll make a PR so you can comment. Sound good? >>> >>> >>> Awesome. >>> >>> And I would recommend that we approach the C bindings piece by piece. I'm a >>> fan of breaking it up into many small PRs so they can each be reviewed >>> quickly, one class at a time. Start with the easy ones and along the way >>> I'm sure we'll hash out the design issues and have a consensus by the time >>> we get to the big hairy classes. If we try to do it all at once, we could >>> end up going down the wrong road and only discover when in the middle of >>> reviewing and integrating an enormous amount of code that we wished we had >>> made some different basic decision. >>> >>> -- lg >>> >> >> -- >> 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 > <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
