Ask Slashdot: What To Do With Shelved OSS Project Fixes? 122
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')?
Easiest answer (Score:5, Insightful)
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.
Re:Easiest answer (Score:5, Insightful)
Re: (Score:3, Interesting)
The code you wrote is their property, but the fact that there is a bug is not. Pseudocode outlining a fix would also constitute new work. IF they stonewall, you can report the bug(s) later, anonymously, with a solution approach. Better than nothing, and not illegal.
Re: Easiest answer (Score:5, Funny)
Just tell me the bug, so I can fix it and we can close this story. Someone else fixing a bug is considered original work. Plus I'm probably a better coder and my fix will be awesome.
Re: (Score:1)
Re: (Score:3)
No it wouldn't. It would mean an email that says go ahead. Saving that would be sufficient. If you're worried beyond that, why the fuck are you working for those people?
Re: (Score:2)
Re: (Score:2)
Is there a reason why you didn't post the patches when you found them?
I didn't trust his "it's Ok" at that point. Mostly because of how often he changed his mind and blamed others. He often made outrageous claims about the code base. I had to start documenting both his requests and to monitor full code base changes in chronological order just to be able to refute his claims. I think it was more a matter of his being mercurial than "evil". When I reached out to his boss, he insisted that my boss had to make the call about what to do with OSS submissions.
Re: (Score:2)
How do you think I kept track of changes in chronological order? By hand? There are tools which will let you view deltas across the the entire repository (and I did mention that repository was in the company's private vcs). But this doesn't address keeping track of assumptions which go into building the system.
Absolutely no system is built to function in all situations. Especially systems built on small scale. So there is always limitations which you must accept. If you boss says, don't spend time a
Re:Easiest answer (Score:5, Insightful)
It's a former employer (I think I mentioned that in the question).
That doesn't matter. An email is good enough. If it goes through a "standard" email provider (Gmail, Yahoo, Hotmail, whatever) then it is a lot harder to forge and back-date an email than a formal written letter, and it will thus carry greater weight in court.
You: Can I release blah blah?
Them: Sure, go ahead.
That is ALL you need.
Re: (Score:2)
Not sure that's the best legal advice, but you should include a reference to the number of hours you spent, classified as either R & D or volunteer hours. Business loves that shit.
Not released means it isn't volunteer time, but RnD could be tax benefits.
Re: (Score:2)
Re: (Score:2)
If it goes through a "standard" email provider (Gmail, Yahoo, Hotmail, whatever) then it is a lot harder to forge and back-date an email than a formal written letter
How so? I have in my Gmail account e-mails dating back to 1996, way before Google existed. How, you ask? Easy: I simply copied my old e-mail archive, which at the time was stored in Unix MBOX and Pegasus Mail PM files, to my Gmail account so as to have it backed up there and thus searchable using an IMAP software. All those e-mails are properly timestamped at their original sending or receiving times.
In fact, I remember now that some of those e-mails didn't import correctly because the "Date:" field was in
Re:Easiest answer (Score:5, Insightful)
Well, so you're not willing to go the legal route for getting the code released. You said you don't want to release the code that you don't own, so that cuts off the illegal route. And you also don't want to forget about it. So I guess you took the only thing you have left: post on Slashdot, but don't do anything about it.
Re: (Score:2)
Yeah, I don't see anything worth worrying over here - so the guy worked hard and did something he thinks is good for a project that nobody else seems to care about anymore... Either he cares enough to get permission to publish, then goes to the trouble to share the update on someplace like SourceForge GitHub or whatever is in vogue by the time he works out the legal aspects, then goes to the trouble to promote the newly published "fixes," or... this is all a waste of brain cycles.
My advice: actually perfor
Don't need to pay a lawyer: (Score:3)
Re: (Score:2)
Caveat: I'm not a lawyer. But I don't see why this needs to be complicated.
But if you *were* a lawyer, you would instantly realize why everything needs to be complicated enough to need a lawyer. Everyone has to eat you know...
Kind of like hammers wanting nails..
Re: (Score:2)
Caveat: I'm not a lawyer. But I don't see why this needs to be complicated.
But if you *were* a lawyer, you would instantly realize why everything needs to be complicated enough to need a lawyer. Everyone has to eat you know...
Kind of like hammers wanting nails..
So it's a patch for an abandoned project that was also abandoned by the employer. Even if he released it without asking permission, it doesn't sound like anything that anyone is going to sue over and/or pay a lawyer for. It sounds like the plan was to eventually release it anyways. As long as there is no trade secrets in it, my guess is that even if you annoyed someone in the process of releasing it that they aren't going to be annoyed enough to follow thru with anything. Yes, everyone has to eat, incl
Re: (Score:2)
That would mean a formal legal letter. Honestly, I don't think I want to pay a lawyer for it. And I have my reasons for thinking that their word that "it's Ok", is not something that I can rely on. I don't want to break the thin veil of anonymity which is slashdot, but my former boss was prone to changing his mind. I would not want to rely on it as legally binding.
While I wouldn't rely on it to have good relations with a past employer, any kind of permission is a strong defense against legal liability even if the permission was withdrawn, misleading, incomplete or invalid. Both the doctrine of clean hands and promissory estoppel should stop them from collecting damages on a situation they themselves created, regardless of whether any laws were actually violated. That said a more formal permission may be useful to avoid a frivolous lawsuit, but being realistic some pe
Re:Easiest answer (Score:5, Interesting)
This. I've worked at various businesses, from a small family run one, to a big megacorp. At both ends of the scale, the management have been totally OK with me submitting code to open source projects, despite it not being a core part of the business but using open source code for various parts of our work. They have often even allocated time to do the work, and when necessary signed off on copyright assignment when required. And in the case of abandoned projects where the company no longer sees any commercial value, it should be even easier, especially when the work was already done and is just sitting around. It sounds like they are familiar with open source stuff, given that you were working on it as part of the project, so it really can't hurt to ask if it's OK to contribute back those changes. Chances are they'll say yes, and if not at least you tried.
Re: (Score:2)
Indeed. I would even expect that this permission will not be much more than a formality, after all the company intentionally went for an open source product, knowing that the changes would have to be published (assuming they would redistribute the software and it's GPL). From the wording of the summary I do assume that it was the intention to use the project, and that the code would be released in that case, so doing so for the other projects shouldn't be too much to ask.
Re: (Score:2)
it's easy to say that they potentially lose something by giving the fixes to be available for a competitor who is doing a similar product.
depending on the product or service they provide, it might be a big or a small thing. suppose it's a bug that affects scaling some net service for example.
Re: (Score:2)
And there has been those times I wanted to release a new tool I created to open source, because others may have found it useful and they weren't part of the core business. And I was denied. And what can you do? As someone already stated, they are paying for the code, so it's their call.
A
Re: (Score:2)
Re: Have you tried asking them? (Score:1)
Depending on the license, if they release a software that depends on it, they could be required to release the code.
This is precisely what thr GPL was designed for. But if it is licensed under a more permissive license like MIT or BSD, then its fair game. Microsoft is known to abuse BSD licensed code.
Re: Have you tried asking them? (Score:5, Insightful)
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.
Re: (Score:2)
> 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.
Re: (Score:1)
I think OP meant they would had had to anyway, as in they were planning on it, so why not just do it.
Re: (Score:1)
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..
Request Permission (Score:5, Interesting)
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...
Re: (Score:2)
It might just be good PR for the company anyway, especially if the fixes are significant. What does the company gain by not releasing the fixes? If it isn't released, it might wind up a dead-end fork being worth zero value to the company, while merging all changes results in not just the fixes from the OP, but other people's contributions as well, making for a better product for all involved.
Re: (Score:3)
Re: (Score:2)
Well, it sounds like you have bigger problems with that former boss, but permission to distribute is permission to distribute. At most he can do is demand you stop, depending on the license.
In fact with many licenses all you need to do is get permission to install a binary. That triggers the source code redistribution provisions.
Re: (Score:3)
Just get him to email you the ok. Seriously things don't need to be triple signed and witnessed in blood.
Re: Request Permission (Score:2)
Nice to see you actively replying to comments on your submission.
I think if lawyers need to be involved, it might be best to simply live and let live.
The alternative could be to, in your own time, make different improvements back to the project. Perhaps take a different approach to what/how you improved it last time and not using the same code you've already produced. Copyright on code is byte-per-byte (at least how I interpret it), so long as you're not using the code you produced for them, you would be in
Ask your boss (Score:3)
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.
A few options (Score:2)
Re: (Score:2)
Re:A few options (Score:4, Informative)
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.
could you.. (Score:3, Insightful)
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..
Re: (Score:1)
That's what I was thinking. If the original company isn't cooperative, then just reinvent the wheel slightly differently.
Usually I have a better design the second time around anyhow because I have the experience to shape it right from the start.
Re: could you.. (Score:2)
This.
Also if you're not on a strict deadline you can afford to be more creative and try a few different things.
Re: (Score:2)
Re: (Score:3)
Then stop fretting, ask and be done with it one way or another. Get an email from their system or a letter on their letterhead saying you can and do it. If you're too paranoid for that, drop it - there's no golden bullet.
Re: (Score:1)
Just submit the revised changes under a pseudo-name.
Anything can be bloated up if you work on it. Example:
Re: (Score:2)
If the fixes are small, then it sounds like *identifying* the bugs was the hard work? If so, maybe you could put together a list of all the bugs you fixed, mention where you made the fixes (which functions, etc), and then post that onlinewould that be enough to let someone else make the corrections? If the products are really in high circulation then someone is bound to be interested, maybe even your former competitors.
Three options (Score:2)
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
Re: (Score:2)
Re: Three options (Score:2)
This is also the simplest solution. That should be a further indicator of it being the best one...
Re: (Score:2)
A small nit-pick: surely you mean " clean room" [wikipedia.org] ?
Besides that, it's a good idea.
Re: (Score:2)
Re: (Score:3)
"Green-Room" is a waiting area backstage for entertainers just before they go on stage.
Re: (Score:2)
ask them (Score:2)
Releasing the fixes won't make it less abandoned (Score:5, Insightful)
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?
Re: Releasing the fixes won't make it less abandon (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:2)
File bugs and attach unit tests that clearly demonstrate how the problem occurs.Then if anyone is interested in maintaining the software they can.
Re: (Score:2)
Re: (Score:1)
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 discov
Bugtracker (Score:1)
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,
They don't own what's in your brain (Score:2)
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 comp
Company owned OSS projects .. (Score:2)
Ask the company to release the source code under the GPL license.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:3)
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.
Eithe
why legal limbo? (Score:1)
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).
Go rogue (Score:2)
Re: (Score:2)
Worst case you become an underground hacker/terrorist. Wouldn't that be exciting?
No. I get that you are kidding. But still... No.
You should have sent the fixes when you made them (Score:2)
Well......... (Score:2)
Not that I would ever suggest doing something like this, but they could end up being released into the wild anonymously.... *cough*
Easy (Score:3)
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.
Re: (Score:2)
Easy (Score:2)
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
Next time (Score:2)
What license are those OSS projects under? (Score:3)
Derivative work? (Score:1)
File bug reports and paraphrase your solutions (Score:2)
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.
Obvious answer: Better financial model (Score:2)
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