www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim O'Brien" <tobr...@discursive.com>
Subject Re: JCP spec licensing (was RE: StAX (JSR 173) API source license)
Date Fri, 28 Apr 2006 16:36:44 GMT
It sounds like we have three lawyers all agreeing that the ASF can't
distribute a spec developed under the JCP because the Foundation has signed
on to the JSPA?

If so, how does this jive with the Geronimo specification implementations?

Also, I'm still unclear as to why Day Software wouldn't be able to
distribute the JCR-170 API without a click thru if it is covered under the
ASL 2.0.     If nothing impeded Geronimo from writing clean room
implementations of the Servlet API, what impedes the Jackrabbit project from
doing the same?  In Jackrabbit's case is it merely because Day Software is a
contributor to said project?

I guess I need some clarification,why would JBoss be allow to distribute
something like a public preview of the JSR-220 draft under the LGPL.  Is is
because they have a different interpreation of the JSPA?   Is it because the
LGPL is more compatible with the JSPA?

On 4/28/06, Jeffrey Thompson <jthom@us.ibm.com> wrote:
>
>
>
> "Jim Barnett" <jimb@bea.com> wrote on 04/27/2006 04:57:02 PM:
>
>
> > Thanks Jeff.
> >
> > To be clear, I wasn't advocating for or against Sun's interpretation
> > of the JSPA on the issue of Spec License requirements.  Rather I was
> > questioning whether the interpretation Sun offers on that point
> > (when taken as being correct for sake of argument only) is logically
> > effective at preserving compatibility given that there is no
> > requirement for downstream licensees to maintain compatibility when
> > they modify otherwise compatible implementations.
>
> Got it.  At the end of the day, the JSPA is a series of bilateral
> agreements with Sun and its up to each of the two parties to determine what
> they believe the language means.  I'm merely suggesting that people look
> really closely at what the language actually says before accepting Sun's
> interpretation.
>
>
> >
> > While there are plenty of reasons why downstream licensees would
> > choose maintain compatibility of implementations, my point was that
> > nothing in the JSPA requires that downstream licensees be compelled
> > contractually to maintain compatibility of implementations, even
> > when they make changes to and further distribute the modified
> > implementations.
>
> Right.  That was specifically discussed during the drafting.
>
>
> >
> > It seems like there's an incongruity between the position that
> > implementers should be contractually required to pass the TCK in
> > order to distribute their implementations, and the position that it
> > is acceptable for any party licensing those implementations to
> > freely modify so as to make them incompatible and further distribute
> > the modified implementations.  If you allow the latter, why be so
> > insistent on the former?  It smacks of dogmatism rather than reason.
>
> Right, it doesn't make sense to me for the Spec Lead to require that all
> implementers pass the TCK when the licensees of the implementers do not have
> to do so.
>
>
> >
> > Against this backdrop, conditioning use of the Java compatibility
> > logo on passage of the TCK makes much more sense than gating
> > distribution of independent implementations on passage of the TCK.
> >
>
> We're on the same page.  Clear and accurate representation of
> compatibility.
>
> > Jim
> >
> Jeff
>
> Staff Counsel, IBM Corporation  (914)766-1757  (tie)8-826  (fax) -8160
> (notes) jthom@ibmus  (internet) jthom@us.ibm.com (home) jeff@beff.net
> (web) http://www.beff.net/
>
>
>

Mime
View raw message