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" <[EMAIL PROTECTED]> 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
