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.
Yes, if he is not distributing binaries, you do not have to distribute source code. You are allowed to modify GPL code for your own use without filtering the code back to the community.
Finkployd
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...
the company i work for has a term of employment agreement that i had to sign upon hire. it specifies that the employee is forbidden (except by written arrangement) from participating in activities that conflict or compete with the company's business. Example would be contributing to open source software that competes with your company's product.
these kinds of agreements is probably common practice.
if in doubt, you can ask for permission. if you aren't granted permission, then you have a decision to make.
According to title 17, an employer owns the copyright to "a work prepared by an employee within the scope of his or her employment." I don't know the case law myself, but I wouldn't expect this to be measured by whether you're using the company's computer, any more than I'd expect they would hold copyright to all phone conversations made on company phones.
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?
The work I do is mostly funded by NASA, under scientific grants. Every grant proposal I submit contains the words "All software and intermediate data products will be freely released to the general public" (or minor variations on that sentence). That way I'm actually required to release stuff, and the most restrictive license I can put on it is something like GPL (public domain would also work, of course). Haven't had any problems with management over it.
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.
Calm down, did you even read his post? He was wondering about how to give back to the community without getting in trouble with his company. So he is planning to give back to the community.
read my blog
musings on politics and technol
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.
* you mention that you are currently customising open source software, does this mean that you are legitimately honouring the licenses associated with that software ? if not, then that should be your first step. the choice here is simple: either honour the license, or don't use the software. this may require you to make available your modifications.
* you really need to write up a business case: why is in the companies interest to do this ? will it be "pr" ? will it cost ? will it cause legal (liability) issues ? will others run with the software and turn it into something better (free labour for you) ? does the work required (to package, make available, etc) outweigh the costs ?
You need to answer these questions in an intelligent and reasoned way before someone else (i.e. your engineering manager / etc) is going to allow this to occur.
There was an interesting PerlMonks discussion about a very similar question not too long ago that you might be interested in reading.
Use Ctrl-C instead of ESC in Vim!
It depends on the country and even in the USA the state. Its always best to have this on paper.
My old one with I2IT. Sonix and 3Com basically said
"If you are doing it on your own time and equipment, it doesn't interfere with work and it doesn't involve or relate to company trade secrets or business then fine"
Which meant I had to keep out of Linux ISDN and bridging but that was IMHO fine. I2IT and Sonix were thankfully both companies that understood that they were making a net win out of the whole thing and that having an active tcp stack writer did help debug company code now and then 8)
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.
And, the shell script for Windows is????
Hey, Mom! Is it beer, yet?
First, remember that I have a government job and pretty much can't get fired. [wink]
Secondly, as somebody else noted, there is no default scripting ability in Windows. md5deep was originally developed a module for a Windows incident response tool called the First Responder's Evidence Disk (FRED). We have just obtained permission to make FRED public and will be releasing it soon. The linux/*BSD/OS X versions of md5deep were all ports written by people outside of the USG.
Ironically enough, however, it was easier to write, compile, debug, and test md5deep under Linux than Windows.
And, the shell script for Windows is????
It works just fine under Cygwin.
With the current SCO hub-bub, I think every developer who thinks about submitting code developed at work and every developer accepting new code from outside developers realize that the code you are submitting is the property of the company you work for!
Ultimately its there decisicion, if you feel like doing it without permission to 'Help' the open source community you are actually hurting the project and community almost beyond repair.
Unless you get writen signed off permission from someone who can give permission, 5-7 years from when you submitted the code, your company can still claim ownership to that data. Right now your boss may say "go for it!", 5 years from now, you and him are probably gone and forgotten, yet the company can still sue the project you submitted to because it contains their property.
Please, please if your not sure, don't submit!
When I submitted my Master's thesis, I had to give the Queen in right of the National Librarian the non-exclusive right to reproduce that thesis.