Re: Re: License issue (the come back)

[acoliver]

>On Fri, 15 Mar 2002 16:05:41  0100 Guillaume Rousse <[EMAIL PROTECTED]>
wrote.

Correct me if I'm wrong but if you break US law while in France without
breaking any French laws and no US laws covered by extradition treaties, I
don't think you care unless you enter the US physically (and have ticked off
someone enough to notice).  I also don't think a license can bind you to
follow US law.  Moot point for me, but maybe not for others.

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

Re: License issue (the come back)

[Guillaume Rousse]

Ainsi parlait [EMAIL PROTECTED] :
> On Thu, 14 Mar 2002, GOMEZ Henri wrote:
> > >Ok, I didn't know that - and I bet many other people are in the same
> > >situation.
> > >
> > >If anyone can confirm this with a professional, then I think it should
> > >be displayed pretty clearly on a visible page, and we should find
> > >alternative open standards to use.
> >
> > jpackage need this kind of information to determine what could be
> > freely present in its rpm distribution and what should be dropped.
>
> Yes, and it's important to find out which packages are indeed based
> on open standards and remove the others imediately.
>
> Not only because it's required by the licence, but because packaging
> them might get people to use them, and that's bad.
That what we initially attempted to do , provide only free software, but we 
had to quickly adopt a less strict policy in order to have something to 
package...

> If a package is based on an open standard and a clean room
> implementation exists and is comparable with the reference and
> has better license - I think the choice should be clear too.
Sure, but that choice depends of developpers, not of packagers...

And the current question is: what to do when no alternative exists ?

>From current discussion, it seems everyone agrees main problem comes from BCL 
itself, and not additional software-specific clauses. There are actually two 
problems:
1) the "bundled as part of your software" clause
2) the "US export laws compliance" clause

My personal understanding of the BCL allows me to consider distributing 
javamail in its own package ad part of a whole distribution project comply 
with 1). And the technical issue of 2) make me thinks it is pointless anyway.

Now if someone can demonstrate me i'm wrong in either of those points, i'd be 
happy to revert to our old practice of distributing spec files only, and let 
final users build their own packages themselves.
-- 
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

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

RE: License issue (the come back)

[Stephane Bailliez]

> -Original Message-
> From: Guillaume Rousse [mailto:[EMAIL PROTECTED]]
[...]
> I know they use such kind of filtering based on your domain 
> name. It also 
> means just using a private indirection, as you did, or public 
> redirect 
> service as anonymiser.com bypass it easily.
> So we can say that Sun attempts to fulfill this clause, but 
> not that they 
> actually comply to. We could also have a banner saying "if 
> you're a evil guy 
> (as defined by US state department), please do not click 
> here" with the same 
> efficiency.

That did not prevent a French tribunal to stupidely force Yahoo to do such
filtering on french ips so that people could not see Nazi related items in
auctions even though this is absolutely impossible to comply with this (what
about aol users ? and others from company with a host located out of france
?, etc...)

Yahoo was supposed to be fine $91,000 per day of violation. Not sure what is
the status of this crap though but even if this is on, it would be piece of
cake to bypass it.

There was even an audition of Vinton Cerf which states the following in the
report:

"It has been proposed that users identify where they are at the request of
the web server, such as the one(s) serving yahoo.fr - or yahoo.com. There
are several potential problems with this approach. For one thing, users can
choose to lie about their locations. For another, every user of the web site
would have to be asked to identify his or her location since the web server
would have no way to determine a priori whether the user is French or is
using the Internet from a French location. Some users consider such
questions to be an invasion of privacy. While I am not completely acquainted
with privacy provisions in the Europe Union, it might be considered a
violation of the rights of privacy of European users, including French users
to request this in formation. Of course if this information is required
solely because of the French Court Order, one might wonder on what grounds
all other users all over the world are required to comply. 

Another complaint about the idea of asking user for their location in that
this might have to be done repeatedly by each web site that the user
accesses - yahoo cannot force every web site to make this request. When a
user first contacts the server(s) at yahoo.fr - or yahoo.com, one might
imagine that the question of geographic location might be asked and then a
piece of data called a cookie might be stored one the user's computer disk.
Repeated visits to Yahoo sites might then refer to this cookie for user
location information. The problem with this idea is that cookies are
considered by many to be an invasion of privacy also, as a result many users
either configure browsers to reject storage of cookies on their disk drives
or they clear them away after each session on the Internet - thus forcing
the query about geographical location each time the user encounters a
Yahoo-controlled web site. Again, Yahoo would have no way to force a web
site net under its control to either ask the location question or to request
a copy of the cookie 

containing the location. Indeed, it would open up a vulnerability for each
user if arbitrary web sites were told how to retrieve the cookie placed
there by the Yahoo sites. 

It has been suggested that the filtering need only apply to users accessing
the Internet from French Territories or by users who are French citizens. It
is not clear whether the jurisdiction of the French Court extends to actions
taken by French citizens who are not in French territory at the time of
their access to Internet. 

For these and many other reasons, it does not appear to be very feasible to
rely on discovering the geographic location of users for purposes of
imposing filtering of the kind described in the Court Order". 
[...]

report here:
http://www.lapres.net/html/ya2011.html


Stephane


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

Re: License issue (the come back)

[Guillaume Rousse]

Ainsi parlait Santiago Gala :
[..]
> FYI: Some time ago, I was forbidden to download a java package because
> my ISP did not have reverse DNS address mapping properly setup, even
> though I'm in Spain, not a "free world enemy", AFAIK. The message I got
> was something like "we could not assess your origin country
> satisfactorily, consult technical support". So, Sun is/was using
> technical mappings between IP block ownership and country to enforce
> such provisions. I don't know the current status.
>
> I had to ssh to a machine that was granted the permission, download from
> there, and then put it in my machine from there. I was not breaking any
> law, since I'm allowed to download it.
>
> In a sense, they do the following: if the machine used to download the
> code is in an allowed country, it is not considered export, so they
> allow it, and transfer the export responsibility further down the chain.
(sorry for this late answer)
I know they use such kind of filtering based on your domain name. It also 
means just using a private indirection, as you did, or public redirect 
service as anonymiser.com bypass it easily.
So we can say that Sun attempts to fulfill this clause, but not that they 
actually comply to. We could also have a banner saying "if you're a evil guy 
(as defined by US state department), please do not click here" with the same 
efficiency.
-- 
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

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

