Re: LICENSE in .jar files

[Conor MacNeill]

acoliver wrote:

> I do.  I was just curious.
> 

Have you a licence for that? :-) It's a mad world.

Conor


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: RE: LICENSE in .jar files

[acoliver]

I do.  I was just curious.


>On Thu, 21 Mar 2002 08:26:50 -0500 "Berin Loritsch" <[EMAIL PROTECTED]>
wrote.
>> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
>> 
>> BTW.  Define: "release" ;-)
>
>
>That sounds like former persident Bill Clinton with his
>"define sexual relations".  Such a question insinuates
>guilt, and that you are trying to find a letter of the
>law loop hole to be clever about.
>
>Lawers are like wolves, they'll eat you for lunch.  You
>may think you have a loop hole, but just shed the right
>light, and it is exposed.
>
>You're always better following the spirit of the law,
>because the devil is in the details (and in the pin
>striped suite)
>
>> 
>> On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote:
>> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> > > On Thu, 21 Mar 2002, Peter Donald wrote:
>> > >
>> > >
>> > > I think what Peter said was that you can read the spec 
>> only if you 
>> > > agree with the licence, and that prevents you from 
>> implementing it 
>> > > unless you follow all the rules.
>> > >
>> > 
>> > You can read the spec. You just can't use the spec to create a 
>> > cleanroom implementation of the specification. You can 
>> still read it 
>> > to understand how to use somebody else's implementation. 
>> Presumably, 
>> > however, having read the spec, you are tainted.
>> > 
>> > > That includes the requirement to pass the official test 
>> suite, and 
>> > > probably other restrictions I don't understand.
>> > 
>> > The problematic clause is this one, I presume:
>> > "(vi) satisfies all testing requirements available from the 
>> > Specification Lead 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;"
>> > 
>> > Presumably we cannot distribute the xml-apis unless we can 
>> meet this 
>> > requirement of the spec.
>> > 
>> > This page http://jcp.org/aboutJava/communityprocess/final/jsr063/
>> > 
>> > asserts that there is a JAXP TCK, although you can't seem 
>> to purchase 
>> > it online.
>> > 
>> > Other restrictions - who knows? When the spec says "(vii) does not 
>> > derive from any of the Specification Lead's source code or 
>> binary code 
>> > materials;", it is not clear to me what that covers, 
>> especially in the 
>> > case of JAXP where I think the RI comes from Apache, based on code 
>> > originally contributed by the Specification Lead (Sun).
>> > 
>> > Also there may be a specific Out-of-Band Sun-Apache licence 
>> in place 
>> > as alluded to by Dirk earlier.
>> > 
>> > >
>> > > It's obvious some of the people who worked on this did 
>> read the spec 
>> > > - so it seems this is not a legal implementation.
>> > >
>> > 
>> > If there is no specific agreement between Sun and Apache covering 
>> > this, then I agree.
>> > 
>> > > The licencing and jcp lists are closed to the public, and 
>> this seems 
>> > > to be the job of the PMC and ASF ( to verify that all the 
>> software 
>> > > is legally used ). I can only hope a lawyer will be used 
>> to validate 
>> > > it.
>> > >
>> > > If this is not resolved - we have to start removing all 
>> dependencies 
>> > > to JAXP and all other APIs that are not legal, and 
>> eventually work 
>> > > on replacements.
>> > >
>> > > There is no other way.
>> > 
>> > I presume you can still depend on JAXP without having your 
>> own clean 
>> > room implementation, nor including it in a distribution. You would 
>> > have to require the user to acquire their own copy of the jaxp 
>> > classes/interfaces. I haven't seen any restrictions in the spec on 
>> > linking.
>> > 
>> > Conor
>> > 
>> > 
>> > --
>> > To unsubscribe, e-mail:   
>>  [EMAIL PROTECTED]>
>> > For 
>> additional commands, 
>> e-mail: 
>> > 
>> > 
>> -- 
>> http://www.superlinksoftware.com
>> http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 
>> Compound Document 
>> format to java 
>> http://developer.java.sun.com/developer/bugParade/bugs/4487555
>..html 
>   - fix java generics!
>The avalanche has already started. It is too late for the pebbles to
>vote. -Ambassador Kosh
>
>
>--
>To unsubscribe, e-mail:
>
>For additional commands, e-mail:
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Berin Loritsch]

> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 
> 
> BTW.  Define: "release" ;-)


That sounds like former persident Bill Clinton with his
"define sexual relations".  Such a question insinuates
guilt, and that you are trying to find a letter of the
law loop hole to be clever about.

Lawers are like wolves, they'll eat you for lunch.  You
may think you have a loop hole, but just shed the right
light, and it is exposed.

You're always better following the spirit of the law,
because the devil is in the details (and in the pin
striped suite)

> 
> On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote:
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > On Thu, 21 Mar 2002, Peter Donald wrote:
> > >
> > >
> > > I think what Peter said was that you can read the spec 
> only if you 
> > > agree with the licence, and that prevents you from 
> implementing it 
> > > unless you follow all the rules.
> > >
> > 
> > You can read the spec. You just can't use the spec to create a 
> > cleanroom implementation of the specification. You can 
> still read it 
> > to understand how to use somebody else's implementation. 
> Presumably, 
> > however, having read the spec, you are tainted.
> > 
> > > That includes the requirement to pass the official test 
> suite, and 
> > > probably other restrictions I don't understand.
> > 
> > The problematic clause is this one, I presume:
> > "(vi) satisfies all testing requirements available from the 
> > Specification Lead 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;"
> > 
> > Presumably we cannot distribute the xml-apis unless we can 
> meet this 
> > requirement of the spec.
> > 
> > This page http://jcp.org/aboutJava/communityprocess/final/jsr063/
> > 
> > asserts that there is a JAXP TCK, although you can't seem 
> to purchase 
> > it online.
> > 
> > Other restrictions - who knows? When the spec says "(vii) does not 
> > derive from any of the Specification Lead's source code or 
> binary code 
> > materials;", it is not clear to me what that covers, 
> especially in the 
> > case of JAXP where I think the RI comes from Apache, based on code 
> > originally contributed by the Specification Lead (Sun).
> > 
> > Also there may be a specific Out-of-Band Sun-Apache licence 
> in place 
> > as alluded to by Dirk earlier.
> > 
> > >
> > > It's obvious some of the people who worked on this did 
> read the spec 
> > > - so it seems this is not a legal implementation.
> > >
> > 
> > If there is no specific agreement between Sun and Apache covering 
> > this, then I agree.
> > 
> > > The licencing and jcp lists are closed to the public, and 
> this seems 
> > > to be the job of the PMC and ASF ( to verify that all the 
> software 
> > > is legally used ). I can only hope a lawyer will be used 
> to validate 
> > > it.
> > >
> > > If this is not resolved - we have to start removing all 
> dependencies 
> > > to JAXP and all other APIs that are not legal, and 
> eventually work 
> > > on replacements.
> > >
> > > There is no other way.
> > 
> > I presume you can still depend on JAXP without having your 
> own clean 
> > room implementation, nor including it in a distribution. You would 
> > have to require the user to acquire their own copy of the jaxp 
> > classes/interfaces. I haven't seen any restrictions in the spec on 
> > linking.
> > 
> > Conor
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> > For 
> additional commands, 
> e-mail: 
> > 
> > 
> -- 
> http://www.superlinksoftware.com
> http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 
> Compound Document 
> format to java 
> http://developer.java.sun.com/developer/bugParade/bugs/4487555
.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote. -Ambassador Kosh


--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Andrew C. Oliver]

I guess I'm wondering what the legal definition of "reverse-engineer"
means.  To me that means disassemble.  If I just write something that
happens to have the same interface, inputs and outputs, to me that
doesn't qualify as "reverse-engineer" but maybe thats just me.  When my
5 year old stepson imitates my movements and voice intonations I don't
feel like he reverse engineered me :-)

-Andy 

On Wed, 2002-03-20 at 21:36, [EMAIL PROTECTED] wrote:
> 
> On Thu, 21 Mar 2002, Conor MacNeill wrote:
> 
> > I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you
> > would not be able to legally run such a reverse engineered clone on a Sun
> 
> You have a lawyer - or rather - the PMC has access to those beast. This is
> being worked on (even today - during the ASF board meeting) - and will be
> resolved. Feel free to keep bringing good examples of potential problems
> to [EMAIL PROTECTED]
> 
> Dw
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document 
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[dirkx]

