4 ms·

That's a shame. This serves as a reminder to us all to be very careful when signing employment contracts. We're fortunate enough to be in an industry with huge

by phpnode 14y ago

That's a shame. This serves as a reminder to us all to be very careful when signing employment contracts. We're fortunate enough to be in an industry with huge demand for talent at the moment, so in addition to salary / benefits, things like having the right to open source your work should be included in your negotiations. In my experience, most good companies are OK with it.

nevinera 14y ago
>This serves as a reminder to us all to be very careful when signing employment contracts. If he was a full-time employee in the US, a contract wouldn't be necessary for this to be an issue. All work done by an employee on company time or using company resources is 'work for hire' (a term often misused in the software contracting industry, where it rarely applies), and that IP belongs to the company. >In my experience, most good companies are OK with it. Most good companies are sometimes 'OK with it'. It depends on how much it will affect their competitive advantages in their field. My employer would probably sign off on open-sourcing a charting library, but not a graph layout library, for example - displaying complex data as graphs is near the core of our business. Certainly most companies will not grant you a blanket right to open source all of your work for them.
- porker 14y ago
  I'd like to know about your business - if only because I'm interested in working in this field. Can you share any info about your employer?
  - nevinera 14y ago
    Definitely! Emcien (from mCn - we deal with a lot of combinatoric problems) is focused on analysis of large-scale data by constructing and operating on relationship graphs of tokens within that data. We use Rails pretty heavily for presentation, though our apps have been leaning more and more on Backbone.js, and most of the core science is performed in some C code largely written by one of the founders, O.R. prof Roy Marsten. The business/marketing site is at emcien.com, and the (fairly new) engineering blog is at engineering.emcien.com. Management sadly isn't interested in long-term remote devs yet - we're in Atlanta, GA. It's a great environment though, in the sweet-spot between risky startup and heavy corporate work.
- phpnode 14y ago
  > If he was a full-time employee in the US, a contract wouldn't be necessary for this to be an issue. Right, but you can still address this when you're negotiating the terms of your employment. > Certainly most companies will not grant you a blanket right to open source all of your work for them agreed, but many companies will be ok with open sourcing individual components, especially if it's done so under their name. My point is this is another tool for you to use at negotiation time when they've reached a limit on price / other benefits.
  - nevinera 14y ago
    I agree that it's worth bringing up, though investigating yourself is likely more accurate (if they haven't released any open projects previously, I'd be hesitant to believe their newfound commitment to the cause). But it's not really something they can honestly negotiate with - they can't commit to releasing anything until they can see what it is, and how likely it is to help their competitors.
- jimmychu0807 14y ago
  My thought is aligning with the policy what nevinera mentioned. The company should have the right to say whether to open src certain project or not programmed by the staff during the work time. But the code written by the same staff during the off-hour should belonged to the same staff. I am running a startup in Hong Kong, and I am thinking of adopting this kind of policy.
- drone 14y ago
  > All work done by an employee on company time or using company resources is 'work for hire' (a term often misused in the software contracting industry, where it rarely applies), and that IP belongs to the company. Even if the company is friendly today, it's worth noting that one should -never- use company-owned resources or time (including laptops) for personal projects. You can get into a situation where the a claim could be made that since company resources were utilized, that real financial value was contributed by the company towards its creation, and some ownership could be claimed. Whether or not such a claim would eventually prevail in court is orthogonal to one's ability to fund the experience in discovery.

by phpnode 14y ago

nevinera 14y ago

>This serves as a reminder to us all to be very careful when signing employment contracts. If he was a full-time employee in the US, a contract wouldn't be necessary for this to be an issue. All work done by an employee on company time or using company resources is 'work for hire' (a term often misused in the software contracting industry, where it rarely applies), and that IP belongs to the company. >In my experience, most good companies are OK with it. Most good companies are sometimes 'OK with it'. It depends on how much it will affect their competitive advantages in their field. My employer would probably sign off on open-sourcing a charting library, but not a graph layout library, for example - displaying complex data as graphs is near the core of our business. Certainly most companies will not grant you a blanket right to open source all of your work for them.

porker 14y ago
I'd like to know about your business - if only because I'm interested in working in this field. Can you share any info about your employer?
- nevinera 14y ago
  Definitely! Emcien (from mCn - we deal with a lot of combinatoric problems) is focused on analysis of large-scale data by constructing and operating on relationship graphs of tokens within that data. We use Rails pretty heavily for presentation, though our apps have been leaning more and more on Backbone.js, and most of the core science is performed in some C code largely written by one of the founders, O.R. prof Roy Marsten. The business/marketing site is at emcien.com, and the (fairly new) engineering blog is at engineering.emcien.com. Management sadly isn't interested in long-term remote devs yet - we're in Atlanta, GA. It's a great environment though, in the sweet-spot between risky startup and heavy corporate work.
phpnode 14y ago
> If he was a full-time employee in the US, a contract wouldn't be necessary for this to be an issue. Right, but you can still address this when you're negotiating the terms of your employment. > Certainly most companies will not grant you a blanket right to open source all of your work for them agreed, but many companies will be ok with open sourcing individual components, especially if it's done so under their name. My point is this is another tool for you to use at negotiation time when they've reached a limit on price / other benefits.
- nevinera 14y ago
  I agree that it's worth bringing up, though investigating yourself is likely more accurate (if they haven't released any open projects previously, I'd be hesitant to believe their newfound commitment to the cause). But it's not really something they can honestly negotiate with - they can't commit to releasing anything until they can see what it is, and how likely it is to help their competitors.
jimmychu0807 14y ago
My thought is aligning with the policy what nevinera mentioned. The company should have the right to say whether to open src certain project or not programmed by the staff during the work time. But the code written by the same staff during the off-hour should belonged to the same staff. I am running a startup in Hong Kong, and I am thinking of adopting this kind of policy.
drone 14y ago
> All work done by an employee on company time or using company resources is 'work for hire' (a term often misused in the software contracting industry, where it rarely applies), and that IP belongs to the company. Even if the company is friendly today, it's worth noting that one should -never- use company-owned resources or time (including laptops) for personal projects. You can get into a situation where the a claim could be made that since company resources were utilized, that real financial value was contributed by the company towards its creation, and some ownership could be claimed. Whether or not such a claim would eventually prevail in court is orthogonal to one's ability to fund the experience in discovery.