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

Comments

Re:If it is GPL'd software...

[ivan256]

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.

Bait and switch?

[foobar104]

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.

Re:Bait and switch?

[sab39]

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

Re:Bait and switch?

[foobar104]

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.

Unlikely in many companies

[pmz]

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.

more eyes on your code

[josepha48]

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.

Re:more eyes on your code

[sab39]

Beyond that, since the implication of the article is that these are changes to existing projects, tell them that keeping a locally-modified version will require substantial maintenance just to upgrade to each new release. In other (buzz)words, emphasize the large recurring maintenance cost of the status quo.

Paying once for the time spent in politics with the external maintainers to get the patches integrated will probably be less than the cost of upgrading to a new external release even once.

The other thing to ask is whether the company expected to make any money directly off the code changes in the first place. This may be "Corporate IP" that has a theoretical monetary "value", but in most cases the company has no plans on actually realizing that value. Point out that you aren't really giving away any value if you weren't planning on getting any dollars out of that value in the first place.

They might respond to that with "well, we should go and figure out how to realize that value, then". If they do, you might want to actually go through the motions of exploring how to extract the value. It should be fairly obvious without biasing your results that there really isn't any way to profitably extract value from a few random patches to an open source project. Ask if they really want to get into the software-selling business. Figure out how much it would cost to create the infrastructure and legal red tape to do this (count people's hours at billable rate if you like), and guesstimate an optimistic figure for how much you could sell the patches for, and how many copies you would sell. Present all of this in a nice presentation showing how you'd actually lose a substantial amount if you tried to do it.

Given all this background, you can present the three alternatives: Keep the code private (large recurring maintenance cost), sell the code (certainly a negative profit), or give the code away (small one-time integration cost). The desired course of action should be obvious :)

Decision Factors

[ninewands]

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

Avoid patch maintenance

[sydb]

If your company doesn't release the patches, they will have to be reworked into new releases of the vanilla source tree.

However that doesn't mean everybody else will do your work for you. If there's a conflict between your code and someone else's, you might be expected to fix your code. But being in first gives you an advantage.

So, sell patch release as reducing the code maintenance overhead.

None of this from experience, just common sense and observation.

Re:Another question

[sab39]

I patched GNUJSP to add support for parameters with multiple values. This was necessary for a production project which has been the major thing I've worked on for 2 years. Since GNUJSP was essentially unmaintained even back then, that bug was never going to get fixed unless I did it. I would have submitted the patch to the upstream maintainers if there were any...

Long term, of course, I'll move to another, maintained project. But at the time I made the fix, none of the alternatives were mature and the rest of my code was tested with GNUJSP only. I saved days of work porting to a new JSP engine (and probably dollars as well, because the alternative free ones at the time didn't meet my needs) just because I could fix the code myself.

That's the one that I trot out for corporate arguments. For personal use I could also mention that I patched abcde to be able to handle my mp3 directory layout, and added autohide support to Mozilla's Site Navigation Bar because I didn't want it wasting space on my screen when it was empty. I submitted both of these changes to the maintainers and in both cases they were accepted. I didn't have to in either case, but I didn't want to have to keep manually patching every new version that got released.