Properly Contributing to Open Source While on Company Time? 400
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."
Simply put: I don't. (Score:5, Interesting)
love? (Score:2, Interesting)
What does he mean by "love"? Does he have a choice?
Why Open Source is bad for you (Score:3, Interesting)
Open Source Doesn't Make Economic Sense For Most
The open source organization has presented a few cases that supposedly explain why OS works economically. However, if you examine the cases objectively you will find that the cases are flimsy and non-specific and do not address any specific concerns. They attempt to bolster their case by pointing out a few "successes", among which Caldera and Red Hat are displayed as shining examples.
The real economic question of the OS model is how is money made, and who is making the money. Who is being rewarded financially for the enormous development effort? The open source initiative claims that there are at least four different models that allow someone to reap rewards. Oddly, it is not mentioned that it is not necessarily the people who did the development work that gain financially.
The four primary business cases mentioned by OS proponents are "Selling Support", "Loss Leader", "Widget Frosting" and "Accessorizing."
The first case proposes that money can be made via selling support for the free software product. This is by far the strongest case and is proven to work, for a few small companies. The two companies that are shown as positive examples of this business model are Red Hat and Caldera, who distribute and support the Linux operating system. What is never mentioned is that neither of these two companies has contributed significantly in relative terms to the Linux development process. Its important to note that using this business model, the people that make the money are usually not the ones who have invested in the development process. So much for the strongest case.
The second case is based on the idea that you give away a product as open source so you can make money selling a closed source program. This also can work, but it should be noted that the money is being made off the closed source product and not off of the open source. An example of this model would be Netscape, who gives away the source code of their client browser so the OS community can do development, but keeps their "cash cow" products completely closed. Obviously, this case may only work if you have a software product that lends itself to this sort of "give away the razor and make money on the blades" system. The truth is that the vast majority of software is monolithic. So much for the loss leader case.
The third case, "Widget Frosting", sounds completely practical. The premise that hardware makers produce open source software so that the OS development community will work for free to produce better drivers and interface tools for their hardware products. It sounds great on the surface, especially for the company that produces the hardware: they get free drivers and do not have to pay for expensive developers. The OS community wins by getting presumably stable drivers and tools. What is not mentioned is the reason hardware makers usually don?t do this is because they do not want to reveal trade secrets regarding their hardware design. Production of efficient drivers requires an intimate knowledge of the hardware the driver is for. It is almost always the case that it is in the hardware developers? best interest to keep their hardware secrets close to home. This also brings up the question of why isn?t hardware "open"? So much for the frosting case.
The final case, "Accessorizing", is similar to the first, but throws in the idea of selling books and complete systems with the open source software, and other accessories as well. It is obvious that selling books qualifies as support, and that it really belongs in the first case. The idea of selling computer systems, T-Shirts, dolls, again begs the question: "Who is making the money?" As with the first case, it is not necessarily the people who have done the development work. Additionally, the question of how much money can be made selling books, t-shirts, mugs, etc, is never answered. O?Reilly Associates is frequent
Re:Simply put: I DO (Score:4, Interesting)
Forgiveness easier to get than permission? (Score:5, Interesting)
This makes sense when you think about it from their risk-averse perspective: releasing even small pieces of otherwise-useless specialized code is all downside and no upside.
On the plus side you might might improve goodwill with a small number of open source developers. But on the minus side you might be exposing the company to liability, accidentally revealing sensitive information, or inadvertantly helping your competitors. Plus, management always has to worry about shareholders second-guessing them -- possibly resulting in a shareholder lawsuit -- if the IP you give away is later perceived to have been very valuable.
Given all this, a dangerous but more pragmatic idea might be to just go ahead and contribute at least the small stuff like your patches and bugfixes. As long as you have no official policy forbidding this you can point out that it's just the standard way things are done when working with open source tools.
Let me be clear that I am not actually advising anyone to do this. More just.. thinking aloud.
A cautionary tale (Score:5, Interesting)
The moral of the story: get the company policies in writing before you start making changes to an open source package.
Re:Simply put: I DO (Score:3, Interesting)
Do the Right Thing (Score:5, Interesting)
First off, do they realize what value they are already getting from open source, or was that snuck in the door? The former would make life easier (for everyone, since more PHBs will realize the value of OSS).
One thing you don't want to do is to sneak behind your boss' backs and contribute what is unarguably company IP back to OSS without their permission. This can cause headaches down the road that could have been avoided.
Setting criteria for contributing back to OSS that you are enhancing is much easier than releasing OSS in the first place (IMO), and, yes, I have worked for enlightened companies that blended both well. It all depends on what your company does (industry focus) and where it values its IP. Generally though, if you have just enhanced OSS, returning those enhancements should be a no-brainer (and required by some OSS licenses). Again, that is really a no-brainer only if management knew you were using OSS in the first place.
For major enhancements, try to value it from your company perspective. If you were (eg) a video codec software company and had just made changes to a BSD video codec that gets 10x compression improvement with no quality loss, is it really worth your while to release that back immediately? I know some will argue that all software must be free, but how many of them are gainfully employed based solely on the free software that they develop (read: I don't think the model for just selling support sustains itself). IOW this isn't intended to start religious wars, just to make you think about what IP really has value to your company, and what you should be more readily willing to share.
Completely new software that you might want to release under and OSS license is similar to the above. First off, if you company isn't OSS aware, make them. Then discuss what things you don't want to release for core IP reasons, and what is good to release.
Remember that just releasing code doesn't raise the jollies of most corporate types. It usually has to have a purpose, and company brand awareness is a large part of that. Making or enhancing OSS software can be very good guerilla marketing for a company. It's perhaps not the same as dot.bomb hype levels, but it still has value for brand awareness, recruiting, etc.
Re:Simply put: I don't. (Score:5, Interesting)
I personally do not have a moral or ethical quandary with opening up my development process, busting a hole in the firewall to allow CVS or at least SSH access, and making wholesale changes to open source projects on company time. I just don't want to be the subject of a 'Your Rights Online' story here.
Re:Copyright (Score:5, Interesting)
What you state is true most of the time, but not all, because of company policy.
And...I hate it.
They always pull the old "we own the computer, therefore" line. It's the same reason given for why they feel justified in reading your emails and such. Well, they own the phones, too, but they cannot legally record your calls without notice.
A friend and I were talking about this a while back. We were allowed to play games at work from time to time, and so sometimes I did. He teased me that I played games on company time. Technically, that can't be said...because we were salaried employees. An extreme analogy would be: make me an hourly employee, and put a timeclock on my desk. I might clock-in and clock-out at intervals of only 10 seconds here and 2 minutes there. A salary employee is essentially doing that, but without the physical timeclock on the desk...just as a mental exercise. Therefore, a salary employee never plays games on company time... and, possibly, might always be free to develop his own ideas which might still belong to him... aside from the fact that he used the company-owned PC at the time.
I'd better check with the carpenters that built my house... it's possible that they own the house, and not me, because they owned the hammers and saws used to build it!
Use Channels (Score:1, Interesting)
Careful! (Score:3, Interesting)
So if anyone wonders why nothing good ever gets done from our company, this is why.
OpenSource on Company Time (Score:2, Interesting)
It depends on your company. You might of signed a form that states that the company owns whatever you write, even if it is job related or not. Depends on the company, usually the larger companies are more draconian about it.
On the reverse side, my company does not require any such statement to be signed. So, technically, I own all my code. Should make any layoffs fun around here.
'What? No severance package? I will make you a deal on my code. Either that or you remove it.'
It is an extream example but entirely possible to happen.
Re:It makes your hair fall out. (Score:3, Interesting)
Decreasing costs and support load is generally how I earn my bonuses. I reduced our corporate IT costs by over $600,000 per annum with OSS over the course of six years. With the promotions and correspondingly larger salary I recieve, I've been able to buy two new cars, a house, and build a gaming network in my basement. All from what you claim is "working for free".
Your greed has blinded you to the enormous benefits of giving stuff away. To answer your question, who is getting the real value from Open Source? I reply: Everybody involved! Except greedy proprietary software vendors, of course. And they've never done anything for me that I didn't have to pay for, so I owe them nothing. I donate code and money to OSS, because it is to my benefit to do so.
Get it in writing (Score:3, Interesting)
First let me say that there is a distinction between "what is right" and "what is legal". Many things that are not legal are right, and vice versa. I'm not interested in getting into a lot of "but that's not right!" arguments; I'm simply relating what the legal realities are as I understand them.
The only way to really be safe is to write down exactly what it is that you intend to contribute and get an officer of your company (or other superior who clearly has the authority to commit the company) to sign off acknowledging that the company will make no claims against your contribution. Stick to what has been agreed to, and get written addendums if there is "scope creep" on your open source project.
If they won't sign off in writing, you can assume that they will take action of some kind against you if you decide to do it anyway. As my lawyer used to say "contracts aren't for when people are happy with one another". Might be a good idea to look at other options (of employment, if you're committed is to your OSS project).
I would also note that unlike some wildly misguided people I've heard recently, you cannot simply take something you don't own (in the legal sense), release it with a GPL notice on top, and be free and clear legally. Sure, that code can't be "called back", but you (and people who use your code assuming you had the right to apply the GPL to that work) might very well find yourself in court. Ownership of the code (and thus who has the right to determine the license) is determined by the contract you entered into, and the courts will decide your fate based on that.
Be aware that some employment contracts state things to the effect that anything you do "in the field" can be claimed by your employer. Thus, just because your contribution is done on your own time with your own equipment, you still could be liable for action. Know exactly what your employment contract says (hopefully you did that before you signed it). Have a laywer (your own laywer) explain it to you if you aren't very familiar with contract language.
Also note that simply not signing an IP agreement does not automatically absolve you of its terms. Look for other employment paperwork that says things like "by accepting employment you implicitly agree to all our required employment contracts". I've definately seen people bit hard by this. If your employer has an IP agreement, then negotiate the terms you want and sign that so that all is tidy and legal. Again, consult your own lawyer to know exactly where you stand.
Know your rights under state law. Different states have wildly different interpretations of the strength of employment agreements. Contract language which would bind you up in one state might very well be tossed out as onerous in another. Consult a lawyer.
You do not want to litigate over this; you want to avoid putting yourself in that position. Even if you win, it's generally very expensive, annoying, frustrating and you'll often as not loose the job as a result. Don't sue "on principle" unless you know you have enough money, time, etc., to survive the process (including the possibility of loosing...no matter how strong you think your case is, the legal world is bizzarro world, and outcomes are not always deterministic). Special Fact - generally, if you sue your company (e.g. to claim ownership), and they decide to countersue you (say, for breach of contract), you won't be able to drop your suit (even if you run out of money), unless the other party agrees to it. Hint - they won't unless you back down.
Lastly...do not simply take your managers verbal word that there will be no problems. Get it in writing. There is a doctrine of "verbal contracts" (I suppose "implied authority" also plays here) under the law, but they are difficult to make stick, especially if the other side is determined to invalidate it. OTOH, "Paper has a perfect memory", as one of my old biz partners used to say.
N.B. - I can speak only for the U.S. There are different subtleties elsewhere...
N.N.B. - IANAL, nor do I want to be...
Re:Simply put: I don't. (Score:5, Interesting)
As a fellow consultant, I have a few questions for you:
1) Do your clients require that *you* wrote it, or that the thingamajig works?
2) Do your clients mind if sections of their codebase that aren't part of the core deliverable (libraries and the like) improve with time without further investment on their part?
3) Do you read the licenses for the stuff that you develop in proprietary software to ensure that "contamination" is not happening there, too? Some of the EULAs for compilers and IDEs can be quite frightening when you actually READ them.
I use *alot* of GPL and LGPL stuff in my work. The key is to ensure that the GPL stuff is called as an external process, (so it's effectively its own program) and the LGPL stuff sits in its own, separate file.
I contribute changes and improvements constantly.
Re:Copyright (Score:5, Interesting)
If you are an actual employee, paid a salary or paid hourly where they withhold taxes and social security and what not, then any work done within the reasonable scope of your employment is considered work made for hire, thus the copyright vests in the employer rather than in you.
However, in almost every other circumstance, the copyright vests in you and must be explicitly transferred. This means that if you're a consultant, you own the work. Or if you're paid by the job, you own the work. Or if the work isn't reasonably within the scope of your employment, you own the work.
Some examples:
You are a janitor at the local school. While at work, you go into the computer lab and write the next Microsoft Windows. Who owns the work? You do. Although done on your employer's time and facilities, it was not within the scope of your employment. (Note however that the school can fire you and sue for misuse of facilities.)
A local ISP pays you $1000 to write a spam filter. Who owns it? You do. You were not an employee of the ISP.
A local ISP pays you $1000 to write a spam filter. You sign a contract which says, "I agree to write a spam filter and the copyrights belong to the ISP." Who owns it? You do. You can't assign rights to a work that hasn't yet been created.
A local ISP pays you $1000 to write a spam filter. After writing the software you sign a contract which says, "I assign the rights to this software to the ISP." Who owns it? The ISP does. You did first, and then you assigned the rights.
Here's a tricky one:
You work (as an employee) for a company writing accounting software. You sign an employment contract which says, "All software I write while employed by the company belongs to the company." In your spare time you write a spam filter. Who owns it? You do. A court would find that the actual fact was that accounting software was the scope of your employment. The only software that's work made for hire (whose copyrights vest in the employer) is the software written within the scope of your employment. And, as previously mentioned, you can't assign copyrights for something you havn't written yet.
What if you wrote the next Lotus 123? Then the company would own it. A spreadsheet is reasonably accounting software which was within your actual scope of employment.
Here's a trickier one:
You work (as an employee) for a company writing accounting software. You sign an employment contract which says, "I will assign rights to the company to all software I write while employed." In your spare time you write a spam filter. Who owns it? You do. That's right, you do. BUT, you have a valid contract with your company which compells you to write a document which says, "I assign the rights to this software to the company." If you fail to do so, you are in breach of contract.
What about when the contract said, "All software I write while employed by the company belongs to the company?" Are you in breach of contract if you don't assign the rights? You are not. There was no requirement to assign the rights, on an element stating that the rights belong to the company. That element in the contract is contrary to the governing law. If your contract allows it (most do), that element would be severed from the contract. Otherwise, the entire contract would be voided.
Re:Simply put: I don't. (Score:3, Interesting)
You don't read much Dilbert, do you? ;)
Everything you say makes sense and is logical, but the problem is that the world is messed up. We're in a world where everyone wants to take, but very few want to give (or give back).
Just look at some of the things that are happening in the world today. Crazy patents. Companies using scare-tactics on their customers. I'm not saying it's all bad, but chances are that you will have a hard time convincing someone with tunnel-vision how contributing helps them out.
Me skeptical? Yeah, I won't argue that. I used to be a very optimistic guy, but having to work has shown me that most people are just selfish. If you can find place where people really want to work together, cherish that. :)
(the worst part is that I've adopted this attitude, and I'm still in my 20's!)
Re:Simply put: I DO (Score:1, Interesting)
Hairy Problem; Get It In Writing (Score:3, Interesting)
Even code you write on your own time -- you don't want the company to later be able to claim that you used their "intellectual property" -- your general knowledge of projects at work -- while writing that code. Perhaps I'm just paranoid, but I make sure to either get my free software activities acknowledged in writing before I accept a job, or not work on free projects that may be related to the stuff I do for hire.
But most important, don't do it without actual legally binding authorisation from your employer (not just your boss). It's critically important that all the free software out there really is safe for everyone to use.
Re:Simply put: I don't. (Score:3, Interesting)
I *always* mention to the client that I use "free tools everywhere possible" to make the job go faster, reduce development costs and enhance stability. When they ask about "ownership", I calmly explain to them that being "Open Source" means that they own a perpetual right to use said "tools", and that I'm careful to use the tools in such a way as to not contaminate their paid-for sources.
When given the option of paying more for something that doesn't really get them anything, I've never had anybody turn down the open tools.
You have?
Giving back to OSS (Score:1, Interesting)
I talked it over with my boss. We had some graphing stuff we wanted to do, doing it by hand would have been possible but taken quite some time, so we saved thousands of $ of development time by grabbing an open source library.
I made some changes to let it display certain things in a better way to meet our requirements. Other people had been asking for the same thing, so I posted code and explanation to the forums of those projects.
Not really any different from contributing in a discussion in for instance Microsoft Developer Network. (Except without the eveel!!!