On Thu, 21 Mar 2002, Conor MacNeill wrote:

> I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you
> would not be able to legally run such a reverse engineered clone on a Sun

You have a lawyer - or rather - the PMC has access to those beast. This is
being worked on (even today - during the ASF board meeting) - and will be
resolved. Feel free to keep bringing good examples of potential problems
to [EMAIL PROTECTED]

Dw


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Conor MacNeill]

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 21 March 2002 1:10 PM
> To: Jakarta General List
> Subject: RE: LICENSE in .jar files
>
>
> BTW.  Define: "release" ;-)
>

I guess it would be up to a court to define "release" :-) I don't know what
it means :-)

There are similar definition problems with terms such as "distribution".
Does providing a jar in CVS consistute distribution. Probably does.

Conor


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: LICENSE in .jar files

[Conor MacNeill]

> -Original Message-
> From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 21 March 2002 1:03 PM
> To: Jakarta General List
> Subject: RE: LICENSE in .jar files
>
>
> So could a non-tainted person through black box testing produce their
> own JAXP clone?
>
> -Andy
>

I don't know. IANAL. We really do need a lawyer. Anyway, in my view, you
would not be able to legally run such a reverse engineered clone on a Sun
JDK

>From the JDK 1.4 licence.

Java Technology Restrictions. You may not modify the Java Platform Interface
("JPI", identified as classes contained within the "java" package or any
subpackages of the "java" package), by creating additional classes within
the JPI or otherwise causing the addition to or modification of the classes
in the JPI.  In the event that you create an additional class and associated
API(s) which (i) extends the functionality of the Java platform, and (ii) is
exposed to third party software developers for the purpose of developing
additional software which invokes such additional API, you must promptly
publish broadly an accurate specification for such API for free use by all
developers.  You may not create, or authorize your licensees to create,
additional classes, interfaces, or subpackages that are in any way
identified as "java", "javax", "sun" or similar convention as specified by
Sun in any naming convention designation.


Conor


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: LICENSE in .jar files

[Peter Donald]

On Thu, 21 Mar 2002 13:03, Andrew C. Oliver wrote:
> So could a non-tainted person through black box testing produce their
> own JAXP clone?

I don't see how as they need access to Suns IP someway and there is no way to 
get a license to do that. Ie can't use spec without being "tainted" and can't 
use any *legal* implementation of spec because all legal implementations are 
not able to grant the right of reimplementation. 

I doubt that would hold up in court but it has held up various opensource 
projects that are actually concerned about legalities (see the GNU Classpath 
archives).

Fun fun fun.

-- 
Cheers,

Pete

**
| Trying is the first step to failure.   |
|   So never try, Lisa  - Homer Jay Simpson  |
**

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Andrew C. Oliver]

BTW.  Define: "release" ;-)

On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > On Thu, 21 Mar 2002, Peter Donald wrote:
> >
> >
> > I think what Peter said was that you can read the spec only if you
> > agree with the licence, and that prevents you from implementing it
> > unless you follow all the rules.
> >
> 
> You can read the spec. You just can't use the spec to create a cleanroom
> implementation of the specification. You can still read it to understand how
> to use somebody else's implementation. Presumably, however, having read the
> spec, you are tainted.
> 
> > That includes the requirement to pass the official test suite,
> > and probably other restrictions I don't understand.
> 
> The problematic clause is this one, I presume:
> "(vi) satisfies all testing requirements available from the Specification
> Lead 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;"
> 
> Presumably we cannot distribute the xml-apis unless we can meet this
> requirement of the spec.
> 
> This page
> http://jcp.org/aboutJava/communityprocess/final/jsr063/
> 
> asserts that there is a JAXP TCK, although you can't seem to purchase it
> online.
> 
> Other restrictions - who knows? When the spec says "(vii) does not derive
> from any of the Specification Lead's source code or binary code materials;",
> it is not clear to me what that covers, especially in the case of JAXP where
> I think the RI comes from Apache, based on code originally contributed by
> the Specification Lead (Sun).
> 
> Also there may be a specific Out-of-Band Sun-Apache licence in place as
> alluded to by Dirk earlier.
> 
> >
> > It's obvious some of the people who worked on this did read
> > the spec - so it seems this is not a legal implementation.
> >
> 
> If there is no specific agreement between Sun and Apache covering this, then
> I agree.
> 
> > The licencing and jcp lists are closed to the public, and
> > this seems to be the job of the PMC and ASF ( to verify
> > that all the software is legally used ). I can only hope
> > a lawyer will be used to validate it.
> >
> > If this is not resolved - we have to start removing all
> > dependencies to JAXP and all other APIs that are not legal,
> > and eventually work on replacements.
> >
> > There is no other way.
> 
> I presume you can still depend on JAXP without having your own clean room
> implementation, nor including it in a distribution. You would have to
> require the user to acquire their own copy of the jaxp classes/interfaces. I
> haven't seen any restrictions in the spec on linking.
> 
> Conor
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document 
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Andrew C. Oliver]

