Slashdot Mirror


Submitting Corporate IP to Open Source Projects?

dannyp asks: "Does anyone have advice and/or references for working with a (very large and cautious) corporate legal department to establish a policy for submitting company-developed patches back to Open Source projects? I work at a large company outside of the technology sector (financial services). As we've succeeded in getting Open Source packages approved for use within the company, we're trying to figure out how to submit patches back to the community. We have to convince management that it makes sense to give this Intellectual Property away, and then (more difficult) convince Legal that we aren't going to get sued for doing it. Any advice?"

5 of 39 comments (clear)

  1. Re:If it is GPL'd software... by ivan256 · · Score: 4, Informative

    If it is GPL'd software then point out to them that they could be sued if they do not release the patches.

    That's completely untrue. You can use patches to GPL'd software internaly to an organization or personally without releasing code. You only need to release code if you plan on distributing the modified version.

    Go read section 2 of the GPL carefully.

  2. Bait and switch? by foobar104 · · Score: 5, Interesting

    I don't intend this as a flame-- or FUD, for that matter-- but it almost sounds like you may have inadvertently pulled a bait-and-switch on your company.

    You said, "we've succeeded in getting Open Source packages approved for use within the company," and this implies that you yourself-- as part of your group or whatever-- advocated the use of Open Source software inside your company. Did you make it extremely clear to the people to whom you were advocating that Free software is not entirely free?

    What I mean is this: when you download GNU SurfWriter from an FTP site, you don't have to pay anybody. You get to use the software for no money. But there's an opportunity cost attached. In using the software, you give up the ability to redistribute it in binary-only form. You give up the ability to incorporate any part of it in a closed-source application. You give up a number of "rights" as part of the "cost" of GNU SurfWriter.

    Put yourself in your boss's shoes for a minute. One of your employees came in last month and convinced you to use GNU SurfWriter. It's free, he said. You get the sources, he said, so you can modify it as you need. All good reasons.

    Now, just a few short weeks later, that same employee comes in and tells you that you either should or must (depending on the circumstances) release your company's changes to GNU SurfWriter to the public. He never said anything about having to give away company IP when he argued for GNU SurfWriter last month! Bastard! Now you've got to explain this to your boss!

    Net result: your boss, maybe your whole company, has a bad impression of the GPL specifically, and Open Source and free software in general.

    I'm neither trying to advocate or deride the GPL in this post. I'm just pointing out that that particular license is definitely two-sided, and failure to be very clear about its limitations can be a bad thing. Without knowing it, you yourself may have spread FUD by not telling the whole story.

    1. Re:Bait and switch? by sab39 · · Score: 4, Interesting

      This all depends on what you are comparing to. If the alternative to the Open Source software was proprietary software, your argument falls apart.

      Suppose that the alternative to GNU SurfWriter was Microsoft Surf. Would you have had to release your changes ("IP") to the public? No, if you'd made changes at all you'd have been sued by a company with extremely deep pockets. Even if it wasn't Microsoft, no proprietary vendor is going to let you make changes to their proprietary application without charging you obscene amounts of money.

      Note also that you are only required to give up the source to your changes if you distribute the modified application outside your organization. Again, this is something you couldn't even do with a proprietary piece of software. Chances are, if proprietary software was even a possible choice when this decision was made, you haven't been doing this. So you aren't required to do anything.

      So the only argument left is whether you should give back your changes. Sounds to me that the author of this article already knows full well that making a moral argument about what the company "ought" to do will get him laughed out of the room. So the arguments he's seeking are reasons why it's in the company's best interests to release its code.

      Now you can look at the situation the other way round: Hey, look, because this application is Open Source we have the opportunity to do something that's in our best interests that we never would have had the opportunity to do with proprietary software.

      Of course, I'm presupposing that releasing changes really is in the company's best interests. That's a separate argument (although I believe it's a pretty easy one to win :) ). But if it isn't, obviously, the company simply won't do it. So your claim that somehow advocating the use of Open Source software was somehow misleading is wrong. They got a bunch of benefits already through the use of the software. What the poster wants to do now is get another bunch of benefits (reduced maintenance cost is probably the big one) through releasing changes back to the original authors.

      (Also note that the original post never said that the software in question was GPL. The idea of giving back source is just as tempting for BSD and X11 licensed projects.)

  3. Unlikely in many companies by pmz · · Score: 4, Interesting

    When I was hired by my current employer, my contract basically stated that anything I do on their time is theirs.

    Things get even more complex, when my time is spent representing my company as a subcontractor to another company. During this time, who owns my work is spelled out in the contract between those companies.

    Thus, the only real answer to your question is: you have to convince the people who set up your business contracts to include a clause spelling out your rights to submit patches to Open Source projects. However, none of the parties in that contract want to pay a lot of money for you to work up such patches, so it will probably be an up-hill battle for you.

    Mainly, I have learned that large bureaucracies, such as those in large companies and governments, tend to stifle such initiatives. Also, you will find that no one in that bureaucracy will be willing to take on any risk for your sake.

    Sometimes these bureaucracies are so mind-numbingly stupid that sometimes I just want to go live in the woods for a while and play chess with my squirrel friends. Yes, that would be much better.

  4. more eyes on your code by josepha48 · · Score: 4, Interesting
    Tell them that it is 'free' QA on your code. If others find a bug they are more likly to fix it. Also there may be someone that takes your code and extends it or improves it in such a way that you get bennies from it.

    The QA part is a good seller. If you have only tested your stuff the way that you use it and someone else gets it they may test and use it differently. This helps you QA your stuff.

    --

    Only 'flamers' flame!