Objectbridge and JDO: Licensing issue

[Florian Bruckner <bf...@florianbruckner.com>]

Hi,

I am sending this to the jakarta-general list because I hope that some of
you can help us to resolve the following issue.

As you might remember, Objectbridge was recently proposed as a
jakarta-subproject and accepted. This requires Objectbridge to change the
license to ASL, which is perfectly ok for everybody there.

As far as I can see, a small problem arose a few days ago. Somebody added
two jar Files of Sun Microsystems related to JDO (Java Data Objects, an API
OJB plans to implement). One of those jars is of the reference
implementation of JDO, one is either from the reference implementation or
the specification.

The following paragraphs is from an email I sent to the Objectbridge
Mailinglist, but unfortunately it didn't help to resolve our issue:

> jdo.jar and jdori.jar are part of the reference implementation of JDO from
> Sun, and that is licensed unter the sun community source license. The
> paragraph in question says:
>
> "
> a) Research Use License:
>
> 	(i) use, reproduce and modify the Original Code,
> Upgraded Code and Specifications to create Modifications and
> Reformatted Specifications for Research Use by You, (ii)
> publish and display Original Code, Upgraded Code and
> Specifications with, or as part of Modifications, as
> permitted under Section 3.1 b) below, (iii) reproduce and
> distribute copies of Original Code and Upgraded Code to
> Licensees and students for Research Use by You, (iv)
> compile, reproduce and distribute Original Code and Upgraded
> Code in Executable form, and Reformatted Specifications to
> anyone for Research Use by You.
> "
>
> My understanding of this paragraph is, that we'd only be able the JDO part
> of OJB under these conditions and only for research. This implies that
we'll
> not be able to release a "production quality" version of OJB-JDO. What we
> jave to go for is a "clean-room" implementation, the requirements for this
> are stipulated in the license of the JDO specification:
>
> "
> Sun hereby grants you a fully-paid, non-exclusive,
> non-transferable, worldwide, limited license (without the
> right to sublicense), under Sun's intellectual property
> rights that are essential to practice the Specification, to
> internally practice the Specification for the purpose of
> designing and developing your Java applets and applications
> intended to run on the Java platform or creating a clean
> room implementation of the Specification that:  (i) includes
> a complete implementation of the current version of the
> Specification, without subsetting or supersetting; (ii)
> implements all of the interfaces and functionality of the
> Specification without subsetting or supersetting; (iii)
> includes a complete implementation of any optional
> components (as defined by the Specification) which you
> choose to implement, without subsetting or supersetting;
> (iv) implements all of the interfaces and functionality of
> such optional components, without subsetting or
> supersetting; (v) does not add any additional packages,
> classes or interfaces to the "java.*" or "javax.*" packages
> or subpackages or other packages defined by the
> Specification; (vi) satisfies all testing requirements
> available from Sun relating to the most recently published
> version of the Specification six (6) months prior to any
> release of the clean room implementation or upgrade thereto;
> (vii) does not derive from any Sun source code or binary
> code materials; and (viii) does not include any Sun source
> code or binary code materials without an appropriate and
> separate license from Sun.  The Specification contains the
> proprietary information of Sun and may only be used in
> accordance with the license terms set forth herein.  This
> license will terminate immediately without notice from Sun
> if you fail to comply with any provision of this license.
> Upon termination or expiration of this license, you must
> cease use of or destroy the Specification.
> "
>
> jdo.jar is also part of the specification, but paragraph viii contains a
> clause that this .jar mustn't be used by a clean-room implementation as
well
> (and that is our goal, isn't it?)

Can we keep using these jars in Objectbridge or do we have to replace them
with our own implementation to do the move to ASL?

TIA,
Florian Bruckner



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Objectbridge and JDO: Licensing issue

[John McNally <jm...@collab.net>]

On Sat, 2002-05-25 at 11:00, Florian Bruckner wrote:
...
> > My understanding of this paragraph is, that we'd only be able the JDO part
> > of OJB under these conditions and only for research. This implies that
> we'll
> > not be able to release a "production quality" version of OJB-JDO. What we
> > jave to go for is a "clean-room" implementation, the requirements for this
> > are stipulated in the license of the JDO specification:
>

You state that this is a problem of moving to ASL. Is this not a problem
regardless of license?

Note that Apache has negotiated the ability to implement JSR's.  From
the press release 

http://jakarta.apache.org/site/jspa-agreement.html

"This is the result of extended dialog over the past year. Sun has
pledged to use licenses that enable open source independent
implementations for all its Java specifications and Test Compatibility
Kits. Sun has pledged this for all future Sun-led Java specifications as
well as key specifications already released."

Whether JDO is one of the "key" specs  is unknown by me, is there
somewhere where this list is available?

I also remember Jason van Zyl making a comment several months ago that
we had won the right to implement the JDO spec.  But I only say that so
that you may ask him where his info came from, or if I am recalling
correctly.  Do not take it to mean anything else than that.

john mcnally


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Objectbridge and JDO: Licensing issue

[Jason Hunter <jh...@servlets.com>]

You basically have two choices.  (1) You can use the Sun JAR files and
comply with their license.  Tomcat does this for several Sun JARs.  Note
that sometimes the JARs have a "value add" clause that makes things a
little tricky, but it's doable.  (2) You could do a clean room
implementation.  It's the legal right to do #2 that was agreed to with
Sun recently.  Previously if you didn't like Sun's JAR license, you were
just stuck.  Now you have the ability to implement a JSR on your own and
get access to the TCK.

-jh-

Pier Fumagalli wrote:
> 
> Florian, I believe that this is more-or-less (or falls really close) to the
> issue that XML-Axis is having (but I might be wrong, Sam?)
> 
> Maybe Jason (our liaison with the JCP) can give us some light on this topic?
> 
>     Pier
> 
> "Florian Bruckner" <bf...@florianbruckner.com> wrote:
> 
> > Hi,
> >
> > I am sending this to the jakarta-general list because I hope that some of
> > you can help us to resolve the following issue.
> >
> > As you might remember, Objectbridge was recently proposed as a
> > jakarta-subproject and accepted. This requires Objectbridge to change the
> > license to ASL, which is perfectly ok for everybody there.
> >
> > As far as I can see, a small problem arose a few days ago. Somebody added
> > two jar Files of Sun Microsystems related to JDO (Java Data Objects, an API
> > OJB plans to implement). One of those jars is of the reference
> > implementation of JDO, one is either from the reference implementation or
> > the specification.
> >
> > The following paragraphs is from an email I sent to the Objectbridge
> > Mailinglist, but unfortunately it didn't help to resolve our issue:
> >
> >> jdo.jar and jdori.jar are part of the reference implementation of JDO from
> >> Sun, and that is licensed unter the sun community source license. The
> >> paragraph in question says:
> >>
> >> "
> >> a) Research Use License:
> >>
> >> (i) use, reproduce and modify the Original Code,
> >> Upgraded Code and Specifications to create Modifications and
> >> Reformatted Specifications for Research Use by You, (ii)
> >> publish and display Original Code, Upgraded Code and
> >> Specifications with, or as part of Modifications, as
> >> permitted under Section 3.1 b) below, (iii) reproduce and
> >> distribute copies of Original Code and Upgraded Code to
> >> Licensees and students for Research Use by You, (iv)
> >> compile, reproduce and distribute Original Code and Upgraded
> >> Code in Executable form, and Reformatted Specifications to
> >> anyone for Research Use by You.
> >> "
> >>
> >> My understanding of this paragraph is, that we'd only be able the JDO part
> >> of OJB under these conditions and only for research. This implies that
> > we'll
> >> not be able to release a "production quality" version of OJB-JDO. What we
> >> jave to go for is a "clean-room" implementation, the requirements for this
> >> are stipulated in the license of the JDO specification:
> >>
> >> "
> >> Sun hereby grants you a fully-paid, non-exclusive,
> >> non-transferable, worldwide, limited license (without the
> >> right to sublicense), under Sun's intellectual property
> >> rights that are essential to practice the Specification, to
> >> internally practice the Specification for the purpose of
> >> designing and developing your Java applets and applications
> >> intended to run on the Java platform or creating a clean
> >> room implementation of the Specification that:  (i) includes
> >> a complete implementation of the current version of the
> >> Specification, without subsetting or supersetting; (ii)
> >> implements all of the interfaces and functionality of the
> >> Specification without subsetting or supersetting; (iii)
> >> includes a complete implementation of any optional
> >> components (as defined by the Specification) which you
> >> choose to implement, without subsetting or supersetting;
> >> (iv) implements all of the interfaces and functionality of
> >> such optional components, without subsetting or
> >> supersetting; (v) does not add any additional packages,
> >> classes or interfaces to the "java.*" or "javax.*" packages
> >> or subpackages or other packages defined by the
> >> Specification; (vi) satisfies all testing requirements
> >> available from Sun relating to the most recently published
> >> version of the Specification six (6) months prior to any
> >> release of the clean room implementation or upgrade thereto;
> >> (vii) does not derive from any Sun source code or binary
> >> code materials; and (viii) does not include any Sun source
> >> code or binary code materials without an appropriate and
> >> separate license from Sun.  The Specification contains the
> >> proprietary information of Sun and may only be used in
> >> accordance with the license terms set forth herein.  This
> >> license will terminate immediately without notice from Sun
> >> if you fail to comply with any provision of this license.
> >> Upon termination or expiration of this license, you must
> >> cease use of or destroy the Specification.
> >> "
> >>
> >> jdo.jar is also part of the specification, but paragraph viii contains a
> >> clause that this .jar mustn't be used by a clean-room implementation as
> > well
> >> (and that is our goal, isn't it?)
> >
> > Can we keep using these jars in Objectbridge or do we have to replace them
> > with our own implementation to do the move to ASL?
> >
> > TIA,
> > Florian Bruckner
> >
> --
> [Perl] combines all the worst aspects of C and Lisp:  a billion of different
> sublanguages in  one monolithic executable.  It combines the power of C with
> the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Objectbridge and JDO: Licensing issue

[Pier Fumagalli <pi...@betaversion.org>]

Florian, I believe that this is more-or-less (or falls really close) to the
issue that XML-Axis is having (but I might be wrong, Sam?)

Maybe Jason (our liaison with the JCP) can give us some light on this topic?

    Pier

"Florian Bruckner" <bf...@florianbruckner.com> wrote:

> Hi,
> 
> I am sending this to the jakarta-general list because I hope that some of
> you can help us to resolve the following issue.
> 
> As you might remember, Objectbridge was recently proposed as a
> jakarta-subproject and accepted. This requires Objectbridge to change the
> license to ASL, which is perfectly ok for everybody there.
> 
> As far as I can see, a small problem arose a few days ago. Somebody added
> two jar Files of Sun Microsystems related to JDO (Java Data Objects, an API
> OJB plans to implement). One of those jars is of the reference
> implementation of JDO, one is either from the reference implementation or
> the specification.
> 
> The following paragraphs is from an email I sent to the Objectbridge
> Mailinglist, but unfortunately it didn't help to resolve our issue:
> 
>> jdo.jar and jdori.jar are part of the reference implementation of JDO from
>> Sun, and that is licensed unter the sun community source license. The
>> paragraph in question says:
>> 
>> "
>> a) Research Use License:
>> 
>> (i) use, reproduce and modify the Original Code,
>> Upgraded Code and Specifications to create Modifications and
>> Reformatted Specifications for Research Use by You, (ii)
>> publish and display Original Code, Upgraded Code and
>> Specifications with, or as part of Modifications, as
>> permitted under Section 3.1 b) below, (iii) reproduce and
>> distribute copies of Original Code and Upgraded Code to
>> Licensees and students for Research Use by You, (iv)
>> compile, reproduce and distribute Original Code and Upgraded
>> Code in Executable form, and Reformatted Specifications to
>> anyone for Research Use by You.
>> "
>> 
>> My understanding of this paragraph is, that we'd only be able the JDO part
>> of OJB under these conditions and only for research. This implies that
> we'll
>> not be able to release a "production quality" version of OJB-JDO. What we
>> jave to go for is a "clean-room" implementation, the requirements for this
>> are stipulated in the license of the JDO specification:
>> 
>> "
>> Sun hereby grants you a fully-paid, non-exclusive,
>> non-transferable, worldwide, limited license (without the
>> right to sublicense), under Sun's intellectual property
>> rights that are essential to practice the Specification, to
>> internally practice the Specification for the purpose of
>> designing and developing your Java applets and applications
>> intended to run on the Java platform or creating a clean
>> room implementation of the Specification that:  (i) includes
>> a complete implementation of the current version of the
>> Specification, without subsetting or supersetting; (ii)
>> implements all of the interfaces and functionality of the
>> Specification without subsetting or supersetting; (iii)
>> includes a complete implementation of any optional
>> components (as defined by the Specification) which you
>> choose to implement, without subsetting or supersetting;
>> (iv) implements all of the interfaces and functionality of
>> such optional components, without subsetting or
>> supersetting; (v) does not add any additional packages,
>> classes or interfaces to the "java.*" or "javax.*" packages
>> or subpackages or other packages defined by the
>> Specification; (vi) satisfies all testing requirements
>> available from Sun relating to the most recently published
>> version of the Specification six (6) months prior to any
>> release of the clean room implementation or upgrade thereto;
>> (vii) does not derive from any Sun source code or binary
>> code materials; and (viii) does not include any Sun source
>> code or binary code materials without an appropriate and
>> separate license from Sun.  The Specification contains the
>> proprietary information of Sun and may only be used in
>> accordance with the license terms set forth herein.  This
>> license will terminate immediately without notice from Sun
>> if you fail to comply with any provision of this license.
>> Upon termination or expiration of this license, you must
>> cease use of or destroy the Specification.
>> "
>> 
>> jdo.jar is also part of the specification, but paragraph viii contains a
>> clause that this .jar mustn't be used by a clean-room implementation as
> well
>> (and that is our goal, isn't it?)
> 
> Can we keep using these jars in Objectbridge or do we have to replace them
> with our own implementation to do the move to ASL?
> 
> TIA,
> Florian Bruckner
> 
--
[Perl] combines all the worst aspects of C and Lisp:  a billion of different
sublanguages in  one monolithic executable.  It combines the power of C with
the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco]


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>