Re: Professional Employees and Works for Hire

This came up from an incidental issue about a month ago. I have been told that if I wish to continue being employed, I cannot post code.

This is extremely bad form on the part of your employer. Companies that implement this type of policy are shooting themselves in the foot, unfortunately they can do a lot of damage to others, including free software organizations, in the process.

I'm not a lawyer, but it seems this all pretty much comes down to the agreement that was signed. A brief reference on the issue is available here. From the part that describes what a 'Work for hire' is:

Section 101 of the U.S. copyright law defines "work for hire" as follows:

a work prepared by an employee within the scope of his or her employment; or,

a work specially ordered or commissioned for use as: a contribution to a collective work, a part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, a sound recording, or an atlas; or,

if the parties expressly agree in a written instrument signed by them that the work shall be considered a work made for hire.

Assuming this is still relevant, Number 3 is the problem. I haven't heard of anything that specifically says employers own all the rights to all work done by professional employees by default but if the contract signed says so, there doesn't seem to be a whole lot you can do.

Excellent post though. This is an issue that has important consequences for free software and should be receiving far more attention than it has been.

Update: Here's another good article on the subject.

Comment on Re: Professional Employees and Works for Hire

Replies are listed 'Best First'.
Re: Re: Professional Employees and Works for Hire by shotgunefx (Parson) on Mar 20, 2002 at 19:02 UTC
You're company doesn't have to be right to sue you and they usually have deeper pockets. Who's to say if the work was done before or after work hours. If you worked at a network company and then at home "invented" some network device, your employer would have a good chance at winning a suit regardless of merit. -Lee "To be civilized is to deny one's nature."	[reply]
Re: Re: Re: Professional Employees and Works for Hire by cjf (Parson) on Mar 20, 2002 at 19:12 UTC
Very true. Unfortunately this is a reality of most legal systems. It's hard to fight against those with more money, even if you are in the right. Hopefully the onus is on the employer to prove you created it during work hours, either way it's still a very difficult situation to be in.	[reply]
Re: Re: Professional Employees and Works for Hire by csh (Novice) on Jan 27, 2004 at 03:32 UTC
One problem with all of this is the impossibility of keeping your employer constantly updated on what you are doing. I have written several programs in a single day, and it could be a bit hard to keep them updated all the time on what I was doing. The whole idea is nuts. Aside: Everyone should do is check their state's coercion laws. In some states, being forced to sign a contract to get a job is considered duress. Dealing with code sharing at work Almost all of my employment contracts have limited the company's IP claims to work I did specifically for them. So far no company has contested work I did on their equipment and time. Of course, I've always told them what I was doing. A lot of companies are far too lax about this. I often asked for a more formal arrangement than my employer did. I have both taken my own code and used it at work, and used code from work elsewhere. I documented what I did, made sure my company knew, and developed a few habits along the way that seem to help. The first conflict I had was because I worked on classified systems, and needed to move code in and out. I learned to sanitize code, and move useful code without giving away proprietary information. It had to pass a review before leaving. Bringing code in was usually pretty easy. I can't say enough how writing clean and modular code makes this whole process much easier. Never keep what you are doing quiet. While I have had to take this approach before, it is far better to document what you do and make sure people know it. Don't be ambiguous: be explicit about what you are doing and what you intend to do, and what rights you want them to have. For any code that I gave my employer, I made sure it was copyrighted and also had a license granting them unrestricted use. This is very important. You really can screw things up for your employer if you are ambiguous about their rights to your work. So far, most employers I've had were happy to find I already had code which could do the job. Unfortunately many of them are way to careless with copyrighted information. In some ways I have had the opposite problem from what Tilly had. Everyone should also spend some time researching ideas like "shop rights", where you own all code you write, regardless of employment, and grant your employer full rights to use the code. IMHO, it is very rare that an employer should find this unacceptable. It gives them all the rights they need, and you retain your natural right to what you create. Obviously there are issues regarding internal/secret/patented information, but reasonable people can work that out.	[reply]


Think about Loose Coupling
	PerlMonks