www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Goossen <goos...@roguewave.com>
Subject RE: Corporate Contributions
Date Fri, 25 Mar 2005 22:09:28 GMT
If the company is supporting the project, they certainly should sign a CCLA.
If the company is not supporting the project, I would expect a high
percentage to resist signing it.  In the best case, the company's legal
department would put an extremely low priority on reviewing and approving a
CCLA.  This will result in either the individual not contributing or a
contribution in wilfull violation of the policy of having CCLAs in place for
all employed persons.  

Given this, it would seem preferable, from ASF's perspective, to provide as
much information as is practicable about work for hire, etc. and then rely
on the individual's representation in the ICLA that they are legally
entitled to grant the license together with the disclaimer of warranty and
limitation of liability in the Apache License.

Of course this does not provide much comfort to users of ASF code, many of
whom, unlike ASF, may be using the code for a commercial purpose.  

-----Original Message-----
From: Jim Barnett [mailto:jimb@bea.com] 
Sent: Friday, March 25, 2005 2:49 PM
To: lrosen@rosenlaw.com; William A. Rowe, Jr.; Geir Magnusson Jr.
Cc: legal-discuss@apache.org
Subject: RE: Corporate Contributions
Importance: High

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

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

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.


-----Original Message-----
From: Lawrence Rosen [mailto:lrosen@rosenlaw.com] 
Sent: Friday, March 25, 2005 12:24 PM
To: Jim Barnett; 'William A. Rowe, Jr.'; 'Geir Magnusson Jr.'
Cc: legal-discuss@apache.org
Subject: RE: Corporate Contributions


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

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

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.


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:jimb@bea.com]
> Sent: Friday, March 25, 2005 11:48 AM
> To: William A. Rowe, Jr.; Geir Magnusson Jr.
> Cc: legal-discuss@apache.org
> 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.

DISCLAIMER: Discussions on this list are informational and educational
only, are not privileged and do not constitute legal advice.
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message