So could a non-tainted person through black box testing produce their
own JAXP clone? 

-Andy

On Wed, 2002-03-20 at 19:55, Conor MacNeill wrote:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > On Thu, 21 Mar 2002, Peter Donald wrote:
> >
> >
> > I think what Peter said was that you can read the spec only if you
> > agree with the licence, and that prevents you from implementing it
> > unless you follow all the rules.
> >
> 
> You can read the spec. You just can't use the spec to create a cleanroom
> implementation of the specification. You can still read it to understand how
> to use somebody else's implementation. Presumably, however, having read the
> spec, you are tainted.
> 
> > That includes the requirement to pass the official test suite,
> > and probably other restrictions I don't understand.
> 
> The problematic clause is this one, I presume:
> "(vi) satisfies all testing requirements available from the Specification
> Lead 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;"
> 
> Presumably we cannot distribute the xml-apis unless we can meet this
> requirement of the spec.
> 
> This page
> http://jcp.org/aboutJava/communityprocess/final/jsr063/
> 
> asserts that there is a JAXP TCK, although you can't seem to purchase it
> online.
> 
> Other restrictions - who knows? When the spec says "(vii) does not derive
> from any of the Specification Lead's source code or binary code materials;",
> it is not clear to me what that covers, especially in the case of JAXP where
> I think the RI comes from Apache, based on code originally contributed by
> the Specification Lead (Sun).
> 
> Also there may be a specific Out-of-Band Sun-Apache licence in place as
> alluded to by Dirk earlier.
> 
> >
> > It's obvious some of the people who worked on this did read
> > the spec - so it seems this is not a legal implementation.
> >
> 
> If there is no specific agreement between Sun and Apache covering this, then
> I agree.
> 
> > The licencing and jcp lists are closed to the public, and
> > this seems to be the job of the PMC and ASF ( to verify
> > that all the software is legally used ). I can only hope
> > a lawyer will be used to validate it.
> >
> > If this is not resolved - we have to start removing all
> > dependencies to JAXP and all other APIs that are not legal,
> > and eventually work on replacements.
> >
> > There is no other way.
> 
> I presume you can still depend on JAXP without having your own clean room
> implementation, nor including it in a distribution. You would have to
> require the user to acquire their own copy of the jaxp classes/interfaces. I
> haven't seen any restrictions in the spec on linking.
> 
> Conor
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document 
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Shane Curcuru]

Sorry for my tangent - it's clear that on legal matters, I should just
get the heck outta Dodge and let someone with more patience work on it.
 8-{

I've forwarded a link (with threading) to your (Conor's) message to the
xml PMC so they should be aware of this licensing issue with JAXP and xml-commons.

=
- Shane

mailto:[EMAIL PROTECTED]";
 .sig="Du sublime au ridicule il n'y a qu'un pas." />

__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LICENSE in .jar files

[Conor MacNeill]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> On Thu, 21 Mar 2002, Peter Donald wrote:
>
>
> I think what Peter said was that you can read the spec only if you
> agree with the licence, and that prevents you from implementing it
> unless you follow all the rules.
>

You can read the spec. You just can't use the spec to create a cleanroom
implementation of the specification. You can still read it to understand how
to use somebody else's implementation. Presumably, however, having read the
spec, you are tainted.

> That includes the requirement to pass the official test suite,
> and probably other restrictions I don't understand.

The problematic clause is this one, I presume:
"(vi) satisfies all testing requirements available from the Specification
Lead 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;"

