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

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.

Re:Bait and switch?

[LordNimon]

Frankly, I wouldn't be disappointed at all if we could get away from the word "free" altogether.

That's why it's really called "Open Source". Some time back, a bunch of people got together and realized that the term "free" was misleading. Anyone who tries to preach the GPL to a layman and uses the word "free" instead of "open" is making a mistake. In fact, it's quite easy to talk about the "freeness" of GPL code without using the word free. For instance, you can say that GPL code can be obtained at no charge and there are no licensing costs with using it. The problem is that the word "free" has several meanings, and therefore it's not a good word to use for people who are sound-byte oriented, like PHBs.