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

7 of 39 comments (clear)

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

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

      If the alternative to the Open Source software was proprietary software, your argument falls apart.

      First of all, it's not an argument. It was more of a cautionary tale. I thought I made it explicitly clear that I was neither advocating nor opposing anything. Just commenting.

      So your claim that somehow advocating the use of Open Source software was somehow misleading is wrong.

      I fail to see how. I pointed out that the GPL specifically (as a well-known example of an open source license) is a double-edged sword. On the one hand, you get something that you don't have to pay money for. On the other hand, you are required to accept certain responsibilities. Some of those responsibilities may be surprising and unpleasant. For example, GNU Readline, IMHO one of the most useful pieces of open source software in the world, is licensed with the full GPL. That means any program that links to GNU Readline must also be released under the GPL. Some months ago I was under the opinion that GNU Readline was licensed under LGPL. This was an unpleasant surprise for me.

      If GPL advocates (which it sounds like the submitter of the article was) spend too much time emphasizing the benefits of open source software, and not enough time disclosing the responsibilities that come along for the ride, people can very easily get the wrong idea about the GPL in particular and open source or free software in general.

      Incidentally, this process of spending more time talking about how great open source software is while down-playing its obligations is well illustrated by your post.

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

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

  4. Decision Factors by ninewands · · Score: 3, Interesting

    There are several things to consider before deciding that it would be wise to donate corporate IP back to an Open Source project. These particular decisions can usually be made either way without incurring the wrath of even the FSF:

    First factor:

    Are your patches merely bugfixes, or are they
    added functions?

    If they are mere bugfixes, I can't see where
    your management would object to releasing
    them.

    OTOH, if you have added new and significant
    functionality to the program, you might want
    to move on to consideration #2.

    Second factor to consider:

    In the case of new functionality, is there any
    reason to distribute it outside your company?

    If the modified program only has meaningful
    application within the context of a company
    similar to your employer do you think it
    would be wise to give your work to the
    competition?

    OTOH, if it is something that you need to
    distribute, say ... to your customers for
    their use, I would agree with the previous
    poster who wrote that contributing your
    patches back to the project might be necessary
    to prevent a lawsuit.

    As for protection from a lawsuit for having contributed your patches, I recommend you refer your corporate counsel to the language of the license that covers the package. The disclaimers in most OSS/FS licenses are much more protective of developers/contributors than even Microsoft's EULA is.

    Just my US$0.02

  5. Re:If it is GPL'd software... by Mr+Z · · Score: 2, Interesting

    Version 3 of the GNU General Public License supposedly will add verbiage to cover application service providers, though. Basically, the idea is if you take a GPL 3 application, patch it, and make its functionality publicly accessible, you're still liable for sharing the patches even though you haven't distributed the binary.

    GPL 3 is still vaporware, so the details may change. But it is something to keep in mind, especially if you deploy a commercial site that's backed by GPL software. If that software moves to a GPL 3 license, things could get interesting. I hope not in a bad way.

    (Before you all scream "FUD", keep in mind that I release all my own code under GPL 2. I can't say the same about the code I write at work, but then my employer owns that code, not me.)

    --Joe