Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Businesses Open Source Software

Ask Slashdot: What To Do With Shelved OSS Project Fixes? 122

Posted by timothy from the why-not-ask-your-old-boss? dept.
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')?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What To Do With Shelved OSS Project Fixes? More

Ask Slashdot: What To Do With Shelved OSS Project Fixes?

Comments Filter:

  • Easiest answer (Score:5, Insightful)

    by Mhrmnhrm ( 263196 ) on Thursday February 25, 2016 @06:28PM (#51587211)

    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)

      by Meadlin ( 748216 ) on Thursday February 25, 2016 @06:32PM (#51587271)
      Agreed. Most of the time companies will allow the release of OSS changes as long as not core intellectual property is released. As long as you don't post the fix without consent (GET IT IN WRITING!!) you're fine. If they don't allow the release, well, you have to remember, you were paid for the work, so it's their choice..

      • Re: (Score:3, Interesting)

        by Anonymous Coward

        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.

    • 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.

      • Re: (Score:3)

        by AuMatar ( 183847 )

        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?

        • It's a former employer (I think I mentioned that in the question).

          • Re:Easiest answer (Score:5, Insightful)

            by ShanghaiBill ( 739463 ) on Thursday February 25, 2016 @07:22PM (#51587711)

            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.

            • 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.

            • I would say both. An email and a notarised letter printed on dead trees. Actually hell, go further and print the email and have that notarised, as well.

            • 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)

        by aardvarkjoe ( 156801 ) on Thursday February 25, 2016 @06:58PM (#51587487)

        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.

        • 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

      • 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 t

        • Re: (Score:2)

          by slew ( 2918 )

          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..

          • 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)

        by Kjella ( 173770 )

        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)

      by rl117 ( 110595 ) <{ten.erbiledoc} {ta} {hgielr}> on Thursday February 25, 2016 @06:47PM (#51587415) Homepage

      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.

    • 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)

      by gl4ss ( 559668 )

      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)

      by flajann ( 658201 )
      I try to get agreements upfront about such matters. Already I've had to grab two open source projects and fix them, and in those cases I did put the fixes back out there in OSS land. Just make the agreement up front.

      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

  • Request Permission (Score:5, Interesting)

    by corychristison ( 951993 ) on Thursday February 25, 2016 @06:31PM (#51587245)

    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...

    • 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.

    • I would characterize my former boss as mercurial rather than "an asshole". Without some legal framework which indemnifies me, I would not rely on him not changing his mind down the line. And I am not crazy about paying for lawyers just to submit patches to projects I already had to fix which were abandoned by their original authors.

      • Re: (Score:2)

        by hey! ( 33014 )

        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.

      • Just get him to email you the ok. Seriously things don't need to be triple signed and witnessed in blood.

      • 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)

    by lakeland ( 218447 ) <lakeland@acm.org> on Thursday February 25, 2016 @06:31PM (#51587253) Homepage

    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 develo
    • The projects were abandoned. That is, they are in common use, but are not maintained. So I am not sure that reaching out to the projects is an option. I also don't know if that in itself would not violate my former employer's copyright.

      • Re:A few options (Score:4, Informative)

        by Harlequin80 ( 1671040 ) on Thursday February 25, 2016 @07:25PM (#51587733)

        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)

    by Anonymous Coward on Thursday February 25, 2016 @06:33PM (#51587279)

    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)

      by Tablizer ( 95088 )

      Could you re-write the fixes?

      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.

      • This.

        Also if you're not on a strict deadline you can afford to be more creative and try a few different things.

      • I think my agreement stated that they own all work product. And since the projects are in common use, improving them could be be argued to be helping my former employer's competition (because they can incorporate the better versions in their products). I wasn't adding huge features to them. They just had very minor bugs and we were the edge case where they would show up a lot. The projects are in common use (despite not being maintained), so that should tell you that they are not some smoking POS which

        • 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)

          by Tablizer ( 95088 )

          Just submit the revised changes under a pseudo-name.

          From what I can remember, the fixes were too small (within 1-3 lines) to be done differently.

          Anything can be bloated up if you work on it. Example:

          NORMAL

          print(a + b)

          BLOATED

          am = new math.ArithmeticManager()
          opA = new math.Operand((float) a)
          opB = new math.Operand((float) b)
          am.addOperand(opA)
          am.addOperand(opB)
          am.operator = new math.operators.Addition()
          am.executeMathOperat

        • Re: (Score:2)

          by LihTox ( 754597 )

          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.

  • 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

  • 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.,

  • Releasing the fixes won't make it less abandoned (Score:5, Insightful)

    by Anonymous Coward on Thursday February 25, 2016 @06:35PM (#51587321)

    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?

    • 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.

    • 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.

      • 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:1)

      by eionmac ( 949755 )

      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)

    by Anonymous Coward

    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,

  • 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

  • "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?

    • Worst case you become an underground hacker/terrorist. Wouldn't that be exciting?

      No. I get that you are kidding. But still... No.

  • 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

  • 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)

    by Tough Love ( 215404 ) on Thursday February 25, 2016 @07:57PM (#51587995)

    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.

    • This or, as some others suggested, a bug report would probably do the trick. I don't know why I haven't thought of it myself. Probably a mental block because I already had the fix.

  • Easy (Score:2)

    by dbIII ( 701233 )
    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
  • For next time, use a public github as you go when working with OSS, that way it's already public.

  • What license are those OSS projects under? (Score:3)

    by Ihlosi ( 895663 ) on Friday February 26, 2016 @07:50AM (#51590491)
    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.

  • 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.

  • 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

Slashdot Top Deals

Love may laugh at locksmiths, but he has a profound respect for money bags. -- Sidney Paternoster, "The Folly of the Wise"

Close