Presumably we cannot distribute the xml-apis unless we can meet this
requirement of the spec.

This page
http://jcp.org/aboutJava/communityprocess/final/jsr063/

asserts that there is a JAXP TCK, although you can't seem to purchase it
online.

Other restrictions - who knows? When the spec says "(vii) does not derive
from any of the Specification Lead's source code or binary code materials;",
it is not clear to me what that covers, especially in the case of JAXP where
I think the RI comes from Apache, based on code originally contributed by
the Specification Lead (Sun).

Also there may be a specific Out-of-Band Sun-Apache licence in place as
alluded to by Dirk earlier.

>
> It's obvious some of the people who worked on this did read
> the spec - so it seems this is not a legal implementation.
>

If there is no specific agreement between Sun and Apache covering this, then
I agree.

> The licencing and jcp lists are closed to the public, and
> this seems to be the job of the PMC and ASF ( to verify
> that all the software is legally used ). I can only hope
> a lawyer will be used to validate it.
>
> If this is not resolved - we have to start removing all
> dependencies to JAXP and all other APIs that are not legal,
> and eventually work on replacements.
>
> There is no other way.

I presume you can still depend on JAXP without having your own clean room
implementation, nor including it in a distribution. You would have to
require the user to acquire their own copy of the jaxp classes/interfaces. I
haven't seen any restrictions in the spec on linking.

Conor


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[costinm]

On Thu, 21 Mar 2002, Peter Donald wrote:

> On Thu, 21 Mar 2002 10:01, Shane Curcuru wrote:
> > IANAL, and I have no idea how this corresponds to usage of the JAXP
> > specification, but it seems pretty clear that this is an implementation
> >  of JAXP that's under the Apache license...
> 
> And blatently illegal to boot ;)

I think what Peter said was that you can read the spec only if you
agree with the licence, and that prevents you from implementing it
unless you follow all the rules. 

That includes the requirement to pass the official test suite, 
and probably other restrictions I don't understand.

It's obvious some of the people who worked on this did read
the spec - so it seems this is not a legal implementation.

The licencing and jcp lists are closed to the public, and 
this seems to be the job of the PMC and ASF ( to verify 
that all the software is legally used ). I can only hope
a lawyer will be used to validate it.

If this is not resolved - we have to start removing all
dependencies to JAXP and all other APIs that are not legal,
and eventually work on replacements. 

There is no other way. 

Costin
 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[Peter Donald]

On Thu, 21 Mar 2002 10:01, Shane Curcuru wrote:
> IANAL, and I have no idea how this corresponds to usage of the JAXP
> specification, but it seems pretty clear that this is an implementation
>  of JAXP that's under the Apache license...

And blatently illegal to boot ;)

-- 
Cheers,

Pete

-
I think not; therefore I ain't...
-

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[Shane Curcuru]

> A complete readme, giving pointers to download your own lawful
version
> of jaxp.jar, would also include how to live without jaxp.jar, if this
is
> possible.

Sorry if this is off on a tangent, but if you're just looking for an
implementation of the javax.xml.parsers and javax.xml.transform
packages (i.e., JAXP) that's under the Apache license, you need look no
further than:

http://xml.apache.org/commons/#external

IANAL, and I have no idea how this corresponds to usage of the JAXP
specification, but it seems pretty clear that this is an implementation
 of JAXP that's under the Apache license...

Xalan and soon Xerces will be using the xml-apis.jar that's included in
the xml-commons distro as their checked-in and redistributed copies of
DOM, SAX, and JAXP.  Jakarta projects are of course welcome to steal
our code too.

> Wouldn't it be great if there was a BMW 530 in my garage when I wake
up
tomorrow?

Make mine a 1988 M6; either in black or the version of cimmaron red
they used to have.  Most beautiful car I can remember, aside from an M1
(which would be in Motorsport colors, of course!).

=
- Shane

mailto:[EMAIL PROTECTED]";
 .sig="Du sublime au ridicule il n'y a qu'un pas." />

__
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[Paul Libbrecht]

Well,

This may work if:

1> the license applies to the redistributed version
2> or this license is provided only as a "proof of purchase" (that is a 
receipt that allows ASF to distribute this) but something more has to be 
indicated, that is, how to get it for yourself so as to be able to 
redistribute it

