Slashdot Mirror
Properly Contributing to Open Source While on Company Time?
egeorge asks: "I was wondering what kind of paperwork/policies developers have at their jobs concerning contribution to open source projects. I develop software at a company that derives almost its entire revenue from software. Some software is licensed to customers, some is run internally in a service model, but the software is our whole business. We have recently been doing more and more modification and customization of open source products, and we would love to give some of this back. As developers, though, some of us are a little hesitant to just start flinging code that technically still belongs to the company out into the world. We want to make sure we get clarification about what is or is not covered by our NDAs.
So, what kind of procedures do other developers have to go through to get adequate coverage for Open Source submissions? I would like to suggest a policy to my superiors, and could use a few good suggestions."
Yes, but its in your best interest to release your changes back to the communtiy so you won't have to manually merge code in later versions.
When our company needed to use some open source, we had a meeting with the legal department. Basically what they said is that if it didn't contain any proprietary information relating to our line of business then we could release it. Since the project just converted xsl to rtf then we didn't have to worry about it and got a green light.
Since we've put it into production and release the changes we made back to the community there have been 3 releases that we don't have to maintain ourselves. The whole thing probably saved us about a man year.
Why, o why must the sky fall when I've learned to fly?
If it's true GPL code and they're distributing it to outside customers, well, they're idiots. Because they now either have to remove the GPL code entirely or release the entire application under the GPL.
If it's LGPL then they need only release any modifications to the library or other LGPL'd code they did. Or, again, remove the LGPL code -- presuming they're distributing it at all.
If it's BSD or similar it's irrelevant, as you said, as long as they keep the copyright notices, etc. in tact.
Essentially, check the license before you use the code and know what it means. We use a great deal of LGPL, BSD, and public domain code in our products. We stay away from GPL though -- we don't have any intentions of distributing at this point, but if we did we'd rather not have that problem.
As far as remitting work back to the community - talk to your managers. If your managers are decent then they'll understand the issues involved. It may take some time, but most likely you'll be given the OK. After all, think about what you've modified in the code -- does it give any advantage to your competitors? Does it reduce the value of your product to your customers? Are the changes bugfixes or new logic that's only applicable to your company?
Actually, we do have one GPL program that we've modified... vsftpd. Again, no plans on redistributing it, but if we did it'd be no problem submitting the changes. They're deeply specific to our company and our usage and would utterly screw up anyone else who used them (things like automatically assuming paths on puts and gets so our customers don't have to do cd, and automatically moving files on completion of transfers (which might be useful)).
Do not work on OSS during company time though, not without explicit written consent. And many companies are now claiming anything you work on, even outside of work, to be their IP (which is on somewhat shaky grounds)... so if you want to work on OSS outside of work, check your contract and get a release from management if needed. Don't just do it -- in the worst case you're really, utterly screwing the project to the point where it may have to be removed from the net (at least officially). Most companies won't give a crap, as long as you're not doing it on company time and it's not competing with them.
Do you work for Microsoft?
Alan Robertson, who maintains the heartbeat package and works for IBM, recently posted to the ha-linux list on this subject.
Alan does not accept patches to the heartbeat code that were developed on company time unless he receives a disclaimer from somebody at the company.
This is obviously spoofable, but it's probably a good way to legally protect the code -- Alan can honestly say he received it in good faith, which keeps IBM's lawyers' from breathing down his neck. It's kind of weird for me, though, I have to send a disclaimer giving myself permission to send in a patch....
So, to answer your question: explain to your CEO why helping the OSS community helps you to help your company, and get her/him to sign off on a policy that allows you to do so. Ask for legal authority to be delegated to yourself (or your boss) to license or assign corporate intellectual property to open-source projects. Then have HR propagate the policy to your co-workers.
Where I'm working right now (TimeSys), I've been involved in contributions to Eclipse and Cygwin. Here's some advice:
ASSUME THAT YOU ARE NOT ALLOWED TO RELEASE ANYTHING WITHOUT PERMISSION.
If there's no clear policy already in place, ask. You probably don't have the authority to act as an agent of the company with regard to making decisions about IP. (If you don't know for sure whether you have that authority or not, you should assume not until someone tells you otherwise.) Keep pushing the suggestions/requests up the chain of command until you reach someone who has the authority to say "yea". They may still tell you "nay", but at least you'll be getting a decision on the matter instead of an "I can't make this decision, I don't want to bother my boss, so I'll just say no" response.
START WITH SOMETHING SMALL.
In my case, it was getting permission to submit patches to correct bugs - very small, very simple, very non-threatening things. The argument was that we could submit the patches, or go through the pain of developing the same patches again with each new release of the software we were using. That's a good way to get the foot in the door: show that there's a benefit to submitting patches that outweighs any perceived risk. If you can show that you spend X days out of every release cycle generating the same ol' patches again and again, it's an even more convincing argument.
DON'T PUSH TOO HARD.
For some companies, this is a big step to take. Let the folks who make the decisions think about the idea, answer their questions honestly, and be persistent without harassing them every day about the issue. You don't want to have them tell you "no" just so you'll quit bugging them.
BE HAPPY WITH WHAT YOU GET.
I don't mean that when you get the first "no", you should give up. You need to be reasonable in your expectations - IMHO, submitting patches for bug fixes is fairly minor, and the reaction to that request should give you an idea of how receptive your maangement might be towards the idea of more substantial work & contributions.
My employer lets us submit bug fix patches freely for one project, at the developer's discretion. Minor feature additions in the same project require approval, which is generally easy to get. Other projects require management approval for all patches, no matter waht. Some projects that require copyright assignments are still in the "we're considering it" phase, and may never be approved. We've contributed at least one large chunk of original code to a project, and are considering doing it for a couple of others, as well, because while we want the software to have feature X, we don't want to have to maintain feature X. That's a pretty good argument to try if you're trying to get approval to submit a patch that adds a feature or functionality to an existing project :-)
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
I'm also a consultant, working for a not-for-profit, and I added a specific contract clause allowing me to contribute to OSS.
:)
The big code issue for my client was that they wanted explicit ownership of the code. They didn't want partial ownership, or to give me the rights to reuse the code, etc. I wanted the right to reuse what I developed elsewhere. We ended up compromising with a clause that allowed me to contribute any "fixes or improvements" to open source code back to the community. Interestingly, they were quite willing to accept this clause at contract time.
So I actually have an explicit contractual clause that allows me to contribute back. It makes me happy.