

Rackspace’s Policy On Contributing To Open Source - VanL
http://www.rackspace.com/blog/rackspaces-policy-on-contributing-to-open-source/

======
jbaudanza
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?

~~~
VanL
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.

~~~
jbaudanza
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.

~~~
kordless
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.

------
lazerwalker
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.

~~~
VanL
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)

~~~
dragonwriter
> 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).

~~~
VanL
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.

~~~
the_ancient
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

~~~
VanL
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...](http://www.theregister.co.uk/2002/08/12/alcatel_owns_us_employees_thoughts/)).

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...](http://www.finnegan.com/Publications/federalcircuit/FCCDetail.aspx?pub=2358bbf7-ef30-46e3-a7d0-3c5bb0d5fcb2))

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...](http://www.informationweek.com/medsphere-settles-lawsuit-with-former-
cto-over-open-source-code/d/d-id/1060683?))

It may be only "corporate lawyers" who agree with the policies, but those
lawyers tend to be very persuasive in front of judges.

~~~
dragonwriter
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.

------
mindcrime
This sounds like a pretty reasonable policy to me. Good job, @Rackspace! Now
let's get more companies to follow suit.

------
auvrw
> 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?

~~~
VanL
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](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.

~~~
protomyth
Does the employee agreement for Rackspace claim code ownership on code written
on employee's own time and equipment?

~~~
girvo
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.

------
brynary
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?

~~~
VanL
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.

VanL (I wrote the policy)

------
caniszczyk
Nice job. What are the inbound policies :)?

~~~
jnoller
You mean using OSS at work? Or something else? I can confirm we use a LOT of
OSS. Like OpenStack. :)

~~~
caniszczyk
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.

------
stefan_kendall
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.