The problem is the following: I'm still expecting some advice from our 
lawyers but I understand currently that ALL Sun licenses are 
non-transferable. As such, anyone in the name of ASF may include this in 
one of the ASF packages but it does give no rights to redistribute to 
anyone that receives this (e.g. me downloading Ant) (*1).

So that: folks receiving such a package should be indicated that they 
can redistribute Apache software but not Sun software and, if they want 
to use Sun software, that they should pick their version at Sun's site.

(this also involves that Sun maintains such links alive, it is not the 
case of Jaxp 1.1... until we're sure they do this, it may make sense to 
URGE downloaders to get their copy right now)

After good thoughts, I feel this a bit like a trap as for many things, 
there is no way to get rid of Sun interface class files.
A complete readme, giving pointers to download your own lawful version 
of jaxp.jar, would also include how to live without jaxp.jar, if this is 
possible.
Getting rid of servlet.jar, for example, seems way harder...

So that... license in .jar files ?? Maybe, but with a readme indicating 
that one is bound by the conditions of this license even though one has 
never read it...

Paul

(*1) Actually, I am sure a dreaded crazy guy may even say that the 
action of cvs-update is already a redistribution so that another person, 
maybe not lawfully member of ASF would be prohibited to build a 
distribution

PS: JDOM beta 8 (see http://www.jdom.org) just did it almost as you say, 
they now have licenses and pointers to original projects, they did not 
say anything about redistribution though...



On Vendredi, mars 15, 2002, at 03:09 , Kevin A. Burton wrote:
> Jus thinking out loud.  Would it be a good protocol to put a LICENSE 
> file in
> .jar files under META-INF ?
>
> Specifically with the JCP stuff and some JAR files that come from SUN 
> and can't be redistributed.
>
> Thanks.  Comments appreciated.
>
> Kevin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[Andrew C. Oliver]

On Thu, 2002-03-14 at 22:16, Geir Magnusson Jr. wrote:
> On 3/14/02 9:17 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:
> 
> > on 3/14/02 6:09 PM, "Kevin A. Burton" <[EMAIL PROTECTED]> wrote:
> > 
> >> Would it be a good protocol to put a LICENSE file in
> >> .jar files under META-INF ?
> > 
> > Sure.
> > 
> > *poof* it is now done in all of the Jakarta projects.
> > 
> > Don't you like magic like that?
> > 
> 
> Wouldn't it be great if there was a BMW 530 in my garage when I wake up
> tomorrow?

oooh mee too mee tooo!!!  Thanks Papa Jon!

> 
> (your cue, Jon...  Blond/toledo, sport, cold, split seats, xenon)
> 
> -- 
> Geir Magnusson Jr. [EMAIL PROTECTED]
> System and Software Consulting
> Be a giant.  Take giant steps.  Do giant things...
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
-- 
http://www.superlinksoftware.com
http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound
Document 
format to java
http://developer.java.sun.com/developer/bugParade/bugs/4487555.html 
- fix java generics!
The avalanche has already started. It is too late for the pebbles to
vote.
-Ambassador Kosh


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[Geir Magnusson Jr.]

On 3/14/02 9:17 PM, "Jon Scott Stevens" <[EMAIL PROTECTED]> wrote:

> on 3/14/02 6:09 PM, "Kevin A. Burton" <[EMAIL PROTECTED]> wrote:
> 
>> Would it be a good protocol to put a LICENSE file in
>> .jar files under META-INF ?
> 
> Sure.
> 
> *poof* it is now done in all of the Jakarta projects.
> 
> Don't you like magic like that?
> 

Wouldn't it be great if there was a BMW 530 in my garage when I wake up
tomorrow?

(your cue, Jon...  Blond/toledo, sport, cold, split seats, xenon)

-- 
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Be a giant.  Take giant steps.  Do giant things...


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: LICENSE in .jar files

[Jon Scott Stevens]

on 3/14/02 6:09 PM, "Kevin A. Burton" <[EMAIL PROTECTED]> wrote:

> Would it be a good protocol to put a LICENSE file in
> .jar files under META-INF ?

Sure.

*poof* it is now done in all of the Jakarta projects.

Don't you like magic like that?

-jon


--
To unsubscribe, e-mail:   
For additional commands, e-mail: