Is the main point that Rackspace has relaxed a restriction that required pre-approval for employees to contribute to OSS _on their own time_ but they still need approval to contribute while at work?
That's not it. Contributions on Rackspace time are also approved. We just need people to understand that the still will need to respect the priorities set by their managers. We don't want them to interpret this policy as allowing them to unilaterally deprioritize their assigned work in favor of hacking on $PROJECT_OF_CHOICE.
If your manager agrees that hacking on $PROJECT is a good idea, go for it.
This is almost precisely the opposite of what we are saying. We are disclaiming ownership of all OSS contributions, inside of work or out. We just want to make sure that while people are on the clock, they do make progress on the tasks assigned to them, rather than on $PROJECT.
> Now, there are a couple of nuances to this new policy:
> 1. Rackers are encouraged to contribute on their own time, and if they wish to contribute during work hours they must obtain approval from their manager.
> 2. If a Racker would like to contribute to a project that is directly competitive with Rackspace, we’d like to understand why before they contribute.
2 has got to mean
"If a Racker would like to contribute to a project that is directly competitive with Rackspace [during work hours], we’d like to understand why before they contribute."
otherwise, i don't think such a policy is even legal?
Every full-time employment agreements I've signed in my career as a software engineer has had some sort of clause to the effect that my employer owns any work I do, even if it's done with my own hardware on my own time, if it is demonstrably in direct competition with my employer's chief line of business. This seems completely in line with that.
(Whether that sort of clause is enforceable in court is another question. IANAL.)
Most companies at least try to sneak in a provision like but, but a couple of important points:
1. Whether it's valid or not may depend on prevailing state law that is in effect. Just because you sign a document saying "you own my brain 24x7" does not necessarily mean that it's the case.
2. These provisions are often negotiable. When I worked for Lulu.com, their IP Assignment paperwork was so onerous that they could have claimed to own a fantasy novel that I might write in my spare time. I refused to sign until they made an exception. It took a while, but we worked something out that was reasonable.
3. A lot of times companies hand you a big stack of paperwork to sign, but have no process to audit that it all got returned and signed. Other than tax and insurance related stuff, your best bet may be to put it in your desk drawer and forget about it until somebody asks. There's a good chance nobody ever will. I worked at a job 4.5 years once and never did sign any of the NDA / IP Assignment / etc. crap. It was still in my desk drawer the day I left, right where I put it the day they gave it to me. shrug
4. Always talk to an actual lawyer if you have serious concerns about this stuff. :-)
If you get pushback on trying to strike out one of these clauses, just tell them that you do volunteer charity work that sometimes involves computers -- and that the organizations you work with want to protect themselves from lawsuits. That way, if they balk, they come across as being anti-charity. And don't forget, organizations suchs as the FSF are registered non-profit charities.
> Always talk to an actual lawyer if you have serious concerns about this stuff. :-)
yeah, but lawyering-up isn't cheap either, so perhaps i can glean some general insight from hn :) :/ ?
but let's say you're working somewhere that uses some technology... like, i dunno, you're working at google or somewhere with a really broad scope and you want to make some sort of open-source contributions to or write something about one of the many things they've got a finger on like, well, pretty much anything from clojure to thermostats... how's it going to play out if you try to fork that apache-licensed project or sell a compendium of writings somewhere down the line?
i have worked at a multinational company before, but the scope of what they did was fairly limited in comparison to some of the larger companies, so i'd never heard of such -- apparently common -- agreements before. i'm guessing that most of companies wouldn't mind free-software-type contributions and these agreements amount to more of an nda than a, "we own all your programs while we're paying your salary," or is that naive?
What we are saying is that it is our policy that the work for hire doctrine (see http://en.wikipedia.org/wiki/Work_for_hire) does not apply to OSS contributions at Rackspace, and that we encourage all employees to become involved with a community.
If you work at a company bigger than 10-15 employees, check your employment agreement. Rackspace's stance on this is highly unusual (I think even unique) for a company its size.
I've removed sections from contracts I've signed that do just that. Always made me laugh. Somewhat unenforcable here in Australia, but I'd rather be sure and strike it out.
This type of policy is very frequently known as the Assignment Of Inventions or Invention Assignments. Sadly - they are very enforceable depending on the state you're in. For example, non-competes are still in force across the US, but in some places if they go to court they fall over.
IP clauses like this are slightly more enforceable - all the employer has to do is prove you were employed at the employer when you started a company/made some code/wrote a book. See also: http://theemplawyerologist.com/2013/01/17/works-for-hire-and...
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 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.
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.
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 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.
>> 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.
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.
Yep, I meant OSS usage at work. Some companies have a procurement process (those that hate their engineers), some use code scanning tools and some have more liberal policies.
Not many companies talk about their policies and since Rackspace doesn't do much distribution (most things run on the server), I'm curious how things are handled.
Rackspace, a company that is built on open source technologies, had a policy that required its employees to get permission from a lawyer before contributing back to any open source projects during their free time. And now one of their executives is patting himself on the back for relaxing this awful policy. Am I reading this correctly?
It is a matter of responsibility. Anyone, in any organization, has a responsibility to make sure that the organization's "assets," however defined, are properly handled. Agree or not, intellectual property is one of the assets, and we had a responsibility to make sure that we followed the proper procedures before it was handed out.
What we did today was make a statement that encouraging participation in various communities and allowing Rackers to develop their skills whenever and however they want is both better for everyone and more consistent with our values. As obvious as this may be to you, we needed to do this in the proper way so that we could satisfy our duties to our shareholders.
I challenge you to find a public company with a similar policy. I have been around a long time, and I've never found one.
Do you think Heroku requires its employees to get permission before hacking on OSS on the weekend? Facebook? Twitter? Even Amazon, which contributes relatively little, only asks that its employees use their private email addresses.
Don't get me wrong, I'm happy that you've decided to hold yourself above the lowest common denominator of tech companies. I just don't think you should be congratulating yourself publicly on HN for it.
In this industry, having a solid background in open source contributions is serious mark of credibility for any engineer. The rest of us are falling over ourselves to work with and encourage people that hack in their free time.
Are there any Rackspace engineers in the thread? Please tell me this is all legalese and nobody actually asks you to get your weekend pull requests approved by a legal department.
There's nothing wrong with being proud about promoting something that is beneficial to all of us. I'm not sure why you are trying to put your own feelings in this and be negative about it, but whatever. I'm glad they are continuing to push on transparency and trust. It's going to be critical in the coming years. I, for one, am glad they are making it a priority.
And to answer your question, VanL is both an engineer and an attorney. I'm not sure he'd label himself as an executive either, but I'll let him speak for himself on that topic - as he should be allowed.
"I challenge you to find a public company with a similar policy. I have been around a long time, and I've never found one.
"
Google's policy was, for years, identical to this :)
(It is only slightly more onerous now, in that we ask to see the first few patches you contribute, mainly the result of too high a rate of unreasonable judgement generating actual issues, which I chalk up to statistics and having a really large number of engineers now)
I stand corrected, then. I had thought that Google's policy allowed contributions, but not under the employee's own copyright. I thought there was an additional step to get that approved.
So only open source work doesn't need to go through a lawyer?
"You can claim a copyright, but only if you couldn't be successful enough to make money."
Sounds like a big "fuck you" to me. Other corporations just ignore side projects outside the problem domain of the business. By making this statement explicitly permitting open-source, it feels like the screws are setup for the moment someone wants to make money.
52 comments
[ 3.0 ms ] story [ 116 ms ] threadIf your manager agrees that hacking on $PROJECT is a good idea, go for it.
VanL (I wrote the policy)
> 1. Rackers are encouraged to contribute on their own time, and if they wish to contribute during work hours they must obtain approval from their manager.
> 2. If a Racker would like to contribute to a project that is directly competitive with Rackspace, we’d like to understand why before they contribute.
2 has got to mean
"If a Racker would like to contribute to a project that is directly competitive with Rackspace [during work hours], we’d like to understand why before they contribute."
otherwise, i don't think such a policy is even legal?
(Whether that sort of clause is enforceable in court is another question. IANAL.)
1. Whether it's valid or not may depend on prevailing state law that is in effect. Just because you sign a document saying "you own my brain 24x7" does not necessarily mean that it's the case.
2. These provisions are often negotiable. When I worked for Lulu.com, their IP Assignment paperwork was so onerous that they could have claimed to own a fantasy novel that I might write in my spare time. I refused to sign until they made an exception. It took a while, but we worked something out that was reasonable.
3. A lot of times companies hand you a big stack of paperwork to sign, but have no process to audit that it all got returned and signed. Other than tax and insurance related stuff, your best bet may be to put it in your desk drawer and forget about it until somebody asks. There's a good chance nobody ever will. I worked at a job 4.5 years once and never did sign any of the NDA / IP Assignment / etc. crap. It was still in my desk drawer the day I left, right where I put it the day they gave it to me. shrug
4. Always talk to an actual lawyer if you have serious concerns about this stuff. :-)
yeah, but lawyering-up isn't cheap either, so perhaps i can glean some general insight from hn :) :/ ?
but let's say you're working somewhere that uses some technology... like, i dunno, you're working at google or somewhere with a really broad scope and you want to make some sort of open-source contributions to or write something about one of the many things they've got a finger on like, well, pretty much anything from clojure to thermostats... how's it going to play out if you try to fork that apache-licensed project or sell a compendium of writings somewhere down the line?
i have worked at a multinational company before, but the scope of what they did was fairly limited in comparison to some of the larger companies, so i'd never heard of such -- apparently common -- agreements before. i'm guessing that most of companies wouldn't mind free-software-type contributions and these agreements amount to more of an nda than a, "we own all your programs while we're paying your salary," or is that naive?
If you work at a company bigger than 10-15 employees, check your employment agreement. Rackspace's stance on this is highly unusual (I think even unique) for a company its size.
IP clauses like this are slightly more enforceable - all the employer has to do is prove you were employed at the employer when you started a company/made some code/wrote a book. See also: http://theemplawyerologist.com/2013/01/17/works-for-hire-and...
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.
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).
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.
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.
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.
So none of these cases seem to be on point here.
There aren't many 5,000+ employee companies with OSS policies this friendly.
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.
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)
We decided to be different and do better.
> 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.
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 :)
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?
It stinks that it's 2014 and invention clauses and non competes are basically default boilerplate, even in jurisdictions where they're unenforceable.
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.
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.
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.
Not many companies talk about their policies and since Rackspace doesn't do much distribution (most things run on the server), I'm curious how things are handled.
What we did today was make a statement that encouraging participation in various communities and allowing Rackers to develop their skills whenever and however they want is both better for everyone and more consistent with our values. As obvious as this may be to you, we needed to do this in the proper way so that we could satisfy our duties to our shareholders.
I challenge you to find a public company with a similar policy. I have been around a long time, and I've never found one.
Don't get me wrong, I'm happy that you've decided to hold yourself above the lowest common denominator of tech companies. I just don't think you should be congratulating yourself publicly on HN for it.
In this industry, having a solid background in open source contributions is serious mark of credibility for any engineer. The rest of us are falling over ourselves to work with and encourage people that hack in their free time.
Are there any Rackspace engineers in the thread? Please tell me this is all legalese and nobody actually asks you to get your weekend pull requests approved by a legal department.
And to answer your question, VanL is both an engineer and an attorney. I'm not sure he'd label himself as an executive either, but I'll let him speak for himself on that topic - as he should be allowed.
Google's policy was, for years, identical to this :)
(It is only slightly more onerous now, in that we ask to see the first few patches you contribute, mainly the result of too high a rate of unreasonable judgement generating actual issues, which I chalk up to statistics and having a really large number of engineers now)
I stand corrected, then. I had thought that Google's policy allowed contributions, but not under the employee's own copyright. I thought there was an additional step to get that approved.
"You can claim a copyright, but only if you couldn't be successful enough to make money."
Sounds like a big "fuck you" to me. Other corporations just ignore side projects outside the problem domain of the business. By making this statement explicitly permitting open-source, it feels like the screws are setup for the moment someone wants to make money.