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.
First, do you have a decent relationship with your former company? If so, good, reach out to someone there who might be able to get you authorization to contribute them back to the project Second, if they won't or if you can't, reach out to the project and at least notify them of the bugs and I would assume you can provide the details of where they are located. You're already providing more than a bug report at that point which helps them more than nothing at all. Third, work with another person to develop a clean-room patch so it isn't your exact work and therefore not your former company's work product.
Error: Sig not found.
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..
1. Ask permission
2. Break the law and throw the dice
3. Re-write all pieces of code that you updated before. Your company doesn't own your ideas (yet), just your expression of your thoughts during business hours. IANAL If you happen to express that over again, there's little chance that a lawsuit would succeed. If you signed a draconian NDA that says the company owns your thoughts then you may have issues.
Realistically through, you're better off forgetting the whole thing and move on to your next interesting problems.
Bye!
Seriously this is not your call. Ask the company, if they really have no use for the code and are OSS friendly chances are they will let you publish the fixes. If they say no, well then that is also their right and you have to live with it, it aint your decision to make.,
So you're basically saying they should lie to their bosses by saying they have to release it anyway? Also, they don't need to take a special deduction, since they're already able to deduct the employee's wages and overhead.
"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.
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?
Post the fixed bugs to bugtrackers for the affected projects and offer code snippets or at least pointers to the places where fixes need to be made.
Do not submit the fixes directly, as that would be a copyright problem. But copyright can't cover your recollections of where problems lie, and a not-for-profit open source project isn't going to be usable as a "competitor" in a non-compete clause. It might even be safe against NDA, depending on lawyer-y details. Your only risk might be from a trade secret case, but that's an unlikely prospect.
IANAL, but I do not anal. YMMV. HTH. HAND. Et cetera.
I agree with the previous comment about asking your company for permission to release the fixes. But if that is not practical, it's easy enough for you to write up a description of the bug and was was needed to resolve it and then circulate this information. If someone else then resolves it by writing their own code, you are safe from copyright liability.
That being said, watch out for NDAs that you may have signed - be cautious if you think someone else may gain a competitive advantage over your former company if you release this information.
"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.
I'm not sure what is meant by "legal limbo." As others have suggested, just ask your boss. If you're in an industry stuck in the 80s like mine the answer will be "No! They'll steal all our SEKRETS if they have our sauce!" In that case, let it be and move on. If they give you the go-ahead, then party on, dude(tte).
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?
I think OP meant they would had had to anyway, as in they were planning on it, so why not just do it.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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)
I see old projects forked to repair bugs all the time... then the new implementation becomes the standard because its under active development. This is one thing I actually like about Github. You can fork an old project really easily, add your own spin, and people can find it when they run into a wall with the parent project.
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.
try to sue someone for a one-liner taken from SO and see how far it gets you
If it enables their competition, they can sue for loss of sales. They can also sue anyone who uses anything based on my fork of the project years from now by claiming root of the poisonous tree. They don't need to sue to stop use. They can sue for monetary damages resulting from loss of sales if any of their competitors use the same project in their product.
Any guest worker system is indistinguishable from indentured servitude.
The better argument might be: Then it's all there and working upstream and if you ever end up using the product again you won't have to find and update those old fixes.
Because it's honestly not so unlikely that a year in the future they will try something similar again and everyone forgot about last time and they'll just debug and fix the same issues all over again..
Not that I would ever suggest doing something like this, but they could end up being released into the wild anonymously.... *cough*
Just cruising through this digital world at 33 1/3 rpm...
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.
File bugs and attach unit tests that clearly demonstrate how the problem occurs.Then if anyone is interested in maintaining the software they can.
If somebody wants it, you want to give it to them and are allowed to do so by the author of the changes then the code has to go with it.
If none of those fit it does not matter and the changes will be forgotten.
The licences are really very simple. The code only has to be released to people that are using the application defined by that code. If nobody is using that version there is no obligation to release the code.
While it would be nice to give something back whoever did the patch owns it and are under no actual obligation to release it to anyone that is not using a version with that patch.
Yes but the thing that makes that all less toxic is that the applications are typically not something the org could seriously consider selling and a million miles from any trade secrets of the org. If there is someone in management that went near a university for something other than an MBA you could put the patch to them as being similar to publishing a paper - a positive contribution with the name of the company on it and no threat to the business model.
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.
> Depending on the license, if they release a software that depends on it, they could be required to release the code.
They're required to release the software to people for whom they've provided the binaries. It doesn't have to be public; it doesn't have to be made available to anyone else. And it can be dual-licensed, which many projects are.
For next time, use a public github as you go when working with OSS, that way it's already public.
Website Just Down For Me? Find out
You'll probably find the answer to your questions in the terms of the license.
IANAL but surely any patches would be considered a derivative work. If this is the case then your employer can't own them as they are a derivative work of an already open source project so the original license would still apply.
I use emails to create and confirm multi-million projects daily including all legal terms and commercial considerations, email (and especially if a copy is sent to a public system e.g. xxx@gmail.com) can be retrieved by a court if you need to defend outside of any closed domain emails or quote and publish exchange on such as Slashdot for public record. Emails have legal validity. Think problems of Mrs Hilary Clinton in USA (I use Mrs as there are some Mr Hilary Clinton names in UK/EU).
Also as you discovered a bug, irrespective of copyright on solving code you should report bug to present users or forum of 'project ', you can then meet or have voice phone to discuss problem, as long as you do not send a specific total draft of solution you are clear of copyright violation. (IANAL, but I draft and confirm contracts and copyright clauses daily as my paid employment).
Regards Eion MacDonald
It would work as far as getting me out of the legal limbo. It would not have worked as far as fixing and delivering the component of the system when the company wanted it delivered. Different problem requires a different solution. Why is that surprising?
Any guest worker system is indistinguishable from indentured servitude.
If you just describe in plain English what you did as a fix to each bug, that is not subject to copyright. That's communicating an idea, which is not subject to copyright. Only the particular form of expression (or a straightforward derivative of the form) is subject to copyright.
Where are we going and why are we in a handbasket?
Probably too late to matter, but this is another case for super-better-financial models!
How much would your company want as compensation for the development of the software? If only there were a mechanism by which the completed project could be described, and if enough 'charity shareholders" wanted to chip in $10 a share, then everyone could be happy. If too few people are interested, then your employer just has to eat it, which seems to be what's going to happen.
More details available upon request, but it doesn't look like Slashdot or Sourceforge is that innovative, eh?
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.