RE: License issue (the come back)

[costinm]

On Thu, 14 Mar 2002, Steve Downey wrote:

> You chose a definition that suits your argument. In the industry, the
> definition is usually more like:

I just used google.

> "That which is established by authority as a rule for the measure of
> quantity, extent, value, or quality; esp., the original specimen weight or
> measure sanctioned by government, as the standard pound, gallon, or yard."
> Source: Webster's Revised Unabridged Dictionary, C 1996, 1998 MICRA, Inc. 

But you need to look up 'authoritiy' first.

Your definition is wrong from start: it's Kg, Meter, Celsius degree !
That's the _standard_, sanctioned by international organizations and 
most governments :-)


> Apache httpd isn't a standard in that sense. It implements a standard, the
> HTTP standard, RFC2616, and others. Log4J isn't a standard, it's a product.

Again, that depends on the definition of the standard and the definition
of authority. 

What's the standard for networks - OSI or TCP/IP ? By your 
definition, OSI ( since ISO is a government sanctioned organization -
at least at that time IETF wasn't a big authority in comparation ).

There are few doznes organizations that self-claim the 'authority'
to create standards, and except for ISO and probably ECMA(?) I don't think  
too many are governement backed.

The authority of W3C or IETF comes from the wide acceptance of 
( some of ) their specifications. In this sense, JCP has the
same authority with for example Microsoft standards.  


> It's in wide use, but it isn't even universally used within Jakarta.
> Commons-logging is closer to a standard than Log4J. [Note, I use log4j in my
> applications. It *is* the standard that has been set within my company. That
> provides for interop between components that we develop.]

Exaclty my point. Each company and project can decide what authority
they recognize and the quality of the various (alternative) 
specifications. And it's perfectly reasonable to expect many
organizations to not recognize non-open specifications as standards,
regardless of the authority that propose it ( be it MSFT or JCP ).

( by non-open I mean specs with licences that prevent clean room
implementation, of course that would also require a dictionary search )

> Tomcat, on the other hand, is a standard. As a Reference Implementation of
> the Servlet and JSP specifications, it is authoritative when the

I don't think tomcat is a standard, but parts of it may become, if other
servers adopt it ( like webapps/ directory ).

I think Ant is a standard - at least by my definition - even if it 
doesn't claim that.

Costin  


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

Re: License issue (the come back)

[Jon Scott Stevens]

on 3/14/02 10:33 AM, "Steve Downey" <[EMAIL PROTECTED]> wrote:

> Tomcat, on the other hand, is a standard.

No. It is not. Tomcat is implementations of 'standards' that Sun defines.



For example, Catalina's implementation of a pipeline and valves is NOT
standard and if you code to those API's, you will not be able to run that
code on other containers. The only thing that is standard in that case is
the Servlet API defined Filters.

-jon


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

RE: License issue (the come back)

[Steve Downey]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 14, 2002 12:07 PM
> To: Jakarta General List
> Subject: Re: License issue (the come back)
> 
> 

> 
> Please, not another standard body !!!
> 
> Could someone check the definition of 'standard' ? 
> 
> "Something, such as a practice or a product, that is widely 
> recognized 
> or employed, especially because of its excellence"
> 
> It is not "something with the word 'standard' in the title", nor
> does it require a 'standard body' to give it this status.
> 
> Apache httpd is a standard. Log4j is a standard. At lest 1/2 
> of the stuff
> that comes out of JCP is not standard ( by this definition ), even
> if it has the word standard in title and a standard body to
> put a stamp on it.
> 
> We are talking about APIs - and my opinion is a good API 
> requires a lot of feedback and iterations - that's not 
> what the 'public review' can even be close to providing.
> No expert or expert group can substitute that, regardless
> of how good he is. 
> 
> 
> Costin
> 

You chose a definition that suits your argument. In the industry, the
definition is usually more like:
"That which is established by authority as a rule for the measure of
quantity, extent, value, or quality; esp., the original specimen weight or
measure sanctioned by government, as the standard pound, gallon, or yard."
Source: Webster's Revised Unabridged Dictionary, C 1996, 1998 MICRA, Inc. 

Apache httpd isn't a standard in that sense. It implements a standard, the
HTTP standard, RFC2616, and others. Log4J isn't a standard, it's a product.
It's in wide use, but it isn't even universally used within Jakarta.
Commons-logging is closer to a standard than Log4J. [Note, I use log4j in my
applications. It *is* the standard that has been set within my company. That
provides for interop between components that we develop.]

Tomcat, on the other hand, is a standard. As a Reference Implementation of
the Servlet and JSP specifications, it is authoritative when the
specification is silent or ambiguous. If a web app functions correctly on
Tomcat, and does not on, for example, WebSphere, then, unless Tomcat is
demonstrably not implementing the spec, WebSphere is broken. RI doesn't mean
sample code, or proof of concept, both of which are valuable, it means this
is part of the definition.



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

Re: License issue (the come back)

[costinm]

On 14 Mar 2002, Pete Chown wrote:

> Peter Donald wrote:
> 
> > ie If we could set up a decent process and work with other standards
> > organizations (ECMA, IEEE, W3C), have a relatively formal
> > participation contract (and thus *safe* from eyes of corporate/IP
> > lawyers) and finally make allies of organisations like IBM, Apple
> > and whoever else then it would be viable for many things.
> 
> This would be good.  Open source software has a strong position in the
> web marketplace.  It should be possible to use that position to gain
> influence in standards processes.  The IETF is an open body that sets
> network standards; why can't there be a similar body that standardises
> APIs?

Please, not another standard body !!!

Could someone check the definition of 'standard' ? 

"Something, such as a practice or a product, that is widely recognized 
or employed, especially because of its excellence"

It is not "something with the word 'standard' in the title", nor
does it require a 'standard body' to give it this status.

Apache httpd is a standard. Log4j is a standard. At lest 1/2 of the stuff
that comes out of JCP is not standard ( by this definition ), even
if it has the word standard in title and a standard body to
put a stamp on it.

We are talking about APIs - and my opinion is a good API 
requires a lot of feedback and iterations - that's not 
what the 'public review' can even be close to providing.
No expert or expert group can substitute that, regardless
of how good he is. 


Costin


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

RE: License issue (the come back)

[cmanolache]

On Thu, 14 Mar 2002, GOMEZ Henri wrote:

> >Ok, I didn't know that - and I bet many other people are in the same 
> >situation. 
> >
> >If anyone can confirm this with a professional, then I think it should
> >be displayed pretty clearly on a visible page, and we should find 
> >alternative open standards to use. 
> 
> jpackage need this kind of information to determine what could be
> freely present in its rpm distribution and what should be dropped.

Yes, and it's important to find out which packages are indeed based
on open standards and remove the others imediately.

Not only because it's required by the licence, but because packaging
them might get people to use them, and that's bad. 

If a package is based on an open standard and a clean room 
implementation exists and is comparable with the reference and
has better license - I think the choice should be clear too. 


Costin



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

Re: License issue (the come back)

[Pete Chown]

Peter Donald wrote:

> ie If we could set up a decent process and work with other standards
> organizations (ECMA, IEEE, W3C), have a relatively formal
> participation contract (and thus *safe* from eyes of corporate/IP
> lawyers) and finally make allies of organisations like IBM, Apple
> and whoever else then it would be viable for many things.

This would be good.  Open source software has a strong position in the
web marketplace.  It should be possible to use that position to gain
influence in standards processes.  The IETF is an open body that sets
network standards; why can't there be a similar body that standardises
APIs?

I do feel, however, that the appropriate model is the IETF, not the
W3C.  The W3C charges a fee for participation, which discriminates
against open source efforts.  It is better than JCP, but if we are
designing our own standards body why settle for second best?

The IETF has worked through the intellectual property problems.  So
for example when you attend a working group meeting you receive a
piece of paper saying that you can't do a Rambus...  The IETF will
allow patented algorithms under certain circumstances.  Of course we
are free to decide not to.  The IETF is a good model, IMHO, but we
don't have to create an exact copy.

> It still would be difficult to do anything with respect to the real
> core as Sun controls the source to a large degree.

Well, gcj is one free implementation of much of the core.  At the same
time, it would probably be unhelpful to come up with a revision of the
core J2SE standard.  It makes sense to concentrate on areas where
standards are in more of a state of flux.

-- 
Pete



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

RE: License issue (the come back)

[GOMEZ Henri]

>Ok, I didn't know that - and I bet many other people are in the same 
>situation. 
>
>If anyone can confirm this with a professional, then I think it should
>be displayed pretty clearly on a visible page, and we should find 
>alternative open standards to use. 

jpackage need this kind of information to determine what could be
freely present in its rpm distribution and what should be dropped.

What make linux so successfull ?

The concept of distribution, where someone give you the garanty that he
packages a full set of tools and products, which works fine together, and
that you could use freely to build from your own home system to a 
full enterprise architecture.

If Sun want to see more and more people use Java in enterprise, it should
really relax the distribution policies to have such distributions appears.


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

Re: License issue (the come back)

[Santiago Gala]

Guillaume Rousse wrote:

>Hello.
>
(big snip)

>
>The last point is the only real problem IMHO. Basically, it forbids to  
>export software in "free world ennemy countries TM". I don't know if making 
>somone from such a country able to download software from a website could be 
>considered software exportation, but considering the technical impossibility 
>to prevent it, i doubt Sun itself could claims to fulfill it.
>
FYI: Some time ago, I was forbidden to download a java package because 
my ISP did not have reverse DNS address mapping properly setup, even 
though I'm in Spain, not a "free world enemy", AFAIK. The message I got 
was something like "we could not assess your origin country 
satisfactorily, consult technical support". So, Sun is/was using 
technical mappings between IP block ownership and country to enforce 
such provisions. I don't know the current status.

I had to ssh to a machine that was granted the permission, download from 
there, and then put it in my machine from there. I was not breaking any 
law, since I'm allowed to download it.

In a sense, they do the following: if the machine used to download the 
code is in an allowed country, it is not considered export, so they 
allow it, and transfer the export responsibility further down the chain.

(rest snipped)


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

Re: License issue (the come back)

[Peter Donald]

On Thu, 14 Mar 2002 07:51, [EMAIL PROTECTED] wrote:
> On Thu, 14 Mar 2002, Peter Donald wrote:
> > > They still include the jaxp source code, in xml-commons.
> > > But it's a clean-room implementation, made directly from the spec.
> >
> > The "directly from the spec" is where the problem lies. It uses suns IP
> > and thus must the TCK. We don't and thus we are in violation of the
> > license and thus Apache and every user is open to being sued if sun
> > chooses to do so.
>
> This is getting intersting...

Thats one way of describing it ;)

