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."
Remember that open-source is not necessarily free-as-in-beer. Your company can charge for the source code and the binaries if it wants, it just needs to use an open-source license (insert heavily-compressed flamewar here).
Also you can make quite clear that you will only support YOUR version of the product and that if they choose to modify the source they're on their own.
If you're just talking about donating code snippets, well, then you need someone with more experience in that than I.
Zaphod B
When duplication is outlawed, only outlaws will have
Not always. As an employee of the US Government, my work is not eligible for copyright protection in accordance with 17 USC 105.
Thus, the programs I've written and been allowed to distribute are available as public domain. You can check out my programs for computer forensics and system administration, foremost, and md5deep, on Sourceforge.
gets asked a lot around here. And the answer is always the same: Talk to your legal department. There isn't anything else you can do.
When we're modifying open source programs for use in our environment, we try to come up with two different types of patches; patches that enhance the package wether they be with new features or bug fixes, and patches that are only there to support local conventions and tools. We rarely submit the local patches back to the development team of the package, but if we feel that the enhancement types of patches will help out the project, we'll submit them back.
Donald Roeber
Generating 2048 Bits of Randomness...
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?
This is not actually true of the GPL.
If they are making programs for internal use then they are obligated to release nothing.
If they are distributing the code to another party, then they have to make the source available to that party.
They GPL never says that they have to release the code to the public, however; the party receiving the above mentioned code would have the right to release it to the public under the GPL.
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.
We want to make sure we get clarification about what is or is not covered by our NDAs
IANAL but here goes...
This one is kind of obvious to me, but an NDA is an Agreement between two or more companies that basically says 'I'll show you mine if you show me yours' and legally binds each party not to tell anyone else about it. I try to avoid these because I'm always paranoid that the other company will tell me something I'm already working on and later try to stake a claim on what's mine.
Simple answer to your question: Before you send ANY code into the public domain get your boss to sign off on EXACTLY what you are releasing. Otherwise, even if you get the OK you could be in hot water later if your boss backs out on you.
All your base are belong to us!
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.
This only works so well though. Many companies have small print that they basically own your brain while you work for them. Even IBM, which pays people to work on open source code has some paperwork for you if you want to work on your own projects. I believe it's fairly straightforward as long as you're not making money off something that looks a lot like your job but you Do have to fill it out. It does make sense from the company's perspective - they don't want to pay you to work on some propriatary code and then have you go home and use the expertise they paid you to gain to apply the same features to a free product that's their competition. Sadly I don't know the actual process one has to go through so I can't be of any help to whoever asked this.
Clauses about owning what you do on your own time don't usually hold up in court, and I've yet to run into a client who wasn't willing to stroke that section out of the contract when I explain why it's an issue for me and my career.
The two places I've worked that leveraged OSS were good about posting their enhancements, one works directly with the developers for a key OSS product they use. (It's been a big benefit to both -- the OSS developer has been adding features they need, and they've been providing him a "real life" debug environment with a highly skilled team and solid feedback.)
I've always specifically steered clients away from GPL libraries, as their business IP isn't worth risking when there are LGPL (or equivalent) libraries that do the same job. Rah-rahs for the GPL and all that, but banks and financial companies aren't even going to consider putting their internal processing systems out as GPL software, and don't qualify for internal-use-only exceptions in most cases.
I do not fail; I succeed at finding out what does not work.