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.
You can always say "Hey, this code, you don't need it, you'd have to release it anyway, how about you do so, and let your tax accountant worry about whether or not it counts as a charitable donation or business expense, or whatever?"
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.,
I think your options are:
1. Forget about it
2. Re-write the fixes in a clean room environment using your own machine and your own time. Since you've fixed it once the development process should go faster, and then you will both own the code and the time used to create it. It's probably best if you don't stare too hard at the existing implementation first though... minor differences in implementation style will help ensure that this is truly a new implementation, and not just copying things from your employer.
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.
That "easiest answer" is actually much harder than forgotten about the changes and just moving on. Moving on doesn't involve asking anybody anything.
If you reimplement the fixes on your own time, you own the copyright on that work. If the fixes are small enough, it's not going to matter much if even if they're similar (try to sue someone for a one-liner taken from SO and see how far it gets you). If the fixes are larger, doubtless you could improve on the fixes and thus the code would be an original work distinct from the fixes done on their codebase.
At the end of the day, it's only going to matter if you think the company is going to go out of its way to sue you. If you're willing to take on that (relatively small, IMO) risk, then you could fall back on the EFF and such for legal representation (I think this is the kind of case they'd want to take on for precedent).
In most of the companies I've seen, once the people who worked on a project have moved on to other projects or left the company, the issue is basically cold and dead. No one is going to spend the time to audit this kind of issue unless there's some actual business benefit to doing so. In this case, you're not profiting from it, they would be (in the long run), and you're protected by the fact that this set of fixes is distinct (and done on your dime and equipment).
If all of this sounds too risky to you, then you'll have to do the "right" thing and actually pay to engage a legal professional who will advise you on the best course of action for you. Since this will cost you money, I doubt it's the path you'll prefer. However, it is the safest and most risk-averse way to approach such situations.
CAPTCHA: guilty (so don't do it!)
Before you used and adapted OSS, didn't you talk to your managers or higher ups in the company about what this would entail?
I'm confused why this is even an ask slashdot question. I had also an issue at my company about an abandoned OSS project. I posted the patches (everyone in charge knew that's how OSS works. Bug->Fix->Post). The main branch wasn't updated but the patches were still posted. Nobody at my company objected, because I talked to them before. Maybe nobody will even use these patches.
So practically, do you wish that we contact your company and ask their permission so you can post patches?
Or is a simple pat on the back and a "hey Superwiz, go ask if it's ok"?
The bottom line is that you or whoever chose to go this OSS route, didn't think it through. Or find a better way to communicate to your higher ups.
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?
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.
But since they shelved the projects in which the OSS code was to be used
This suggest that the projects that were company projects, not the original OSS projects.
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.
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.
Causing a fork is much more work than emailing a changeset submission. Though I wish people had done that a few times where the megacorp project I was working had bugs in the OSS sub-project that was frozen at a "stable" version earlier than active development. A couple of times I had to re-engineer a fix that was already in a later version, but could not be retrofitted directly into the older version due to other code/file changes. We shipped the changesets documented with the software, but unless somebody really dug into the bitpile, no one would notice and they also would be stuck with the "fixed in current version" responses.
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.
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
Okay, so your employer one day gives you a pile of money and sends you to the local box store to buy 27 60-inch flat screen monitors. The company deploys 25 of them but puts 2 others in a warehouse with absolutely no intention of ever using them. You know that the local rec center could really use those TVs and you also know that the company would never miss them if you just took them. Do you take what doesn't belong to you even if you know 100% you will never get caught or do you ask for permission? It really is that simple to me. Obviously not a perfect analogy, because you can always point out flaws in the code without uploading work you do not own. But make no mistake. The company owns that code. And those TVs. You don't.
describe your bug fixes to those people and they can fix them independently of you
This seems like a solution which would work.
If this works, then why did he fix them on company time first, instead of going this way directly?
Unless the "abandoned" software is being distributed by one of the larger Linux distros (Fedora, Debian, Ubuntu, Gentoo, Arch). If it is, you submit the bug fixes to at least Fedora and Debian (or Ubuntu), and you will notice the fix not only will get accepted, it will eventually leak to the other distributions. And it *will* reach a large number of users of that software (how large depends on how popular it is, of course).
And it is standard practice when reviving a software project, to contact the downstream maintainers of the big five distros or direct download their versions of the package, check for all changes they made, and incorporate them into a the new, ressurected upstream branch. I've seen it happen a number of times.
You'll probably find the answer to your questions in the terms of the license.
Another option could be to duplicate the work while documenting your efforts in order to prove that it is original work. Then submit your new fixes.
I was in the position of having fixed bugs in open source code under contract to a company. BUT, the company didn't pay, still didn't pay, then went bust. So I released.
Even though they've decided not to continue using and improving that particular project, they gain nothing by withholding the fixes
You can't know that at all. They may and like will gain a competitive advantage by NOT enabling other to compete with them. This is standard operating procedure in business. It's why businesses routinely buy out competitors and then close them down and or abandon their technology.
If management thinks even for the slightest moment that releasing the fixes will enable a competitor, even a free open source competitor, they will be strongly opposed to releasing the code. See Google, Facebook, Microsoft, Apple and every other for profit corporation out there. In business, you do not enable your competition. Don't even bother responding with outlier anecdotes. General operation practices say; NO!
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.