On Fri, 2005-03-25 at 13:49 -0800, Jim Barnett wrote: > It was not my intent to sow any "fear" but rather to identify and discuss the > IP risks associated with accepting contributions, understand ASF's current > methods of minimizing those risks, and understand the groups' perceptions > about how ASF would respond to a third party claim. Part of my reason for > participating in this thread is to assess the risks and benefits of ASF > project participation, contribution (XMLBeans, Beehive, etc.) and use of ASF > code for my employer. Accordingly, these issues are important to us. > > From an IP ownership perspective, where something that is owned by an > employer (by state law, federal law, contract, or otherwise), is contributed > to an ASF project by an employee without the employer's authorization, I do > not believe that ASF's "openness" and transparency helps that much. It is > not a standalone defense to an infringement claim. It would help establish a > laches or statute of limitations defense, an implied authority argument, or > something novel predicated on the employer's negligence in managing its > employees. > I also agree that ASF should disclaim liability to the fullest extent > possible. Disclaimers can be very effective at limiting exposure between the > parties where they are included in a contract. General disclaimers published > on a website, however, are not as effective at limiting exposure. What duty > does a non-participant third party have to read anything published on an > organization's website or to investigate transparent OSS projects for > unauthorized contributions by their employees? I think establishing either > actual or constructive notice or duty to investigate could be difficult. > None of the issues we've been discussing contemplate or require any > criminality by venal contributors. Each is just as likely to arise through > completely innocent, accidental contributions of an employer's IP, as by > subterfuge. In a commercial licensing context (which I am admittedly much > more at home with), the parties usually address in their contract what > happens if an adverse third party claim arises with respect to licensed > technology. There is a mechanism allowing the licensor to attempt to replace > the offending code, and failing that, terminate the license. OSS licenses > don't work that way since there are no indemnities and no express remedies. > I am not saying that ASF shouldn't educate prospective project participants, > publicize the "openness" of ASF projects, or highlight employer > responsibility to oversee employees' activities. It should. Reasonable > minds can differ, however, as to how much protection "openness" and public > education buys ASF. I happen to disagree that it takes a far fetched > hypothetical involving criminal actors to legitimize the issues I've raised. > > I really liked Costin's earlier suggestion about an ASF FAQ on the IP > cleanliness issues and would welcome the chance to participate with the group > in developing it.
i'm grateful that jim willing to discuss the whole spectrum of possibilities. it's important to get these issues out in the open and come up with some solutions. <IANAL> i (for example) am exposed to criminal liability (under UK copyright law) by my activities as a release manager. if a US contributor (for example) makes a innocent mistake about the current US law, then i could be charged and (if found guilty) might be faced with sequestration of my assets plus a long gaol sentence. the key to UK law is acting ethically. my only defence would be that i acted in good faith. if ASF contributors act ethically, then i have nothing to fear. if they do not, then CCLAs will not save me. the main point i would like to make is that the CCLA is a solution that though it may prove effective under US law, may prove ineffective under UK law (for example). different solutions may well be needed where employment law differs. it's interesting to note that there is a hint that the situation under US law may vary from state to state. employers in jurisdictions where the CCLA is (for practical purposes) unenforceable or unpredictable (legally) are very likely to take the attitude that the expense (of seeking legal opinion) and the risk (of unforeseen legal consequences) are too great (given no commercial reward). jim's previous master-servant example is very interesting and indicates where UK and US law seem to have diverged. it seems that US employment law arises from agency and contractual relationships. though it is possible to be an agent of a company (or individual), this relationship is not addressed by UK employment law. UK employment law arises from more equitable employment regulations for servants. as a servant, i have to be on my employers premises as specified, keep my nose clean and do what i'm told. i don't have the same duties to act in my employers best interests as an agent would. UK employment contracts are governed by employment statue rather than contract statue (as would agency). as an agent, if i do wrong, i would expect to be sued. as a servant, i would expect to be faced with either the sack or criminal charges. there are also no laws about trade secrets here. it's often said that UK employment contracts are not enforceable: this is incorrect. it's just that they are enforceable under employment statue rather than contract statue. when you are employed it is now very difficult to have any other relationships with your employer. all such contracts are viewed through the employment statue lens. the legal rights granted by the CCLA to an employee are therefore difficult to predict. i'm still a little confused about how the legal redress theory would work when faced with a disputed contribution by an employed UK committer. how would the ASF or downstream users go about seeking redress (using a signed CCLA) if a UK court reassigns (under UK employment law) ownership of source copyright from that employee to an employer? </IANAL> - robert --------------------------------------------------------------------- DISCLAIMER: Discussions on this list are informational and educational only, are not privileged and do not constitute legal advice. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