> To be honest, I allways believed that Jaxp, and all are 'open standards'.
> ( i.e. they allow clean room implementation )

Nope ;(

> Again, we need a lawyer here - but if this is the case I think we
> should do something. There are plenty of open standards ( too many even
>
> :-), and if a spec is not open, it shouldn't be used -
>
> but an alternative (  or a new open standard ).
>
> I hear many java APIs are cloned to .net, and that a lot of .net is
> 'open standard' - I'm pretty sure it has a lot of APIs that could do
> the same thing as the non-open ones, and we can clone them in java. An
> open API/standard should be used whenever possible.

Its sad when you start thinking microsofts platform is more open :/

I think this may be an avenue depending on how the revision of the JCP goes. 
If it doesn't go well and someone with enough "political correctness" was 
willing to go for it I think it would be a very good way to progress. 

It would first be a matter of establishing relationships with other big 
players in Java world that have clout and are sympathetic to our situation. 

ie If we could set up a decent process and work with other standards 
organizations (ECMA, IEEE, W3C), have a relatively formal participation 
contract (and thus *safe* from eyes of corporate/IP lawyers) and finally make 
allies of organisations like IBM, Apple and whoever else then it would be 
viable for many things. We could even join up with existing opensource 
organizations to cross-pollinate ideas. Apache + GNU + Eclipse + Netbeans + 
JBoss would make an impressive opensource shard. IBM + Apple + others would 
make a fairly convincing commercial shard. Join em together and we have a new 
Java standards body.

It still would be difficult to do anything with respect to the real core as 
Sun controls the source to a large degree. However for many of the other 
components/add-ons then it would be quite viable to do this. Especially if 
tools like JDiff+XDoclet could auotmate most API testing and functional 
testing could be done with JUnit or some other custom framework.

It is not so much a technical problem but a marketing one. Given the right 
environment I think it could happen - best to wait and see how JCP reorg 
turns out though.

-- 
Cheers,

Pete

--
"An intellectual is someone who has been educated 
beyond their intelligence."
--

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

RE: License issue (the come back)

[Andrew C. Oliver]

My understanding is it prohibits reverse engineering copy protection...
not general things.  Also according to this notable source article:
http://www.loc.gov/copyright/1201/comments/reply/026lane.pdf
it would seem interoperability (I'd read this elsewhere as well) is
still protected.  (So sorry M$, POI's legal :-) 

-Andy

On Wed, 2002-03-13 at 12:14, Fernandez Martinez, Alejandro wrote:
> Hi Costin,
> 
> Does not the DMCA expressly prohibit reverse-engineering? Or is it just
> legaleze, not applicable in the real world?
> 
> Un saludo,
> 
> Alex.
> 
> > -Mensaje original-
> > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Enviado el: miércoles 13 de marzo de 2002 17:04
> > Para: Jakarta General List
> > Asunto: Re: License issue (the come back)
> 
> [snip]
> 
> > AFAIK ( and again don't take my word for it, call your lawyer 
> > :-), clean
> > room implementations based on a published spec are perfectly 
> > legal. Probably the name/logo is protected, but saying that your
> > code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 
> > 'compatible' ) should be ok. 
> > 
> > Costin
> > 
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: 
> > <mailto:[EMAIL PROTECTED]>
> > 
-- 
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:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: License issue (the come back)

[cmanolache]

On Thu, 14 Mar 2002, Peter Donald wrote:

> > They still include the jaxp source code, in xml-commons.
> > But it's a clean-room implementation, made directly from the spec.
> 
> The "directly from the spec" is where the problem lies. It uses suns IP and 
> thus must the TCK. We don't and thus we are in violation of the license and 
> thus Apache and every user is open to being sued if sun chooses to do so.

This is getting intersting...

To be honest, I allways believed that Jaxp, and all are 'open standards'.
( i.e. they allow clean room implementation )

Again, we need a lawyer here - but if this is the case I think we 
should do something. There are plenty of open standards ( too many even 
:-), and if a spec is not open, it shouldn't be used - 
but an alternative (  or a new open standard ).

I hear many java APIs are cloned to .net, and that a lot of .net is
'open standard' - I'm pretty sure it has a lot of APIs that could do
the same thing as the non-open ones, and we can clone them in java. An 
open API/standard should be used whenever possible.

> nope - if you use the IP then it needs to pass TCK - to do otherwise is not 
> legal. Unless we have another license agreement concerning jaxp with Sun that 
> is unpublished (as alluded to before) then we are not legal. It may be thrown 
> out in court but it is still expensive to fight it.

That's why we need the list of software/licenses that we can use and 
redistribute, and what's not on the list shouldn't be used.
Especially software that implements non-open standards. 

> > We also use a clean room implementation of JMX in tomcat, same thing
> > probably applies there.
> 
> JMX has always been under a different license and I didn't think you had a 
> clean room impl you just had some MBeans.

We use openjmx ( now called mx4j ), that's a clean-room impl of the spec
( AFAIK )


> > AFAIK ( and again don't take my word for it, call your lawyer :-), clean
> > room implementations based on a published spec are perfectly
> > legal. Probably the name/logo is protected, but saying that your
> > code implements/is based on jaxp/jmx/etc ( but is not 'certified' or
> > 'compatible' ) should be ok.
> 
> Wrong - at least as I understand the licensing issue. To implement the 
> spec(s) in many cases you must pass the TCK. It can cost a fair chunk of $ to 
> run against the TCK which pretty much excludes all opensource projects from 
> ever legally implementing different specs (ie the XML ones we do at apache).

Ok, I didn't know that - and I bet many other people are in the same 
situation. 

If anyone can confirm this with a professional, then I think it should
be displayed pretty clearly on a visible page, and we should find 
alternative open standards to use. 

Costin




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

Re: License issue (the come back)

[Peter Donald]

On Thu, 14 Mar 2002 03:04, [EMAIL PROTECTED] wrote:
> On Wed, 13 Mar 2002, Peter Donald wrote:
> > Correct - but even packages that presumably have IBM (and sun?) people
> > working on them have questionable legalities. Take xerces (or crimson),
> > at one stage they included the jaxp source code and even if it doesn't
> > anymore it surely links against it.
>
> They still include the jaxp source code, in xml-commons.
> But it's a clean-room implementation, made directly from the spec.

The "directly from the spec" is where the problem lies. It uses suns IP and 
thus must the TCK. We don't and thus we are in violation of the license and 
thus Apache and every user is open to being sued if sun chooses to do so.

> > Nor am I aware of any publically avaiable TCK for the JAXP library which
> > means that apaches xml parser is in violation of the license for JAXP
> > spec. I could be wrong but thats how I understand it and as such even
> > major projects at Apache are not legal. Fun eh?
>
> Probably it only mean it can't have a logo with 'jaxp' on it.

nope - if you use the IP then it needs to pass TCK - to do otherwise is not 
legal. Unless we have another license agreement concerning jaxp with Sun that 
is unpublished (as alluded to before) then we are not legal. It may be thrown 
out in court but it is still expensive to fight it.

> We also use a clean room implementation of JMX in tomcat, same thing
> probably applies there.

JMX has always been under a different license and I didn't think you had a 
clean room impl you just had some MBeans.

> AFAIK ( and again don't take my word for it, call your lawyer :-), clean
> room implementations based on a published spec are perfectly
> legal. Probably the name/logo is protected, but saying that your
> code implements/is based on jaxp/jmx/etc ( but is not 'certified' or
> 'compatible' ) should be ok.

Wrong - at least as I understand the licensing issue. To implement the 
spec(s) in many cases you must pass the TCK. It can cost a fair chunk of $ to 
run against the TCK which pretty much excludes all opensource projects from 
ever legally implementing different specs (ie the XML ones we do at apache).

-- 
Cheers,

Pete


"The only way to discover the limits of the possible 
is to go beyond them into the impossible." 
 -Arthur C. Clarke


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

RE: License issue (the come back)

[dirkx]

..
> I remember reading somewhere about some fair use of published
> information and books, but didn't know that this can be restricted.
> I should start reading the prefaces of the books, maybe they'll
> start including a licence and 'if you disagree with the terms, you
> must burn the book imediately'.

.. you should return this information inmediately and will be reimbursed.

Commercial in confidence.

Dw.


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

RE: License issue (the come back)

[dirkx]

> Does not the DMCA expressly prohibit reverse-engineering? Or is it just
> legaleze, not applicable in the real world?

The DMCA is about circumventing copy right protecting devices or
constructs.

Implementing a library based on a public description of an API; where this
description is obtained under a license which allows for such
implementations is a different story.

Though in this specific case - you propably may be allowed to implement it
from the API - mixing own implementation with other essential components
you have not written - i.e. packaging for distribution may be harder - as
you may not be able to add any javax classes or any third party jar with
it. Also note that there is still some complexity with regard to the above
license you get with the description - as a description -without- a
license may mean you can implement but not re-distribute those parts you
learned from the description and (c) right issues on the actual
description as carried into your implementation.

Dw.




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

RE: License issue (the come back)

[costinm]

So when someone is publishing a book he can attach a licence and restrict 
the way the information in the book is used ? 

We're not talking about copyrights here - this is not about redistributing 
the spec - but about what you can do with what you learn by reading a 
book ( or how you can listen a song, talk about it etc ).

I remember reading somewhere about some fair use of published 
information and books, but didn't know that this can be restricted.
I should start reading the prefaces of the books, maybe they'll
start including a licence and 'if you disagree with the terms, you
must burn the book imediately'. 

Costin


On Wed, 13 Mar 2002, Steve Downey wrote:

> >From http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf, the latest J2EE
> 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 solely for the purpose of 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, as
> defined by Sun, without subsetting or supersetting; (iii) includes a
> complete implementation of any optional
> components (as defined by Sun in 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 Sun); (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 with-out
> 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 termina-tion
> or expiration, you must cease use of or destroy the Specification.
> 
> 
> OTOH, this, from the JMX spec:
> 
> This document and the technology it describes are protected by copyright and
> distributed under licenses restricting their use, copying,
> distribution, and decompilation. No part of this document may be reproduced
> in any form by any means without prior written authorization of
> Sun and its licensors, if any. Third-party software, including font
> technology, is copyrighted and licensed from Sun suppliers.
> 
> 
> So it looks like clean room uncertified products that implement JMX are OK.
> They are not for J2EE. According to these licenses, in any case.
> 
> 
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 13, 2002 11:04 AM
> > To: Jakarta General List
> > Subject: Re: License issue (the come back)
> > 
> > 
> > On Wed, 13 Mar 2002, Peter Donald wrote:
> > 
> > > Correct - but even packages that presumably have IBM (and 
> > sun?) people 
> > > working on them have questionable legalities. Take xerces 
> > (or crimson), at 
> > > one stage they included the jaxp source code and even if it 
> > doesn't anymore 
> > > it surely links against it.
> > 
> > They still include the jaxp source code, in xml-commons. 
> > But it's a clean-room implementation, made directly from the spec.
> > 
> > AFAIK the people who wrote the code were not in the expert group
> > when they wrote it. It's a bit strange, since trax was incorporated
> > in jaxp1.1, but the code existed on apache even before was 
> > part of the spec.
> > 
> > 
> > > Nor am I aware of any publically avaiable TCK for the JAXP 
> > library which 
> > > means that apaches xml parser is in violation of the 
> > license for JAXP spec. I 
> > > could be wrong but thats how I understand it and as such 
> > even major projects 
> > > at Apache are not legal. Fun eh?
> > 
> &

RE: License issue (the come back)

[Steve Downey]

>From http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf, the latest J2EE
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 solely for the purpose of 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, as
defined by Sun, without subsetting or supersetting; (iii) includes a
complete implementation of any optional
components (as defined by Sun in 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 Sun); (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 with-out
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 termina-tion
or expiration, you must cease use of or destroy the Specification.


OTOH, this, from the JMX spec:

This document and the technology it describes are protected by copyright and
distributed under licenses restricting their use, copying,
distribution, and decompilation. No part of this document may be reproduced
in any form by any means without prior written authorization of
Sun and its licensors, if any. Third-party software, including font
technology, is copyrighted and licensed from Sun suppliers.


So it looks like clean room uncertified products that implement JMX are OK.
They are not for J2EE. According to these licenses, in any case.





> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 13, 2002 11:04 AM
> To: Jakarta General List
> Subject: Re: License issue (the come back)
> 
> 
> On Wed, 13 Mar 2002, Peter Donald wrote:
> 
> > Correct - but even packages that presumably have IBM (and 
> sun?) people 
> > working on them have questionable legalities. Take xerces 
> (or crimson), at 
> > one stage they included the jaxp source code and even if it 
> doesn't anymore 
> > it surely links against it.
> 
> They still include the jaxp source code, in xml-commons. 
> But it's a clean-room implementation, made directly from the spec.
> 
> AFAIK the people who wrote the code were not in the expert group
> when they wrote it. It's a bit strange, since trax was incorporated
> in jaxp1.1, but the code existed on apache even before was 
> part of the spec.
> 
> 
> > Nor am I aware of any publically avaiable TCK for the JAXP 
> library which 
> > means that apaches xml parser is in violation of the 
> license for JAXP spec. I 
> > could be wrong but thats how I understand it and as such 
> even major projects 
> > at Apache are not legal. Fun eh?
> 
> Probably it only mean it can't have a logo with 'jaxp' on it.
> 
> We also use a clean room implementation of JMX in tomcat, same thing
> probably applies there. 
> 
> AFAIK ( and again don't take my word for it, call your lawyer 
> :-), clean
> room implementations based on a published spec are perfectly 
> legal. Probably the name/logo is protected, but saying that your
> code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 
> 'compatible' ) should be ok. 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

RE: License issue (the come back)

[Fernandez Martinez, Alejandro]

That's good news. Thanks a lot,

Alex.

> -Mensaje original-
> De: Jon Scott Stevens [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 13 de marzo de 2002 18:52
> Para: [EMAIL PROTECTED]
> Asunto: Re: License issue (the come back)
> 
> 
> on 3/13/02 9:31 AM, "[EMAIL PROTECTED]" 
> <[EMAIL PROTECTED]> wrote:
> 
> > Implementing a published API/specification have nothing to do with
> > reverse-engineering and I don't think it is prohibited.
> 
> Nope. It isn't. I re-implemented a BEA specification (dbKona) 
> based on their
> publicly available javadoc's.
> 
> <http://share.whichever.com/index.php?SCREEN=village>
> 
> -jon
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: License issue (the come back)

[Jon Scott Stevens]

on 3/13/02 9:31 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Implementing a published API/specification have nothing to do with
> reverse-engineering and I don't think it is prohibited.

Nope. It isn't. I re-implemented a BEA specification (dbKona) based on their
publicly available javadoc's.



-jon


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

RE: License issue (the come back)

[costinm]

On Wed, 13 Mar 2002, Fernandez Martinez, Alejandro wrote:

> Does not the DMCA expressly prohibit reverse-engineering? Or is it just
> legaleze, not applicable in the real world?

Implementing a published API/specification have nothing to do with 
reverse-engineering and I don't think it is prohibited.

What seems to be prohibited by the words in the licence is distributing
a BCL jar togheter with a clean-room implementation of another spec
( which require implementing javax./java. classes ).

Costin


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

RE: License issue (the come back)

[Fernandez Martinez, Alejandro]

Hi Costin,

Does not the DMCA expressly prohibit reverse-engineering? Or is it just
legaleze, not applicable in the real world?

Un saludo,

Alex.

> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 13 de marzo de 2002 17:04
> Para: Jakarta General List
> Asunto: Re: License issue (the come back)

[snip]

> AFAIK ( and again don't take my word for it, call your lawyer 
> :-), clean
> room implementations based on a published spec are perfectly 
> legal. Probably the name/logo is protected, but saying that your
> code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 
> 'compatible' ) should be ok. 
> 
> Costin
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 

Re: License issue (the come back)

[costinm]

On Wed, 13 Mar 2002, Peter Donald wrote:

> Correct - but even packages that presumably have IBM (and sun?) people 
> working on them have questionable legalities. Take xerces (or crimson), at 
> one stage they included the jaxp source code and even if it doesn't anymore 
> it surely links against it.

They still include the jaxp source code, in xml-commons. 
But it's a clean-room implementation, made directly from the spec.

AFAIK the people who wrote the code were not in the expert group
when they wrote it. It's a bit strange, since trax was incorporated
in jaxp1.1, but the code existed on apache even before was 
part of the spec.


> Nor am I aware of any publically avaiable TCK for the JAXP library which 
> means that apaches xml parser is in violation of the license for JAXP spec. I 
> could be wrong but thats how I understand it and as such even major projects 
> at Apache are not legal. Fun eh?

Probably it only mean it can't have a logo with 'jaxp' on it.

We also use a clean room implementation of JMX in tomcat, same thing
probably applies there. 

AFAIK ( and again don't take my word for it, call your lawyer :-), clean
room implementations based on a published spec are perfectly 
legal. Probably the name/logo is protected, but saying that your
code implements/is based on jaxp/jmx/etc ( but is not 'certified' or 
'compatible' ) should be ok. 

Costin


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

RE: License issue (the come back)

[Stephane Bailliez]

> -Original Message-
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
[...]
> I presume there is some form of implied consent/licensing or 
> somethin gthat 
> may hold up if it ever went to court but even then I really 
> dislike the fact 
> that we have to rely on the good will of a company not to sue 
> apache or even 
> worse to sue Apaches users ;(
> 
> Then again IANAL and could be completely wrong? Anyone want 
> to explain why I am wrong? :)

I believe this is somewhat the same mess about GPL and dynamic linking.
http://lwn.net/2001/0628/a/esr-modules.php3

No one is able to figure what it means and from what I understand from Eric
Raymond post this is somewhat 'oh wait, I'm saying this but this is subject
to change anytime and anyway this can be overruled by a legal decision some
day depending on how they interpret it. For now I say this but eh, good
luck.'

Awesome.

All this 'smoke' is I believe absolutely intentional to reserve room for
future legal actions in case an entity becomes a little bit 'annoying'.

Stephane

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

Re: License issue (the come back)

[Peter Donald]

On Wed, 13 Mar 2002 11:41, [EMAIL PROTECTED] wrote:
> BTW, the clause 'complete and unmodified' is very interesting - does it
> refers to the jar or the whole binary package ( most people refer to the
> whole downloaded package as 'software', and the jar is a piece of it ).
> If so, tomcat and most other packages that include it are breaking
> the licences, since they repackage and include only the jar.
> 'Software' is previously defined as 'accompanying software
> and documentation and any error corrections provided by Sun (collectively
> "Software")

yep ;)

> Even more fun is the restriction on creating 'java., javax., or sun.'
> packages. Does it mean that you're not allowed to include open source
> ( and clean room ) implementations of javax. pacakges if you include
> one of those licences ?

yep.

> The only possible conclusion is that software shouldn't be redistributed
> without a lawyer checking and aproving every included license, and
> we need a list of licenses that are acceptable for inclusion on
> packages we distribute ( from jakarta, xml, etc ), verified by a lawyer.

Correct - but even packages that presumably have IBM (and sun?) people 
working on them have questionable legalities. Take xerces (or crimson), at 
one stage they included the jaxp source code and even if it doesn't anymore 
it surely links against it.

However I can't see how this is even vaguely legal - due to the licensing 
issues brought up recently wrt the JCP process. It uses the products of the 
JCP and I am not aware of any different licensing policy for the jaxp stuff. 
Nor am I aware of any publically avaiable TCK for the JAXP library which 
means that apaches xml parser is in violation of the license for JAXP spec. I 
could be wrong but thats how I understand it and as such even major projects 
at Apache are not legal. Fun eh?

I presume there is some form of implied consent/licensing or somethin gthat 
may hold up if it ever went to court but even then I really dislike the fact 
that we have to rely on the good will of a company not to sue apache or even 
worse to sue Apaches users ;(

Then again IANAL and could be completely wrong? Anyone want to explain why I 
am wrong? :)

-- 
Cheers,

Pete

"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
J.R. "Bob" Dobbs


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

Re: License issue (the come back)

[Guillaume Rousse]

Ainsi parlait GOMEZ Henri :
> >We have setup [EMAIL PROTECTED] for that reason (this is
> >also commonly
> >discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and
>
> both list are not available to basic commiters ?
But the first one is:
try [EMAIL PROTECTED]
-- 
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

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

Re: License issue (the come back)

[Guillaume Rousse]

Ainsi parlait [EMAIL PROTECTED] :
> > The BCL states that you cannot make a distribution of the .jar file
> > outside of your product. In other words, if you want to distribute the
> > single .jar file, you can't do that.
> >
> > "(i) distribute the Software complete and unmodified and only bundled as
> > part of your Programs"
Well, the very reason that we package this proprietary stuff is precisely 
that they are needed by other packages (otherwise we wouldn't provide them). 
So even if included in separate files, they are actually distributed as 
dependencies of other softwares. If "our program" is our complete set of 
packages, we could consider them as bundled inside.

[..]
> BTW, the clause 'complete and unmodified' is very interesting - does it
> refers to the jar or the whole binary package ( most people refer to the
> whole downloaded package as 'software', and the jar is a piece of it ).
> If so, tomcat and most other packages that include it are breaking
> the licences, since they repackage and include only the jar.
> 'Software' is previously defined as 'accompanying software
> and documentation and any error corrections provided by Sun (collectively
> "Software")
Right, and providing them in full packages with documentation, license and 
other original files, as we do, is more respectful in this regard.
-- 
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

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

RE: License issue (the come back)

[dirkx]

...
> >- I looked at the license and the words
> >Ex: "You have chosen to download Java(TM) Message
> >Service (JMS) API
> > -- Javadoc 1.0.2b
> > Sun Microsystems, Inc.
> > Binary Code License Agreement"

Two things - the mailing list [EMAIL PROTECTED] is more geared towards
this and filled with people who actually enjoy these things.

Secondly - the license you see in the above case is *NOT* the license the
ASF needs to be able ot distribute.

What you see is the license under which you, the end user, gets the code.
This is not nessesarily the same as the license needed by an entity such
as the ASF to re-distrubute code.

In the open source world, e.g. with an ASF license, it happens to be that
those two are identical - but in the general case, and sepcifically in the
case of SUN, that is not so. For this reason we actually have several
contracts negotiated out of band with SUN to this effect.

Dw


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

Re: License issue (the come back)

[Guillaume Rousse]

Ainsi parlait Jon Scott Stevens :
> on 3/12/02 7:05 AM, "Guillaume Rousse" <[EMAIL PROTECTED]> wrote:
> > So we did, and here is the result
>
> You didn't find licenses for a lot of software that has licenses...instead
> of saying 'no license' which implies that it does not have a license, you
> should have stated ('could not find a license')...
>
> I went through the java.sun.com website and in about 30 seconds found the
> licenses for the first 3 'no license' items below...you can do the rest of
> the work...
As stated in my original mail :
no license means "in current package" only

Real problem is not to have exhaustive list, but to discuss the correct 
behaviour to adopt regarding a given license combination.
-- 
Guillaume Rousse <[EMAIL PROTECTED]>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

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

RE: License issue (the come back)

[GOMEZ Henri]

>We have setup [EMAIL PROTECTED] for that reason (this is 
>also commonly
>discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and 

both list are not available to basic commiters ?

>have setup pages
>like this one to help us track things...
>
>http://jakarta.apache.org/site/jars.html
>

Yes, but how could I find this page from homepage ?

BTW, you could add to jaf exclusion :

jaas, javahelp, javamail, jdbc-stdext, jimi, jms, jta, jts

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

RE: License issue (the come back)

[GOMEZ Henri]

>
>It has nothing to do with language barriers or who I know.
>
>- I went to each product on Sun's website.
>Ex: 

ok

>- I clicked the 'Download' link on the left side navigation.
>Ex: 

ok

>- I clicked the 'continue' button on the page.
>Ex: "Download the version 1.0.2b Source, API 
>Documentation and Jar
> (the jar file has been added)"

ok

>- I looked at the license and the words
>Ex: "You have chosen to download Java(TM) Message 
>Service (JMS) API
> -- Javadoc 1.0.2b
> Sun Microsystems, Inc.
> Binary Code License Agreement"

And then you have to understand what is exactly BCL.
I'm not a lawyer, english is not my primary language sorry,
so 2 reasons to be more than carefull

>> BTW, Guillaume and I want to know if we could or couldn't
>> make the Sun jars available via jpackage project next
>> to others free jars, with the final goal to have a ready
>> to use Java distribution which will be a great benefits
>> for all the Java community, both developpers and users.
>
>The BCL states that you cannot make a distribution of the .jar 
>file outside
>of your product. In other words, if you want to distribute the 
>single .jar
>file, you can't do that.

Ok, so you confirm us that the Sun jars couldn't be used outside
a real program and as such couldn't be part of a RPM distribution ?
But what happen if that distribution use these jars (ie javamail)
for REAL program (like Tomcat 4.x) ?

>"(i) distribute the Software complete and unmodified and only 
>bundled as
>part of your Programs"

'Part of my program', could we see a distribution as a set of 
programs depending on BCL jars for both build, install and
runtime ?

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

Re: License issue (the come back)

[Jon Scott Stevens]

on 3/12/02 5:02 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> The problem is that the list should be reversed - i.e. what licences
> are _allowed_ and verified by a lawyer.
> 
> And we have 2 issues - what jars are allowed in CVS, and what jars
> are allowed in the binary software we distribute.
> 
> Costin

We welcome your contributions.

-jon


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

Re: License issue (the come back)

[costinm]

On Tue, 12 Mar 2002, Jon Scott Stevens wrote:

> http://jakarta.apache.org/site/jars.html

The problem is that the list should be reversed - i.e. what licences
are _allowed_ and verified by a lawyer. 

And we have 2 issues - what jars are allowed in CVS, and what jars 
are allowed in the binary software we distribute. 

Costin


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

Re: License issue (the come back)

[Jon Scott Stevens]

on 3/12/02 4:41 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> The only possible conclusion is that software shouldn't be redistributed
> without a lawyer checking and aproving every included license, and
> we need a list of licenses that are acceptable for inclusion on
> packages we distribute ( from jakarta, xml, etc ), verified by a lawyer.
> 
> Costin

Correct.

We have setup [EMAIL PROTECTED] for that reason (this is also commonly
discussed on [EMAIL PROTECTED] and [EMAIL PROTECTED]) and have setup pages
like this one to help us track things...

http://jakarta.apache.org/site/jars.html

-jon


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

Re: License issue (the come back)

[cmanolache]

> The BCL states that you cannot make a distribution of the .jar file outside
> of your product. In other words, if you want to distribute the single .jar
> file, you can't do that.
> 
> "(i) distribute the Software complete and unmodified and only bundled as
> part of your Programs"

What about a dummy program - say "Linux java installer" - with minimal 
code ?
If this is not acceptable, you can probably just redistribute ant or 
tomcat4, which make use of almost all those packages. Ant is the best 
vehicle, and very usefull to have it installed anyway. 

BTW, the clause 'complete and unmodified' is very interesting - does it
refers to the jar or the whole binary package ( most people refer to the
whole downloaded package as 'software', and the jar is a piece of it ).  
If so, tomcat and most other packages that include it are breaking
the licences, since they repackage and include only the jar.
'Software' is previously defined as 'accompanying software 
and documentation and any error corrections provided by Sun (collectively 
"Software")

Even more fun is the restriction on creating 'java., javax., or sun.' 
packages. Does it mean that you're not allowed to include open source
( and clean room ) implementations of javax. pacakges if you include
one of those licences ? 

The only possible conclusion is that software shouldn't be redistributed
without a lawyer checking and aproving every included license, and 
we need a list of licenses that are acceptable for inclusion on 
packages we distribute ( from jakarta, xml, etc ), verified by a lawyer.

Costin


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

Re: License issue (the come back)

[Jon Scott Stevens]

on 3/12/02 1:13 PM, "GOMEZ Henri" <[EMAIL PROTECTED]> wrote:

>> I went through the java.sun.com website and in about 30
>> seconds found the
>> licenses for the first 3 'no license' items below...you can do
>> the rest of
>> the work...
> 
> Could you help us in such works since :
> 
> - you were damn't fast on such hard task
> - you have many friends at Sun which could help you
> 
> Don't forget that Guillaume and I are french and we may
> have sometimes problems in understanding all the subtilities
> of all the Sun licenses in english only.
> 
> We'll be more than happy to have a french version of them.
> 
> Nota that many others companies like IBM provide license
> in several languages to help their users / customers...

It has nothing to do with language barriers or who I know.

- I went to each product on Sun's website.
Ex: 
- I clicked the 'Download' link on the left side navigation.
Ex: 
- I clicked the 'continue' button on the page.
Ex: "Download the version 1.0.2b Source, API Documentation and Jar
 (the jar file has been added)"
- I looked at the license and the words
Ex: "You have chosen to download Java(TM) Message Service (JMS) API
 -- Javadoc 1.0.2b
 Sun Microsystems, Inc.
 Binary Code License Agreement"

> BTW, Guillaume and I want to know if we could or couldn't
> make the Sun jars available via jpackage project next
> to others free jars, with the final goal to have a ready
> to use Java distribution which will be a great benefits
> for all the Java community, both developpers and users.

The BCL states that you cannot make a distribution of the .jar file outside
of your product. In other words, if you want to distribute the single .jar
file, you can't do that.

"(i) distribute the Software complete and unmodified and only bundled as
part of your Programs"

-jon


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

RE: License issue (the come back)

[GOMEZ Henri]

>I went through the java.sun.com website and in about 30 
>seconds found the
>licenses for the first 3 'no license' items below...you can do 
>the rest of
>the work...

Could you help us in such works since :

- you were damn't fast on such hard task
- you have many friends at Sun which could help you 

Don't forget that Guillaume and I are french and we may 
have sometimes problems in understanding all the subtilities
of all the Sun licenses in english only.

We'll be more than happy to have a french version of them.

Nota that many others companies like IBM provide license 
in several languages to help their users / customers...

BTW, Guillaume and I want to know if we could or couldn't
make the Sun jars available via jpackage project next
to others free jars, with the final goal to have a ready
to use Java distribution which will be a great benefits
for all the Java community, both developpers and users.

 

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

Re: License issue (the come back)

[Jon Scott Stevens]

on 3/12/02 7:05 AM, "Guillaume Rousse" <[EMAIL PROTECTED]> wrote:

> So we did, and here is the result

You didn't find licenses for a lot of software that has licenses...instead
of saying 'no license' which implies that it does not have a license, you
should have stated ('could not find a license')...

I went through the java.sun.com website and in about 30 seconds found the
licenses for the first 3 'no license' items below...you can do the rest of
the work...

> non-free
> jaasBCL + LDS
> jafBCL
> javahelpBCL + LDR
> javamail BCL + LDS
> jaxpBCL + LDS
> jdbc-stdext no license

BCL

> jimiBCL + LDS
> jmsno license

BCL

> jndino license

BCL

> jtano license
> jtopenno package
> jtsBCL + LD
> netbeans-java-extbinno license
> resolverno license
> 
> non-distributable
> javacc?
> jsseBCL + LD
> sun-jsdk1.3 BCL + LDS + LDR
> sun-jsdk1.4BCL + LDS + LDR
> blackdown-jsdk1.3 BCL + LDS + LDR
> ibm-jsdk1.3?


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

Re: License issue (the come back)

[Berin Loritsch]

Danny Angus wrote:
>>The last point is the only real problem IMHO. Basically, it forbids to
>>export software in "free world ennemy countries TM". I don't know
>>if making
>>somone from such a country able to download software from a
>>website could be
>>considered software exportation, but considering the technical
>>impossibility
>>to prevent it, i doubt Sun itself could claims to fulfill it.
> 
> 
> On the other hand it would be hard to prove that you exported it yourself to
> a banned country, and didn't provide it to a user in the continental US who
> then sent it abroad.
> It certainly seems unworkable in principle, and as a foreigner I wonder what
> the US lawmakers would consider to be adequate protection against
> downloading by evil foreigners.
> You can pretty much bet the farm that terrorists won't let licence
> conditions stop their plans.


Then again, you can pretty much bet the farm that they aren't using Java
anyways.  Terrorists that use encryption are likely to use more powerful
russian (FSU?) encryption suites.  They also are not interested in
development, or ease of use.  They are interested in weapons and causing
damage.


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
 - Benjamin Franklin


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

RE: License issue (the come back)

[Danny Angus]

> The last point is the only real problem IMHO. Basically, it forbids to
> export software in "free world ennemy countries TM". I don't know
> if making
> somone from such a country able to download software from a
> website could be
> considered software exportation, but considering the technical
> impossibility
> to prevent it, i doubt Sun itself could claims to fulfill it.

On the other hand it would be hard to prove that you exported it yourself to
a banned country, and didn't provide it to a user in the continental US who
then sent it abroad.
It certainly seems unworkable in principle, and as a foreigner I wonder what
the US lawmakers would consider to be adequate protection against
downloading by evil foreigners.
You can pretty much bet the farm that terrorists won't let licence
conditions stop their plans.

d.


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