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."
As I understand it, as far as the copyright law goes, if you create it at work on your companies' computer, the copyright belongs to them.
keep in mind the GPL allows for internal use of modified software without releasing the source code.
autopr0n is like, down and stuff.
The first question that needs clarification in my mind is - Is your company distributing open-source code that they have modified?
If that is the case - then if it is GPL'd code, you need to release it according to the license. If it is a BSDish license that isn't the case.
Probably the best piece of advice - get your company to emit a policy on the subject. You may not like the results, but at least it will be a definitive answer.
Have you compiled your kernel today??
I think Justin Frankel would tell you that you can't ever be sure that you have any creative control over what you are doing on company time.
The only ways to remain certain that you have complete control are to either work on your own or with a small group in a small company and then leave as soon as they get bought out by the big guys.
lysergically yours
Ultimately, anything you've done on company time is owned by the company, and you have no rights to it whatsoever, NDA or no. Your contract may grant or revoke various rights, of course, where not prohibited by law. But I would definitely go in assuming that all that code belongs to the company and you have no right to distribute it without formal written permission.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Because you are doing it on their time, not your own.
Vicarious liability, for one reason. Your employer (in most jurisdictions) is at least partly responsible for your actions whilst you are in their employ, and on their time. It hardly seems fair for them to be expected to assume liability without having the capacity to mitigate it, does it?
And all the disclaimers in the world won't help you if a case can be made for malicious code being deliberately released - your company would still be accountable.
--Ng
I would have thought the best approach is to suggest that you submit the patches so that you won't have to go through the pain of merging your changes in every time you want to get a new version of the software. If you phrase it as something that will help your productivity, I'd have thought they'd be much more likely to agree.
I feel like a fish catching a hook, but I'll reply for a bit. First off, this is off-topic. This story is about someone using opensource software in business services and wondering how to contribute changes/improvements back to the community while keeping his company's IP separated.
Second, open source models for profit are not based on the sale of the software, so since opensource companies don't sell their software, don't assume they aren't profitable. You don't credit Red Hat and Caldera with any development, but they most certainly do contribute and make their money off of both support and the package they sell their OS in. They prepare everything for a user to have a complete OS and that requires many tweaks to everything for uniformity and integration. They also develop and maintain OS updates as patches become available so their users can update their systems.
Your discussion against why opensource software is not better than commercial is only in talking about how gcc is not up to par with commercial compilers, but you haven't proven that point. As a cross-compiler, I'll bet gcc is probably one of, if not the, best out there. I guess it won't compile as well for a P4 as an Intel designed P4 compiler, but those details are tough to notice and not so applicable. Then your argument here trails into how there aren't enough qualified contributors in the opensource world to make competitive software, while I would suggest that there is more qualification in the opensource world. Since you didn't support your argument, I won't support this to save space and at least match the convincing-ness of your argument.
You say that opensource software was not responsible for the internet's success, but open protocols were. The first step was open protocols with clear definitions. The next was software to implement them, which is still largely opensource. Apache, BIND, sendmail are always at the top of the list and I promise if you turned off every Apache, BIND, and sendmail server right now, you wouldn't bother trying to use what's left of the internet.
By the way, how does Netscape's contributions to opensource help them make a profit? I've never felt inclined to buy Netscape's enterprise servers simply because I use Mozilla.
And this document won't be recopied or redistributed by me, as I'm not as willing to make a fool of myself like you have. But then again, I did bother to write this long reply.... oh well.
-N
I've nothing to say here...
Try explaining to a client how you just charged them to add some functionality to something that will be used by others for free. It's great karma, but most suits aren't too interested in karma...
Another problem is that most people are more interested in short-term costs. Look at all the publicly-traded companies that will lay off people in order to boost their stocks in the short-term. The only people that really care about long-terms costs are either people in direct ownership or people with some level of perspective. Most grunts these days are probably figuring they won't be around at a specific company for long (whether it's their choice or the choice of someone else). And the best way to look good quickly is lowering short-term costs...
If all you have are silver bullets, everything looks like a werewolf.
Not in my experience. Some do, some don't. Many people don't even have contracts, but company policies usually exist regarding IP that is produced while employed at said company.
In some cases those restrictions even extend to one's free time. If you work for a company that develops software and decide to write some OSS on your own time, you could very well be putting your job at risk.
The moral: read the fine print before signing and/or going to work someplace.
if you were my employee, and you wasted your time writing 'md5deep', you'd be fired. this is a 5 minutes shell script.
md5deep, reimplemented in shell, for your benefit. not tested, i'm sure there are some bugs. yes, it could use refinement, but this is a one minute job.
recursion:
$ find . -type f | xargs md5sum
time estimation:
#on my machine i get about 40 megs per second
#using md5sum (openssl is faster)
echo "`du -sk | cut -f1` / 40000" | bc