Slashdot Mirror
Ask Slashdot: What To Do With Shelved OSS Project Fixes?
New submitter superwiz writes: A company for which I worked for recently had a project which required debugging a few abandoned OSS projects. 2 of the projects ended up not being used in the company products even though bugs were found and resolved in them. This puts me in a legal limbo. Since the company paid for my time to work out those bugs, they own the copyright. I can't release them. But since they shelved the projects in which the OSS code was to be used, they don't have to release the code to the public. It would be pretty simple to identify me as the person who made the changes even if I were to release the code anonymously because these changes were committed to my former employer's private repository. Should I just forget it? I don't like the idea of information loss, especially given how much benefit that company already derives from other OSS projects. But I also don't want to release the code which I don't own. Has anyone been in this situation before? How did you handle it (other than just 'forget about it')?
Just ask your company. Even though they've decided not to continue using and improving that particular project, they gain nothing by withholding the fixes, but could gain developer goodwill (useful in future endeavors) and positive PR (always nice to have) by allowing the patches to at least be submitted upstream, even if they're not ultimately merged.
I suspect that one of these choices is incorrect. Correct.
Have you simply talked to your employer about it?
Not all businesses, or at least the management, are blood-sucking, money hungry, assholes.
Perhaps work out a deal where you do some pro-bono on the next project in exchange for the right to release the code? I mean, if the benefits of releasing it is that beneficial to the community, surely you can suck up a some unpaid time in exchange for its release...
Depending on whether your company is more lead by legal or marketing they'll either decide to release the changes for good PR, or to shelve them in case the changes have some sort of issue. You should be able to get a pretty clear steer on which way your company operates from your immediate manager.
It's worth knowing, because companies so scared of legal issues that they won't contribute to the commons are sad places to work.
Could you re-write the fixes?
Say you get together a list of the bugs and re-code the solution on your own time, releasing that? Otherwise you would need to convince your employer to release them on their own. Maybe as a good will sort of thing to improve a future endeavor..
I'm assuming the project hasn't been updated for several years for it to be in "abandoned" status.
Honestly, why do you think your fixes would ever go anywhere and be incorporated into the project? Projects look like code, but in reality consist of people. Without the people, why does it even matter?
If there's a community of people who still use the code, describe your bug fixes to those people and they can fix them independently of you. If there isn't even this, then who exactly is going to benefit from your fixes?
"A company for which I worked for recently had a project which required debugging a few abandoned OSS projects .. Since the company paid for my time to work out those bugs, they own the copyright. I can't release them."
Ask the company to release the source code under the GPL license.
Publish the fixes. If they come after you, unleash the Streisand effect on them. Worst case you become an underground hacker/terrorist. Wouldn't that be exciting?
There's no need for a formal legal letter developed by a lawyer. This is straightforward. Send an email to your boss and say, "May I please release these code improvements to this open source software under their respective licenses?" If he says yes, then keep the email - and perhaps better, post it publicly somewhere. Your boss can change his mind, but that doesn't change anything. If you buy a car, and a year later say "hey, I've changed my mind", you don't suddenly get your money back. As long as there's no initial deceptions, or something illegal about an agreement, then agreements stay that way. If he says no, well, that's that. Sometimes organizations to silly things, but it's their legal right to do silly things. Caveat: I'm not a lawyer. But I don't see why this needs to be complicated.
- David A. Wheeler (see my Secure Programming HOWTO)
It's obviously too late now, but I'd have sent the fixes upstream when I first wrote them – before the product was cancelled. If everyone believed the product was going to go, they couldn't really have argued against doing that. After all, why sit on fixes? Bits on a hard drive don't get better with age. Send them upstream as soon as you've written them. So what if they're not beautiful. The worst thing that might have happened is you'd have gotten feedback with suggestions for making them even better.
Other than that, if you're not willing to ask for permission now, or they say no, then I think now you have to do what others have suggested, i.e. black box it. Get a friend, tell him or her what needs fixed, have them submit their fix. Once their patches are submitted upstream I would think it'd even be okay to comment on their fix.
The summary says they haven't done any distribution, so they have no requirement to release the source.
since they shelved the projects in which the OSS code was to be used, they don't have to release the code to the public.
Also, it's impossible to "abuse" BSD-licensed code. The license literally says do whatever you want with it, including selling it, with no need to release source ever. Microsoft has just followed the license.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I'm assuming the project hasn't been updated for several years for it to be in "abandoned" status.
I could fork them on github and the fork could be picked up by some distributions. On my last check, there were no public forks which would contain these fixes.
describe your bug fixes to those people and they can fix them independently of you
This seems like a solution which would work.
Any guest worker system is indistinguishable from indentured servitude.
Ok. I've read a couple of your posts now. I have no idea what you think copyright extends to, but talking to someone is not one of them. If you have a confidentiality agreement on your employment that is another thing entirely.
Seriously I deal with significant money contracts every single day. An email acknowledgement is more than enough contract to go on. Get your ex-boss to ok the release. If he says no, then you drop it. If he says yes, then you are good. If he changes his mind you have the email trail.
Just prepare a detailed description of how to write the fix(es) and post it where some interested party can find it. See, the copyright applies to the code, and that's the easy part... the hard part is knowing what to do and why. That knowhow is yours, you own it, and you can do what you want with it, especially if you happen to live in California.
When all you have is a hammer, every problem starts to look like a thumb.
It's called "Clean-Room" to isolate the original developer from the team that re-writes the fixes.
"Green-Room" is a waiting area backstage for entertainers just before they go on stage.
root of the poisonous tree
fruit of the poisonous tree? That applies to evidence gathering, not copyright. Re-implementing your own code might be argued to be a derivative work of your own original code (you can't be your own clean room), but given how small the bug is it's hard to prove.
It would be awfully hard to argue that an edge case bug fix is going to dramatically improve sales. There's no such thing as fruit of the poisoned tree in copyright - but you said yourself that the code is probably viable without the bug fix.
Either way, I'm not suggesting you should do it without permission.
You'll probably find the answer to your questions in the terms of the license.