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

Another question

[Otter]

Out of curiosity, to the degree that people all talking about their own experiences and not just running their mouths:

Could you give some examples of what GPL products you've patched and (to the degree you can say) what the patches add or fix?

I'd like to get a sense of how much advantage users really get from having source available.

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

[LordNimon]

You give up a number of "rights" as part of the "cost" of GNU SurfWriter.

Compared to BSD-style licenses and truly public domain code, yes. But keep in mind that under normal copyright law, you never had the right to distribute the binary in the first place. The GPL gives you the right to distribute it, provided you abide by one condition: the source code goes with it.

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]

The GPL gives you the right to distribute it, provided you abide by one condition: the source code goes with it.

Fair enough. From my point of view, they're two sides of the same coin. On the one hand, you get the source code and the right to use it for no money. On the other hand, you accept certain obligations, such as making your changes to the source and the source to derivative works available to the public.

All I was saying is that it's important that we be equally open about both of these: the right, and the responsibility.

(Frankly, I wouldn't be disappointed at all if we could get away from the word "free" altogether. GPL-licensed software is not free in the sense of having no cost associated with it. It's also not free in the sense of having no restrictions on it. I'd be just as happy if we could avoid the discussion altogether by using a different term than "free" to describe software licensed under the GPL.)

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.

Re:Bait and switch?

[sab39]

Unfortunately, you snipped the parts of my post that were most relevant to your argument (or cautionary tale, or whatever).

My point is that the "extra responsibilities" of the GPL are only "extra" by comparison to other, more liberal kinds of Open Source software. Since the poster was talking about having achieved victory in getting any Open Source accepted in his corporation, I think it's probably a safe assumption that the alternatives were proprietary applications. (There is, admittedly, another possibility which I'll discuss in a minute).

If you're in a situation where a proprietary application is a viable alternative, that means that you only need to do things which are permitted by a proprietary application. That is, you aren't distributing it outside your organization. If that's the case, the GPL places NO restrictions on you. The "double edged sword" only starts applying if you start doing things that you couldn't do at all with proprietary software, and there's no indication that the poster's company is doing those things.

I didn't get the impression that the original poster was a GPL advocate. His post never mentioned the GPL, and his position makes perfect sense independent of which Open Source license applies. And regardless of the license, as I said above, it's highly unlikely that his company is doing something that would cause the limitations of the license to come into play.

I'm certainly the last person to hide the responsibilities that come with Free Software (and I've known about Readline for years, and disagree with that licensing choice - but usually avoid using Readline in my projects for that reason). But knowing what the responsibilities aren't is as important as knowing what they are. There's no need to emphasize the GPL's requirement to give away source with all binaries if the person you're talking to had no plans to give away binaries at all. It just confuses the issue.

Now, the other possibility I mentioned above is that the alternative to Open Source was custom-developed applications, built in-house. In that situation it is plausible that the applications would be distributed, and the GPL requirement would apply. My arguments are based on the assumption that that is not the case; if it is, then I agree that it was dishonest to advocate GPL software without mentioning that restriction.

But that's a pretty big set of "if"s: IF the alternative was software developed in-house, AND IF said software is distributed outside the organization, AND IF the open source software in question is distributed under the GPL, AND IF the poster didn't think to mention any of these facts in his post, AND IF it didn't occur to the poster that "you're required to by law" was a valid answer to his Ask Slashdot. Add to that a dollop of giving-people-the-benefit-of-the-doubt, and I'll stand by my assumption that the restrictions imposed by the GPL don't apply to this poster's situation.

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.

Re:Bait and switch?

[foobar104]

Aha! I know I'm on the right track when I learn that somebody smarter than me actually thought of it years ago.

<burns>Excellent.</burns>

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

Re:Decision Factors

[RocketJeff]

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.

Nope, you only need to provide the patches to the customers you distributed the software to. Since you have to be able to give them the source anyways (because of the GPL), this shouldn't be much of a burden.

With the GPL, you don't have to give the source to anyone you didn't give the binary to. It seems that most people read things into the GPL that aren't really there...

Re:Makes sense?

[isorox]

I highly doubt giving away your IP is somehow going to make you more profit than you lose.

We need software X to do function Y. It will take 50 man hours to complete at $50 per hour. Thes $2500.

However, release code, ask for feature, 2 weeks later function Y is in product X. Take code. Use Code.

Net gain $2500
Net loss $0

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:Makes sense?

[sab39]

Fifthly, the poster specifically said that lawyers would need to be consulted before code could be released. Lawyers are at least as expensive as coders, so your "Net loss: $0" is certainly not accurate.

How about this scenario. The figures could go either way, but it's important to note which figures are one-time and which are recurring...

Releasing code:
- Lawyer time ($nnn, one-time)
- Programmer time to work with external maintainer to get patches accepted into the external source tree ($mmm, one-time, probably not a terribly large amount of time)

Keeping code internal:
- No lawyer time ($0)
- No up-front programmer time ($0)
- Programmer time to re-integrate local changes into new externally-released version of program ($ppp, recurring, and probably much larger than $mmm, at least).

Now, depending on the lawyer cost, a single upgrade might or might not work out cheaper if the code is kept internally. But eventually a recurring cost is guaranteed to come out greater than any one-time cost. This is even more true if the legal work can be done once to cover all future open source contributions, so that the lawyer cost can be split across multiple applications.

What a lot of managers don't realize is that maintaining a fork of a program's source code is expensive. As your codebase diverges from the external one, important bugfixes applied to the latter become harder and harder to apply to your local copy, taking more and more programmer time to keep up. Paying a little more up front in that situation is just good sense.

Re:Makes sense?

[anthony_dipierro]

Programmer time to re-integrate local changes into new externally-released version of program ($ppp, recurring, and probably much larger than $mmm, at least).

That's actually an excellent point. If you're making changes to a moving target, and the maintainer seems agreeable to letting in your enhancements, then not only do you save money by not having to constantly merge, but you also get a less buggy product due to increased testing.

Yep, I overlooked that factor. Thanks for the insight.

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

[Mr Z]

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

Re:Makes sense?

[j09824]

It doesn't make sense to give the Intellectual Property away. Your company exists to make profit. I highly doubt giving away your IP is somehow going to make you more profit than you lose.

Donating IP to an open source project gives you company visibility, good will, attracts programmers, invites enhancements from other users, and in many cases reduces your maintenance costs. That often beats letting the stuff sit in a drawer, where you derive exactly zero benefit for it, or even have to pay for continually patching it into open source software.

No, contributing code or ideas to open source projects isn't always a financial win, but it makes a lot of sense much more often than you suggest.

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

[j09824]

They only have to distribute the patches/sources if they distribute the binaries outside their organization. If it's for internal use, they can do whatever they want and keep it secret.

We fixed a gcc bug.

[Jerky McNaughty]

We found a code gen bug in gcc a long time ago on Sparc. We fixed it and submitted a patch. We could have, perhaps, worked around it, but we didn't need to since we had the gcc source.

Incidently, the gcc source is surprisingly easy to read. I've referred to it numerous times to see why something does what it does, what different command line options do, etc.