Open Source Developer's Agreement
ajv writes: "We've just released our open source developer's agreement. The OSDA allows companies or employees to negotiate into their employment contracts the certainty of owning IP they develop under clear guidelines. This will help all the people out there who develop open source software but are afraid to release it, or more likely, are afraid their boss will react and ask for it to be taken down or ask for a cut of the (non-existent) action. Get it on the main Web site, or on SourceForge."
You have a good point, but if you were a programmer/developer/coder of some sort, you have to sign a NDA, which basically prohibits you from doing any development at all outside of your work environment, and if you do, it belongs to them. That means that the perl scripts I write at home for my website belong to my employer. That is the biggest problem and what the main focus of this documentation is about. There are people that want to work on open source projects at their job, but unless it somehow benefits their employer I don't think it's a good idea.
And trust me, the more people try and get things like this for open source, the more that stubborn CTOs are going to resist it in favour of the latest technology in Computer Weekly.
Managers will always choose the products that they percieve their peers would use or think is cool, and the companies that give them the most freebies. Never underestimate the power of a bad product, and a company with money to take your boss to a nice lunch and a game of golf.
Mas vale cholo, que mal acompañado.
And if you think an employer would never dream of taking ownership of an employee's off-hours work, just ask Evan Brown what he thinks of the idea.
--
Fuck the system? Nah, you might catch something.
You have a good point, but if you were a programmer/developer/coder of some sort, you have to sign a NDA, which basically prohibits you from doing any development at all outside of your work environment, and if you do, it belongs to them
Maybe the one you signed. I've signed a few NDA's and gone onto projects covered by NDA, but all they said was that I couldn't talk about very clearly named specifics: a product idea, the purpose of a project, the composition of the team, etc. Wow. If you signed anything that says your time is not your own, I suggest renegotiating your contract or getting out while the getting's good.
I've finally had it: until slashdot gets article moderation, I am not coming back.
A few years ago, friends and i had started building an OS from scratch. Dubbed Pandora, we have a kernel that boots more machines than current Darwin can (you guessed it: PowerPC Macs).
I was responsible for the UI part (I claim no credits to the kernel, which also has a MacsBug-like debuger).
When I started working for my current employer (which also supports Linux for it's commercial apps), I wanted to make sure that my UI project ("Moira") was safe from any corporate entanglement. I had them sign a "copyright disclamer" wich specifically specifies that my employer disclaims any copyrights and interest in the project, thus protecting it.
On the other hand, this only covers this project, and I must ensure anything else doesn't go against the company's NDA (which I signed).
Both parties therefore are protected in what I feel is a mutually equitable agreement.
Karma karma karma karma karmeleon: it comes and goes, it comes and goes.
If this is about code written on company time, I can't see how it can be justified that the developer owns the IP.
However, if the software is being developed outside of the employer, on a machine not owned by the employer, with software not owned by the employer, then I could see how this might be useful. There are quite a few companies out there that have policies stating that any software developed by an employee is IP of the company. Personally, I have worked under three different policies:
While I was in the USAF, I took a part-time job with Computer City, a CompUSA clone owned by Tandy the parent company of Radio Shaft, to make ends meet. Computer City required employees to sign an agreement signing over IP rights to Tandy for anything developed while a Computer City employee. I explained to the store manager that I couldn't sign the agreement for 2 reasons: 1) I had philosophical problems with the agreement. 2) Tandy would have a few problems claiming IP rights on software developed for the Air Force, especially when it was classified as Top Secret. The manager waived the agreement, and I was able to continue working for the company without it.
My next job was with a bank that had the same policy as Tandy. As a condition of my employment, I demanded a signed waiver stating that the policy would not apply to me. I basically told them that unless I maintained IP rights for anything I developed on my own time, I would not work for them. They had no problem with with waiving the agreement, and I got it in writing.
My current employer has it written in the corporate policy that employees own IP rights to anything written on the employees time. It is also in the employment contract. My employer is enlightened enough to know that people have lives outside of the company, and has acknowledged it.
Basically it comes down to how much you want to work for a particular company. If it is important enough to you, demand you IP rights in writing, and be prepared to refuse to work for them unless you get them.
But this goes further than that. It explicitly codifies what such things are, protecting the coder. Furthermore, there's a whole 'nother aspect to this: the company that recycles Free (as in FSF) anf Open Source software in the products it produces.
Where I work we aggregate a great deal of code with Free software (specifically, major portions pf Red Hat [GNU/]Linux). Sometimes we extend GPL code (and will have to release our changes when we ship product). We've actually had RMS here to address our developers on the GPL and sensitize them to the fact that we take complience with it seriously. But, once you start using the fruits of the open and free sofware communuties, even if you ensure GPL complience, there's somewhat of a moral pressure to give something back, i.e. release your own original code as GPL, or otherwise open.
With this in mind, I've been striving for us to take the position that code we develop is either strategic to a product or product line, or not. If not, I argue that it should be GPL for two reasons: First, it helps make us good free and open software community corporate citizens. Second, it often represents overhead code that doesn't generate direct revenue through licensing, but requires support nevertheless. A community of people who can also use and extend it, is therefore a benefit. Sometimes we produce code that is stillborn: it would have to be released under the GPL if we distributed binaries, but we have decided not to make it part of a product. Why let such code rot? Why not give it away, in the hopes it might find a home?
Often, other than legal GPL complience, the effort to do these things is not justified by the company. an appropriate OSDA agreement would empower employees who feel this way, to release such code themselves, without fear of reprisials. That can only be a good thing.
You could've hired me.