views:

111

answers:

4

I am a co-op at a company and I was tasked with patching Roumen Petrov's OpenSSH w/ x509 certificates patch (http://www.roumenpetrov.info/openssh/) to include one of the features in his wanted list: wildcards in Distinguished Names. On his site he says that he will gladly accept patches.

After finishing, I asked my manager to implore the higher-ups if it was possible to release the patch to the public. Unfortunately, nothing ever came from it, the higher-ups forgot about the request.

The OpenSSH & the w/ x509 patch code is under a BSD license, so we are no legal requirement to release our changes. However, as an avid user of open-source and finally able to contribute, I want to help Mr. Petrov in his efforts. There is also a benefit to my company: the patch goes upstream and we do not have to maintain it between upstream-patch-versions.

I am an employee of the company (not a contractor), and thus my work at work is property of the company, and so I cannot release it without their approval (not that I would think of it).

I am wondering if I reproduce my changes on my own time, without looking or referencing the code generated at work, whether I could then release that patch.

Note: I could not find a copy of my employment contract anywhere, so I'm going to try to get a copy of it, but until then I cannot answer any specific questions about it.

Note 2: I realize you people are not lawyers. (Who are you callin' "you people?"!)

+9  A: 

the higher-ups forgot about the request

I would probably send a request. Something along the lines of

Dear whoever is responsible We're using open source software xyz for free in our company. In the course of my current work I have added feature which is used by our company but would be beneficial to public and I would like to submit it to open source community for inclusion in xyz. The pros of doing this are here summarize benefits that you outlined above. Let me know who is the best person to approve this. The sooner it can be submitted the sooner we don't have to maintain it.

Then keep pushing and asking until you get the approval.

stefanB
+1 I like the maintenance argument.
mouviciel
It should not be difficult for the company to realize the benefit of the work to be release open source since they are already using the software for free and realizing all the benefits, plus they get more eyes on the new code which will help them to find any issues ... the author might always refuse the code as inadequate then you just keep it for yourself ...
stefanB
They might even add it to their portfolio and put it on top of their website "We have some experts working for us, we've even submitted new features to OpenSSH ... "
stefanB
I would put *much* more emphasis on the concrete benefits to the company itself (marketing and maintenance, both of which you mentioned), rather than benefits to the public at-large—in fact, don't even mention the latter, treat that as a happy side-effect.
Roger Pate
A: 

The tricky thing is it might be hard to prove the new work wasn't based on the work you did for your company; what an old teacher of mine called the "love boat defense" ("watch the love boat before doing your own work; anything that you write after watching such mind-draining pap is yours") won't work here. Even if the implementation is completely different but there are similarities in design, it could be considered a derivative work. If you could think of a completely new and unrelated design, you could mount a good defense in case it came to court, but it wouldn't prevent it from going to court (which is the real goal).

Of course, if your company brought you to court, they'd lose a valuable employee, so they might be hesitant to do so. Still, stefanB's advice is the safest route and keeps you on good terms with your employer.

outis
+1  A: 

First, you're right: people here probably aren't lawyers, and those that claim to be may be difficult to confirm. It's very unsafe to trust any legal advice from Stack Overflow.

You should find yourself a lawyer who understands IP law and contract law (At the very least). You'll need the lawyer to look at your employment contract (everything you signed, pre and post hiring) to determine if you've entered into an enforceable non-compete agreement.

This stuff is pretty serious. I can't find the reference, but I've read of companies employing multiple teams who were mostly forbidden to communicate, and completely forbidden to read each others' code, in order to avoid tainting the company's proprietary software with software for which the company did not own the copyright.

atk
+1  A: 

You must be careful. I'm not sure how draconian the labor laws are in Indiana, but in Massachusetts, you'd be out of luck. The problem is that you have seen the IP and could be liable for derivative works. At this point, it's nearly impossible for you to build a "clean room" patch. It's not something I'd suggest doing without a paper trail of authorization.

I've worked with massively modified forks of MIT & BSD licensed code. I'm aware of ways to make these projects 100's of times faster, but these techniques and improvements are what give some companies their edge. They often have no interest in contributing and aren't required to, even if it makes sense.

The devil in me says do it anyway. Do what my former colleague does and release it under somebody else's name. Another colleague liked to say, asking for forgiveness is better than asking for permission. What's life worth without the risk of utter ruination?

On second thought, talk to your employer and really play up the benefits.

Pestilence