3 ms·

> For me, as an "experimentalist" (read, data-analyst), I also maintain job attractiveness by having sets of code that no one else has. I'm experienced in a var

> For me, as an "experimentalist" (read, data-analyst), I also maintain job attractiveness by having sets of code that no one else has. I'm experienced in a variety of pattern finding algorithms, and have even invented a few myself for very specific problems-- and within my little sphere, people know this about me, I'm the person people come to for certain things. > I spent years of my life perfecting these, learning about algorithms, learning the intricacies and quirks of the various datasets we use-- if someone wants to take my place in this community as "that guy" then I expect them to devote as much time as I have to learning these techniques inside out and then to do something better than me. > I have no desire to pass my code off to a masters student and let him naively plug some dataset into it-- firstly because no one should ever rely on a black box in this field, and secondly because these codes all need to be tweaked to account for the different instruments and data structures being used. > Perhaps if my contract didn't have a built in expiration I would be willing to care-bear-share my fractal search methods and spend my Thursday afternoons showing you how to Savitsky-Golay smoothing works, but as long as I'm out of a job next July, and you're the guy applying for my job, you can keep your filthy hands off my code. First, WOW. In can't imagine any sector (except indeed academia) where a "keep your filthy hands off my code" attitude like that is remotely acceptable. Second question is, whose code, exactly? In most lines of work, if you write code for an employer (university in this case, I suppose), the copyright for that code is implicitly given to the employer. In this particular case, it means they could, as well as should force you to open this code. It could very well be that your contract explicitly states different, it has to be clear about code though, it's not just implied together with writings, for instance. Imagine if you were to work for, say, a security analysis consultancy firm, and you write a lot of cool machine learning and analysis code to detect intrusions or leakage. Regardless of whether your contract expires, if you leave, you're not leaving with your code. And if you'd refuse to document it properly so that the next guy can't use it, expect the contract to expire prematurely. I can imagine that would seem frustrating and scary NOW, but only because they made it seem like yours was a proper approach for all those years you gave it. Of course it wasn't--and deep down inside you know this to be true--if only everything had been open from the start.

xyzzy123 14y ago
> First, WOW. In can't imagine any sector (except indeed academia) where a "keep your filthy hands off my code" attitude like that is remotely acceptable. Actually, keeping code "close to your chest" is pretty common in the security industry. You'll see fuzzer frameworks get released all the time, but fuzzers which find "real bugs worth money" tend to get hoarded. If you work for a consultancy and have private tools, you are not expected to hand those over to the company. They will appreciate it if you release some results with their name on it (as well as yours) every now and then though.
- tripzilch 14y ago
  I see your point. I was actually trying to think of a counterexample where "keep your hands off my code" would indeed be a valid attitude, and the first that came to mind was the security industry (because what you describe indeed makes sense). But then I remembered the way copyrights work under employment, making it a bit of a convoluted (countercounter) example, sorry about that. What you describe, however, is if someone already has developed these tools and then joins a security consultancy company. Wouldn't it be very different if one developed the tools while under employment of a certain company (and it was your job to develop such type of tools)? Cause that's the whole point of the way copyright works here, if you develop this tool on company time, I really doubt they'd let you walk away with that IP. Especially because they are worth that money. And even if you develop it in your own spare evenings, law is pretty specific that doesn't matter, for one reason that it's impossible to prove (and often quite unlikely) that you didn't use any company resources or knowledge to do so. There is a good possibility that university contracts have different rules about the IP you produce while doing research though.
  - xyzzy123 14y ago
    > Wouldn't it be very different if one developed the tools while under employment of a certain company Basically, yes, stuff done on company time is definitely theirs under 'work for hire'. Totally agree with you. A lot of projects are done as evening/weekend work which is on shaky legal ground - similar to bootstrapping a company while employed. If you have a side activity which is making money, it's simplest to stay quiet about it. Among the limited sample set of "people I know", it's considered extremely crass for a company to try to pull an undeserved IP grab. Such a company would find it really hard to get self-motivated people after pulling a move like that. Because everyone has side projects. Although some are diligent about getting "my stuff versus your stuff" spelled out in contract, it's often a "gentleman's agreement"... As an aside, I wanted to point out that it's really common for security companies (or simply, "groups") to keep internal tools and only release them to the public when they've wrung all the "juice" out of them - e.g. publicity value exceeds the value of the results. I think this model is not too far off what was described originally.

xyzzy123 14y ago

> First, WOW. In can't imagine any sector (except indeed academia) where a "keep your filthy hands off my code" attitude like that is remotely acceptable. Actually, keeping code "close to your chest" is pretty common in the security industry. You'll see fuzzer frameworks get released all the time, but fuzzers which find "real bugs worth money" tend to get hoarded. If you work for a consultancy and have private tools, you are not expected to hand those over to the company. They will appreciate it if you release some results with their name on it (as well as yours) every now and then though.

tripzilch 14y ago
I see your point. I was actually trying to think of a counterexample where "keep your hands off my code" would indeed be a valid attitude, and the first that came to mind was the security industry (because what you describe indeed makes sense). But then I remembered the way copyrights work under employment, making it a bit of a convoluted (countercounter) example, sorry about that. What you describe, however, is if someone already has developed these tools and then joins a security consultancy company. Wouldn't it be very different if one developed the tools while under employment of a certain company (and it was your job to develop such type of tools)? Cause that's the whole point of the way copyright works here, if you develop this tool on company time, I really doubt they'd let you walk away with that IP. Especially because they are worth that money. And even if you develop it in your own spare evenings, law is pretty specific that doesn't matter, for one reason that it's impossible to prove (and often quite unlikely) that you didn't use any company resources or knowledge to do so. There is a good possibility that university contracts have different rules about the IP you produce while doing research though.
- xyzzy123 14y ago
  > Wouldn't it be very different if one developed the tools while under employment of a certain company Basically, yes, stuff done on company time is definitely theirs under 'work for hire'. Totally agree with you. A lot of projects are done as evening/weekend work which is on shaky legal ground - similar to bootstrapping a company while employed. If you have a side activity which is making money, it's simplest to stay quiet about it. Among the limited sample set of "people I know", it's considered extremely crass for a company to try to pull an undeserved IP grab. Such a company would find it really hard to get self-motivated people after pulling a move like that. Because everyone has side projects. Although some are diligent about getting "my stuff versus your stuff" spelled out in contract, it's often a "gentleman's agreement"... As an aside, I wanted to point out that it's really common for security companies (or simply, "groups") to keep internal tools and only release them to the public when they've wrung all the "juice" out of them - e.g. publicity value exceeds the value of the results. I think this model is not too far off what was described originally.