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. Jim -----Original Message----- From: Lawrence Rosen [mailto:[EMAIL PROTECTED] Sent: Friday, March 25, 2005 12:24 PM To: Jim Barnett; 'William A. Rowe, Jr.'; 'Geir Magnusson Jr.' Cc: [EMAIL PROTECTED] Subject: RE: Corporate Contributions Jim, I think you're raising the fear level way too high here. While I can also imagine hypothetical scenarios in which venal ASF folks are locked in the stockade for criminal acts, that isn't likely either. I suggest that we lawyers find ways to educate ASF contributors about their potential obligations to their employers, educate employers about their duty to supervise their own employees, advise everyone of the openness of our code so they can "see for themselves," and otherwise disclaim ASF responsibility. If people still think a CCLA is useful in that environment, fine. Collect those forms as best we can under expectations of honesty by our contributors. If, after all that, some court somewhere finds us liable for past copyright damages or contributory infringement, we'll just appeal. There's a new pro bono open source law firm on the East coast we can turn to for help if necessary. But that's pretty damned unlikely given ASF's heartfelt good faith efforts to educate our world about proper code provenance. /Larry Lawrence Rosen Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 â fax: 707-485-1243 Author of âOpen Source Licensing: Software Freedom and Intellectual Property Lawâ (Prentice Hall 2004) > -----Original Message----- > From: Jim Barnett [mailto:[EMAIL PROTECTED] > Sent: Friday, March 25, 2005 11:48 AM > To: William A. Rowe, Jr.; Geir Magnusson Jr. > Cc: [EMAIL PROTECTED] > Subject: RE: Corporate Contributions > > <snip> > > >First, is the SCO problem - that someone will be able to come and shake > them down after they have made a significant investment of > infrastructure and development around the software we create and > distribute. > > At which point we rip out all the offending code. End of discussion > on that point. There is no means, even via a CCLA, to completely > eliminate that risk. > > <snip> > > Ripping out the offending code mitigates new liability but may not > eliminate the problem either. Anyone licensing the offending code prior > to the "rip out" date, still has a license from ASF purporting to allow > it to continue to modify, distribute and use the offending code. I > suppose ASF could post some form of public announcement advising of the > infringing nature of prior releases, but it is unclear to me whether > that is enough to allow ASF to avoid "contributory infringement" > liability for continued use by existing licensees.
