|
Nathan, >I think there should be no distinction between employee and >independent contractor when it comes to copyrights. In the absence of an >agreement to the contrary, the copyright should go to the literal author - >whoever that may be. While I appreciate where you are coming from, I think it would be next to impossible to implement. It could only be practical in the case of a one-man shop with a project developed from scratch that doesn't interface with other components. As soon as you have a project team, who owns what parts? If an experienced developer designs things which are assigned to junior programmers who otherwise wouldn't have a clue, who has the copyright? When your code won't run without service program routines the company already had before you started, what are you going to do? Avoid calling anything you didn't write so your code will run complete on its own? Let's face it: there is a lot more maintenance of existing applications then development of new stand-alone applications. It is totally impractical to say Billy Bob owns this subroutine, Sally Sue owns this IF block, and Johnny owns the design of this DB. Attrition happens; especially in this industry. When you start modifying someone else's code, what do you suggest the new programmer owns? >This change alone, would release a flood of creativity >unparalleled in recent history. And a flood of quibbling over who owns what unparalleled in even this overly litigious society. >Also, consider >that programmers would only have rights to the expression within the modules >or components they were the original author of. Which leads to: "I don't want to work on that existing code. It needs to be rewritten, sir, from scratch." >Douglas Handy posed a scenario of a failed commercial project. Should the >employees give up their salaries? I meant it as a rhetorical question, not a proposal. I do *not* think the employee should be financially liable. My point was that employees *aren't* liable in the case of a commercial failure.. >Based >on my experience, the underlying reason most projects fail is because >individuals don't have an ownership stake in the results. "But you can't scrap this project now! Just give me two more months (again). I'm sure I can finish it this time!" "I refuse to be transferred to that project. I didn't write it." "Joe can't help now! If he does, I won't own the whole thing." And the list goes on. It would be a management nightmare. >To be realistic, it may take another 75 years for copyright law to change. >If change is going to occur, its going to have to be in the individual >employment agreements and contracts people enter into. The laws don't have to change for you to negotiate rights. An IC can chose to transfer the rights, and a client should be smart enough to spell out the ownership in writing before hiring a contractor. Likewise, I don't see it as impossible for an employee to negotiate (in writing) the transfer of copyright ownership in specific cases. But in general I think that would be hard to segregate. An example of where I could see it working is in utility/tool type work, or creation of service programs, etc. Something that stands alone on its own merit, and doesn't have a prerequisite of other code. For example, the freeware utility WRKDBF developed by Bill Reger at Levitz Furniture. I don't know who owns the copyright -- Bill or his employer -- but it is an example of something I could see trying to negotiate with an employer. Doug +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.