[Objectbridge-jdo-dev] FYI: Objectbridge and JDO: Licensing issue

[Mahler T. <tho...@it...>]

> -----Urspr=FCngliche Nachricht-----
> Von: Jason Hunter [mailto:jh...@se...]
> Gesendet: Montag, 27. Mai 2002 21:12
> An: Pier Fumagalli
> Cc: Jakarta General List
> Betreff: Re: Objectbridge and JDO: Licensing issue
>=20
>=20
> You basically have two choices.  (1) You can use the Sun JAR files =
and
> comply with their license.  Tomcat does this for several Sun=20
> 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=20
> license, you were
> just stuck.  Now you have the ability to implement a JSR on=20
> your own and
> get access to the TCK.
>=20
> -jh-
>=20
> Pier Fumagalli wrote:
> >=20
> > Florian, I believe that this is more-or-less (or falls=20
> really close) to the
> > issue that XML-Axis is having (but I might be wrong, Sam?)
> >=20
> > Maybe Jason (our liaison with the JCP) can give us some=20
> light on this topic?
> >=20
> >     Pier
> >=20
> > "Florian Bruckner" <bf...@fl...> wrote:
> >=20
> > > Hi,
> > >
> > > I am sending this to the jakarta-general list because I=20
> 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=20
> 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=20
> ago. Somebody added
> > > two jar Files of Sun Microsystems related to JDO (Java=20
> 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=20
> implementation or
> > > the specification.
> > >
> > > The following paragraphs is from an email I sent to the=20
> Objectbridge
> > > Mailinglist, but unfortunately it didn't help to resolve=20
> our issue:
> > >
> > >> jdo.jar and jdori.jar are part of the reference=20
> implementation of JDO from
> > >> Sun, and that is licensed unter the sun community source=20
> 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=20
> able the JDO part
> > >> of OJB under these conditions and only for research.=20
> This implies that
> > > we'll
> > >> not be able to release a "production quality" version of=20
> OJB-JDO. What we
> > >> jave to go for is a "clean-room" implementation, the=20
> 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=20
> viii contains a
> > >> clause that this .jar mustn't be used by a clean-room=20
> implementation as
> > > well
> > >> (and that is our goal, isn't it?)
> > >
> > > Can we keep using these jars in Objectbridge or do we=20
> 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=20
> billion of different
> > sublanguages in  one monolithic executable.  It combines=20
> the power of C with
> > the readability of PostScript. [Jamie Zawinski - DNA Lounge=20
> - San Francisco]
>=20
>=20
>=20
> --
> To unsubscribe, e-mail:  =20
> <mailto:gen...@ja...>
> For additional commands, e-mail:=20
> <mailto:gen...@ja...>
>=20