If I'm understanding this correctly, the chief change is that now a Rackspace employee who wishes to contribute to OSS during work hours only needs their manager's approval, as opposed to having to go all the way to legal?
This could be worded more clearly to indicate what about this is new; I can't think of an alternate interpretation that doesn't suggest Rackspace previously forbid employees from contributing to OSS on their own time, which I assume (and surely hope) has never been the case.
Our default policy was (as is the case at most companies) that code written by our employees is copyright Rackspace. This is true just about universally - look on wikipedia about the "work for hire" doctrine.
Because employee code was technically the property of Rackspace, we had a policy that they needed to ask for permission before releasing it to the public under an open source license. But when we looked at our actual history, we saw that we were granting 100% of the requests.
This new policy grants pre-approval to all Rackers to contribute to open source projects under their own name, holding their own copyright. We even allow contributions that occur on Rackspace time using Rackspace resources, as long as their manager agrees that it is a good use of their at-work time.
Our default policy was (as is the case at most companies) that code written by our employees is copyright Rackspace. This is true just about universally - look on wikipedia about the "work for hire" doctrine.
Such a policy seems impossible to reconcile with the statutory requirements for a work to be a work for hire, which (when based on employment status rather than specific commission of the work in question) is specifically limited to works that are "prepared by an employee within the scope of his or her employment", 17 USC Sec. 101 (emphasis added).
The scope of employment has historically been interpreted very broadly, usually in terms of any present or possible future business opportunity. You will see how that leads to a broad right of assignment.
You may say, that is ridiculous! I can't believe such a thing! Well, I agree that it is ridiculous, but it is still generally true (modulo some exceptions applicable in a couple of states due to specific employment laws).
At Rackspace, we believe in doing the right thing. We already were doing the right thing, but only when asked. We changed our policy to instead do the right thing by default.
Only in the minds of Corporate lawyers is that true, the few cases that have gone all way to judgment often side with the employee unless the work product is directly related to their job function. Most of these cases also settle out of court long before they get to judgment because the soulless company bankrupts the former employee with bullshit legal costs
DDB is a patent cases, and, therefore therefore isn't interpreting the "work for hire" provision of copyright law -- the issue isn't whether an employment contract could transfer exclusive rights to the employer, but whether the employer was entitled to treat the work as a "work for hire" by policy (in copyright, there's a pretty important distinction between a transfer of exclusive rights by contract and a work being a "work for hire" where the original copyright is with the hiring party, this distinction does not exist in patent law); Medsphere wasn't an IP case at all, it was a case about breach of fiduciary duty by a corporate officer; and DSC/Alcatel involves a case where employee conduct at the time evidence that the employee thought that the work was within the scope of an inventions clause (including asking bosses for a waiver of the inventions clause), even though in court assertions were made (but, from what I can find, weakly supported) that would indicate the work was outside the scope. But, also, most of the reporting is around a "duty to disclose inventions" clause, and none indicates anything about work for hire in copyright -- its not at all clear from anything I can find on the case that it addresses scope of employment/work for hire issues, just scope of an enforceable contract clause which may effect a transfer of ownership.
DDB is specifically limited to patents not copyright which is what we are discussing here.
DSC Communications Corp. v. Evan Brown is more relevant, and highlights while I will never live in Texas.... But I should have also said that most of these employment contracts are governed by State law, not Federal law so the amount of bullshit the companies are allowed to get away with is highly varies from state to state. Texas is the worse when it comes to employee protections. DSC would have been laughed out of court here.
Medsphere v. Shreeve was settled out of court so has no bearing on this discussion.
I worked at Rackspace from 2007-2013 and have been acquainted with them for even longer. The notion of a "soulless company" bankrupting a former employee is ridiculous in the context of the Rackspace way of doing business. It goes against the Rackspace Core Values. Many Rackers have left the company to found companies of their own and I've never heard of any legal fight with any of these folks.
There aren't many 5,000+ employee companies with OSS policies this friendly.
I did not mean to imply they were a soulless company, I love rackspace, I am a (very small) customer of theirs never had anything less than a great experience.
However my experience with corporate legal at any company is the people therein have complete lack of humanity or decency. They have sold their souls for BMW and a 6-7 figure salary.
I should add that, whatever questions I have about the potential technical overreach (and it certainly isn't atypical, I agree) in the described terms of your original policy, I think that both how you appear to have applied it and, even more, how you are now treating the issue are both positive things in the industry
It sounds like what you're implying is that Rackspace's employment agreements assign all code written by an employee, regardless of when/where/why it was created, is owned by Rackspace.
This is not universally true. I have never and would never work under such terms. Only work done on company equipment or assigned or materially related to the business should be owned by the company.
To position otherwise is to significantly stifle employees ability to pursue projects outside of work (even if they are generally approved)
>> It sounds like what you're implying is that Rackspace's employment agreements assign all code written by an employee, regardless of when/where/why it was created, is owned by Rackspace. This is not universally true.
> That is the typical corporate America policy
I've worked for several massive companies, and none have insinuated that code written by an employee at home is owned by the company. If that's what you were referring to, then no, it's not typical corporate America policy. It does exist, but it's not typical.
This has been the default policy (inventions / work on your free time == the companies) at just about every job I've ever had in my career. They slip it into employment agreements as a method to ensure they can claim ownership over any "Intellectual Property and Inventions" you might make.
I've known several people (and OSS developers) who have been on the blunt end of this pretty nasty clause. They've been sued, or startups they started on the side sued by their now-ex company.
I've done the startup thing to the big company thing and somehow these clauses have always been there.
Disclosure: I work with Van @Rackspace - this updated policy is one step on a grand master open source plan :)
> This has been the default policy (inventions / work on your free time == the companies) at just about every job I've ever had in my career.
I second this. The companies I have worked in the past and current company (I think all come well within Fortune 50 list) all had exactly similar default policy. I too was surprised when I learnt that. But ALL of my past/current companies had a "discuss & establish exception" (via manager+legal coordinator if required) for my own work done (opensource or income-generating mobile app for eg:) during non work hours. The requirements were not very complex but they could be very broadly applicable since most of these big companies are in every field/domain of the software world. And the terms could be broadly summarized as "Thou shall not be given ownership of something that is going to be competetive or near-future business opportunity for the company" . Mostly your typical android/iphone app would get an easy approval. Opensource contributions (as long as non-competetive to existing company product) get easier-pass than income-generating (any thing involving money typically complicates things :) ) projects of the employee because the potential for conflict of interest is higher.
A lot of companies (like Rackspace or my current employer) are adopting opensource into the enterprise more and more and encouraging employees to contribute to opensource during work hours.
This is a great step by Rackspace, to be clear. All I'm saying is that it's mistaken to believe that most big companies will force you to sign an agreement stating that your code written on your own free time is theirs.
Actually, I was slightly mistaken originally. One time an employer tried to pull that, but when I pointed it out, they were willing to cross out the clause, because I was willing to walk away.
The catch here is you read the fine print. Many employees don't, and even if they do they miss assignment of invention clauses, non competes, etc. I too have asked to strike our the invention clauses - in one case they said ok, then backtracked and "lost" the struck through portion when I quit, the other refused "what are you hiding/planning".
It stinks that it's 2014 and invention clauses and non competes are basically default boilerplate, even in jurisdictions where they're unenforceable.
When I used to work for Motorola (pre-breakup), they had a clause in their standard contract (that you only saw on your first day orientation) that stated something along the lines of "Any idea, invention, or innovation conceived solely by employee or jointly with others, at any time during your duration of employment, that pertains to any current, future, or planned activities of the company, are owned by the company."
I'm sure I got a couple of words wrong in there, but I recall that at around the same time there was a large chunk of some open source project that had to be removed due to contributions by an employee of another company with similar wording. And when I asked about it with higher-ups, they basically said that even if you are working at home at midnight, on your own equipment, what you do may have been influenced by something like a hallway conversation with a co-worker.
My career has mostly been at banks and finance companies. It is indeed typical corporate american policy, at least for a certain size and type of corporation (and my personal sample).
Interestingly, as a development manager I have had candidates (hey Yousef!) balk at this condition and I just strike it out, initial, and submit to HR. No one ever checks this shit.
Comments
If I'm understanding this correctly, the chief change is that now a Rackspace employee who wishes to contribute to OSS during work hours only needs their manager's approval, as opposed to having to go all the way to legal?
This could be worded more clearly to indicate what about this is new; I can't think of an alternate interpretation that doesn't suggest Rackspace previously forbid employees from contributing to OSS on their own time, which I assume (and surely hope) has never been the case.
Our default policy was (as is the case at most companies) that code written by our employees is copyright Rackspace. This is true just about universally - look on wikipedia about the "work for hire" doctrine.
Because employee code was technically the property of Rackspace, we had a policy that they needed to ask for permission before releasing it to the public under an open source license. But when we looked at our actual history, we saw that we were granting 100% of the requests.
This new policy grants pre-approval to all Rackers to contribute to open source projects under their own name, holding their own copyright. We even allow contributions that occur on Rackspace time using Rackspace resources, as long as their manager agrees that it is a good use of their at-work time.
VanL (I wrote the policy)
Such a policy seems impossible to reconcile with the statutory requirements for a work to be a work for hire, which (when based on employment status rather than specific commission of the work in question) is specifically limited to works that are "prepared by an employee within the scope of his or her employment", 17 USC Sec. 101 (emphasis added).
Hi dragonwriter,
The scope of employment has historically been interpreted very broadly, usually in terms of any present or possible future business opportunity. You will see how that leads to a broad right of assignment.
You may say, that is ridiculous! I can't believe such a thing! Well, I agree that it is ridiculous, but it is still generally true (modulo some exceptions applicable in a couple of states due to specific employment laws).
At Rackspace, we believe in doing the right thing. We already were doing the right thing, but only when asked. We changed our policy to instead do the right thing by default.
Only in the minds of Corporate lawyers is that true, the few cases that have gone all way to judgment often side with the employee unless the work product is directly related to their job function. Most of these cases also settle out of court long before they get to judgment because the soulless company bankrupts the former employee with bullshit legal costs
This is not true. For example, take a look at DSC Communications Corp. v. Evan Brown, or DDB Tech v. MLB Advanced Media or Medsphere v. Shreeve.
In DSC, the court ruled that Alcatel owned the employee's thoughts that had not yet been committed to writing. (See http://www.theregister.co.uk/2002/08/12/alcatel_owns_us_empl...).
In DDB, the court found that Schlumberger (the oilfield services company) owned a baseball simulator written by an employee. (See http://www.finnegan.com/Publications/federalcircuit/FCCDetai...)
In Medsphere, the CTO of the company was sued for releasing the source code to their application as open source on Sourceforge. (See http://www.informationweek.com/medsphere-settles-lawsuit-wit...)
It may be only "corporate lawyers" who agree with the policies, but those lawyers tend to be very persuasive in front of judges.
DDB is a patent cases, and, therefore therefore isn't interpreting the "work for hire" provision of copyright law -- the issue isn't whether an employment contract could transfer exclusive rights to the employer, but whether the employer was entitled to treat the work as a "work for hire" by policy (in copyright, there's a pretty important distinction between a transfer of exclusive rights by contract and a work being a "work for hire" where the original copyright is with the hiring party, this distinction does not exist in patent law); Medsphere wasn't an IP case at all, it was a case about breach of fiduciary duty by a corporate officer; and DSC/Alcatel involves a case where employee conduct at the time evidence that the employee thought that the work was within the scope of an inventions clause (including asking bosses for a waiver of the inventions clause), even though in court assertions were made (but, from what I can find, weakly supported) that would indicate the work was outside the scope. But, also, most of the reporting is around a "duty to disclose inventions" clause, and none indicates anything about work for hire in copyright -- its not at all clear from anything I can find on the case that it addresses scope of employment/work for hire issues, just scope of an enforceable contract clause which may effect a transfer of ownership.
So none of these cases seem to be on point here.
DDB is specifically limited to patents not copyright which is what we are discussing here.
DSC Communications Corp. v. Evan Brown is more relevant, and highlights while I will never live in Texas.... But I should have also said that most of these employment contracts are governed by State law, not Federal law so the amount of bullshit the companies are allowed to get away with is highly varies from state to state. Texas is the worse when it comes to employee protections. DSC would have been laughed out of court here.
Medsphere v. Shreeve was settled out of court so has no bearing on this discussion.
I worked at Rackspace from 2007-2013 and have been acquainted with them for even longer. The notion of a "soulless company" bankrupting a former employee is ridiculous in the context of the Rackspace way of doing business. It goes against the Rackspace Core Values. Many Rackers have left the company to found companies of their own and I've never heard of any legal fight with any of these folks.
There aren't many 5,000+ employee companies with OSS policies this friendly.
I did not mean to imply they were a soulless company, I love rackspace, I am a (very small) customer of theirs never had anything less than a great experience.
However my experience with corporate legal at any company is the people therein have complete lack of humanity or decency. They have sold their souls for BMW and a 6-7 figure salary.
I should add that, whatever questions I have about the potential technical overreach (and it certainly isn't atypical, I agree) in the described terms of your original policy, I think that both how you appear to have applied it and, even more, how you are now treating the issue are both positive things in the industry
It sounds like what you're implying is that Rackspace's employment agreements assign all code written by an employee, regardless of when/where/why it was created, is owned by Rackspace.
This is not universally true. I have never and would never work under such terms. Only work done on company equipment or assigned or materially related to the business should be owned by the company.
To position otherwise is to significantly stifle employees ability to pursue projects outside of work (even if they are generally approved)
That is the typical corporate America policy, and yes it does stifle contribution.
We decided to be different and do better.
>> It sounds like what you're implying is that Rackspace's employment agreements assign all code written by an employee, regardless of when/where/why it was created, is owned by Rackspace. This is not universally true.
> That is the typical corporate America policy
I've worked for several massive companies, and none have insinuated that code written by an employee at home is owned by the company. If that's what you were referring to, then no, it's not typical corporate America policy. It does exist, but it's not typical.
This has been the default policy (inventions / work on your free time == the companies) at just about every job I've ever had in my career. They slip it into employment agreements as a method to ensure they can claim ownership over any "Intellectual Property and Inventions" you might make.
I've known several people (and OSS developers) who have been on the blunt end of this pretty nasty clause. They've been sued, or startups they started on the side sued by their now-ex company.
I've done the startup thing to the big company thing and somehow these clauses have always been there.
Disclosure: I work with Van @Rackspace - this updated policy is one step on a grand master open source plan :)
I second this. The companies I have worked in the past and current company (I think all come well within Fortune 50 list) all had exactly similar default policy. I too was surprised when I learnt that. But ALL of my past/current companies had a "discuss & establish exception" (via manager+legal coordinator if required) for my own work done (opensource or income-generating mobile app for eg:) during non work hours. The requirements were not very complex but they could be very broadly applicable since most of these big companies are in every field/domain of the software world. And the terms could be broadly summarized as "Thou shall not be given ownership of something that is going to be competetive or near-future business opportunity for the company" . Mostly your typical android/iphone app would get an easy approval. Opensource contributions (as long as non-competetive to existing company product) get easier-pass than income-generating (any thing involving money typically complicates things :) ) projects of the employee because the potential for conflict of interest is higher.
A lot of companies (like Rackspace or my current employer) are adopting opensource into the enterprise more and more and encouraging employees to contribute to opensource during work hours.
This is a great step by Rackspace, to be clear. All I'm saying is that it's mistaken to believe that most big companies will force you to sign an agreement stating that your code written on your own free time is theirs.
Actually, I was slightly mistaken originally. One time an employer tried to pull that, but when I pointed it out, they were willing to cross out the clause, because I was willing to walk away.
Perhaps I was just lucky three times in a row?
The catch here is you read the fine print. Many employees don't, and even if they do they miss assignment of invention clauses, non competes, etc. I too have asked to strike our the invention clauses - in one case they said ok, then backtracked and "lost" the struck through portion when I quit, the other refused "what are you hiding/planning".
It stinks that it's 2014 and invention clauses and non competes are basically default boilerplate, even in jurisdictions where they're unenforceable.
I thought that wasn't enforceable in California?
When I used to work for Motorola (pre-breakup), they had a clause in their standard contract (that you only saw on your first day orientation) that stated something along the lines of "Any idea, invention, or innovation conceived solely by employee or jointly with others, at any time during your duration of employment, that pertains to any current, future, or planned activities of the company, are owned by the company."
I'm sure I got a couple of words wrong in there, but I recall that at around the same time there was a large chunk of some open source project that had to be removed due to contributions by an employee of another company with similar wording. And when I asked about it with higher-ups, they basically said that even if you are working at home at midnight, on your own equipment, what you do may have been influenced by something like a hallway conversation with a co-worker.
My career has mostly been at banks and finance companies. It is indeed typical corporate american policy, at least for a certain size and type of corporation (and my personal sample).
Interestingly, as a development manager I have had candidates (hey Yousef!) balk at this condition and I just strike it out, initial, and submit to HR. No one ever checks this shit.
Are you changing your employment agreements to not take all those rights? It is possible to narrow which rights are assigned.