OVPL - wrap-up of objections

[Lawrence Rosen]

> I'm not sure what you mean by "doable" here. I don't believe 
> there is an enforceability problem beyond that of ANY 
> reciprocal license in bare license form (Andy disagrees, if 
> you do too, I'd like to know why; Larry Rosen seems to agree).

That misstates what I told you. Your rather tough license requirement that
contributors assign their copyrights to the ID is possibly not enforceable
in the absence of a written contract. I referred you to 17 USC 201(e) and
204(a). You should consult your own attorney to get advice about how or if
those sections of copyright law might affect your license.

/Larry

> -----Original Message-----
> From: Alex Bligh [mailto:alex at alex.org.uk] 
> Sent: Thursday, July 21, 2005 1:38 PM
> To: Chris F Clark; license-discuss at opensource.org
> Cc: Alex Bligh
> Subject: Re: OVPL - wrap-up of objections
> 
> Chris,
> 
> --On 21 July 2005 15:30 -0400 Chris F Clark <cfc at theworld.com> wrote:
> 
> > Andy T Wilson (ATW) posted two objections to the OVPL, which he 
> > summarized and I have extracted from below:
> >
> >> The "contract" portion of OVPL creates a bi-lateral 
> agreement between 
> >> the contributor and ID in which the contributor
> >> (a) agrees to furnish the ID with all future contributor 
> >> modifications to covered code, and (b) agrees that the ID 
> (and only 
> >> the ID) has rights to, at its option, re-license contributor 
> >> modifications on non-OVPL terms.
> >
> > I'm going to ignore the issue of the ID being able to relicense the 
> > code under other licenses.  From my point of view that is a 
> desirable 
> > quality.  However, as discussed, it may not be doable as part of a 
> > license which is not a properly executed signed contract.  
> Even as a 
> > developer who would be tempted to use the OVPL, I would 
> still want to 
> > have signed argeements for non-trivial submissions (and 
> perhaps even 
> > agreements for trivial ones).
> 
> I'm not sure what you mean by "doable" here. I don't believe 
> there is an enforceability problem beyond that of ANY 
> reciprocal license in bare license form (Andy disagrees, if 
> you do too, I'd like to know why; Larry Rosen seems to agree).
> 
> However, I *do* agree with the last statement. Signed 
> agreements (whether in the form of license-backs, or 
> assignments with re-license) will *always* improve the 
> situation in that they represent belt-and-braces. I fully 
> expect ID's to ask for them too in many circumstances; I 
> don't expect they will always receive them though.
> 
> > I think the important point here is the "all" modifications 
> portion, 
> > which has been disputed.  The OVPL as far as I can see, is 
> trying to 
> > prevent "shared secrets", that is donwstream versions that 
> are shared 
> > by a community but are secret to that community.  It is not 
> clear that 
> > preventing shared secrets is non-OSD.  (I think it fails one of the 
> > criteria for being "free", but that is a separate topic.)
> 
> That's only the back-end of 3.3. I'm very surprised that's 
> the bit of 3.3 which is causing indigestion (I don't think 
> that's what Andy was suggesting) not least because is was 
> discussed on this list (though I now can't find it).
> 
> I thought the front end of 3.3 was the problem (the license-back).
> 
> > If the OVPL did not give the ID rights to relicense the contributed 
> > software, would it still be objectionable?  Next, would it still be 
> > distinct from other licenses?  Is there another license that allows 
> > the ID to request modifications that have been distributed, but for 
> > which source is not "generally available"?
> 
> I would hope not - without 3.3, there I don't think there is 
> anything vaguely contentious (looks for something wooden to touch).
> 
> Alex