You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Guillaume Rousse <ro...@ccr.jussieu.fr> on 2002/03/12 16:05:45 UTC
License issue (the come back)
Hello.
They have been already *several* discussions about Sun proprietary APIs
licenses, and more precisely about exact redistribution conditions. Current
consensus in ASF, AFAIK, is that redistribution of crypto API (as jsse) is
strictly forbidden, and redistribution of non-crypto APIS is not permitted
with source code.
We (jpackage project, http://jpackage.sourceforge.net) contacted sun legal
department to have an official response on this topic. We exposed our own
practices, that is to provide a non-free section for all normal APIs with
standard packages, and a non-distributable section for all crypto APIs and
JDKs, with empty packages. The only response we had was: read the license
carefully :-) (kind of RTFM, actually)
So we did, and here is the result
non-free
jaas BCL + LDS
jaf BCL
javahelp BCL + LDR
javamail BCL + LDS
jaxp BCL + LDS
jdbc-stdext no license
jimi BCL + LDS
jms no license
jndi no license
jta no license
jtopen no package
jts BCL + LD
netbeans-java-extbin no license
resolver no license
non-distributable
javacc ?
jsse BCL + LD
sun-jsdk1.3 BCL + LDS + LDR
sun-jsdk1.4 BCL + LDS + LDR
blackdown-jsdk1.3 BCL + LDS + LDR
ibm-jsdk1.3 ?
BCL means standard Binary Code License, which is the basic Sun Binary Code
License for all software. Most java software add extra clauses, especially
concerning redistribution, which are refered here as LDS (License to
distribute software), LRD (License to distribute redistributables) and LD
(License to distribute). Full citations of those clauses are included at the
end of the message.
no license means "in current package" only, and ? means uncertainity.
My own interpretation follows:
1) There is nothing in any of those license making click-through procedure
mandatory
2) There is no point having jsse and jts in different section are they are
subject to exactly the same conditions
3) The US export laws enforcement clause is part of BCL, which apply to *all*
packages, not only to crypto packages.
4) LDR refers to a a "distributable" section in README file, that was not
found either in javahelp nor in JDKs
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.
Apart this problem, i still don't see what prevent distribution of all
packages having at least one of those additional distribution clause (LD or
LDS), as long as original license is preserved. LDR with a non-existent
distributable section is not acceptable here.
However, IANAL, and as I know ASF people have already stepped onto this
problem, i would like your opinion here.
Thanks for your help.
LDS
2. License to Distribute Software. Subject to the terms and conditions of
this Agreement, including, but not limited to Section 3 (Java (TM)
Technology Restrictions) of these Supplemental Terms, Sun grants you a
non-exclusive, non-transferable, limited license to reproduce and distribute
the Software in binary code form only, provided that (i) you distribute the
Software complete and unmodified and only bundled as part of, and for the
sole purpose of running, your Java applets or applications ("Programs"),
(ii) the Programs add significant and primary functionality to the Software,
(iii) you do not distribute additional software intended to replace any
component(s) of the Software, (iv) you do not remove or alter any
proprietary legends or notices contained in the Software, (v) you only
distribute the Software subject to a license agreement that protects Sun's
interests consistent with the terms contained in this Agreement, and (vi)
you agree to defend and indemnify Sun and its licensors from and against any
damages, costs, liabilities, settlement amounts and/or expenses (including
attorneys' fees) incurred in connection with any claim, lawsuit or action by
any third party that arises or results from the use or distribution of any
and all Programs and/or Software.
LD
1. License to Distribute. Sun grants you a non-exclusive,
non-transferable, royalty-free, limited license to (a) use
the binary form of the Software for the sole purpose of
designing, developing and testing your JavaTM applets and
applications intended to run on a compatible Java
environment (the "Programs"), provided that the Programs
add significant and primary functionality to the Software,
and (b) reproduce and distribute the binary form of the
Software through multiple tiers of distribution provided
that you: (i) distribute the Software complete and
unmodified; (ii) do not distribute additional software
intended to supersede any component(s) of the Software;
(iii) do not remove or alter any proprietary
legends or notices contained in or on the Software; and
(iv) only distribute the Software pursuant to a license
agreement that protects Sun's interests consistent with the
terms contained in this Agreement, and provides that Sun is
a third party beneficiary to such license agreement. If you
distribute the Software pursuant to this paragraph, you
must include the following statement as part of product
documentation (whether hard copy or electronic), as a
part of a copyright page or proprietary rights notice
page, in an "About" box or in any other form reasonably
designed to make the statement visible to users of the
Software: "This product includes code licensed from
RSA Data Security".
LDR
3. License to Distribute Redistributables. Subject to the terms and
conditions of this Agreement, including but not limited to Section 4 (Java
Technology Restrictions) of these Supplemental Terms, Sun grants you a
non-exclusive, non-transferable, limited license to reproduce and
distribute the binary form of those files specifically identified as
redistributable in the Software "README" file ("Redistributables") provided
that: (i) you distribute the Redistributables complete and unmodified
(unless otherwise specified in the applicable README file), and only
bundled as part of Programs, (ii) you do not distribute additional software
intended to supersede any component(s) of the Redistributables, (iii) you
do not remove or alter any proprietary legends or notices contained in or
on the Redistributables, (iv) you only distribute the Redistributables
pursuant to a license agreement that protects Sun's interests consistent
with the terms contained in the Agreement, and (v) you agree to defend and
indemnify Sun and its licensors from and against any damages, costs,
liabilities, settlement amounts and/or expenses (including attorneys' fees)
incurred in connection with any claim, lawsuit or action by any third party
that arises or results from the use or distribution of any and all Programs
and/or Software.
BCL export regulation clause
7. Export Regulations. All Software and technical data
delivered under this Agreement are subject to US export
control laws and may be subject to export or import
regulations in other countries. You agree to comply
strictly with all such laws and regulations and acknowledge
that you have the responsibility to obtain such licenses to
export, re-export, or import as may be required after
delivery to you.
--
Guillaume Rousse <ro...@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: License issue (the come back)
Posted by Santiago Gala <sg...@hisitech.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: License issue (the come back)
Posted by Berin Loritsch <bl...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: License issue (the come back)
Posted by Danny Angus <da...@thought.co.uk>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: License issue (the come back)
Posted by Guillaume Rousse <ro...@ccr.jussieu.fr>.
Ainsi parlait Jon Scott Stevens :
> on 3/12/02 7:05 AM, "Guillaume Rousse" <ro...@ccr.jussieu.fr> 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 <ro...@ccr.jussieu.fr>
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: License issue (the come back)
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 3/12/02 7:05 AM, "Guillaume Rousse" <ro...@ccr.jussieu.fr> 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
> jaas BCL + LDS
> jaf BCL
> javahelp BCL + LDR
> javamail BCL + LDS
> jaxp BCL + LDS
> jdbc-stdext no license
BCL
> jimi BCL + LDS
> jms no license
BCL
> jndi no license
BCL
> jta no license
> jtopen no package
> jts BCL + LD
> netbeans-java-extbin no license
> resolver no license
>
> non-distributable
> javacc ?
> jsse BCL + LD
> sun-jsdk1.3 BCL + LDS + LDR
> sun-jsdk1.4 BCL + LDS + LDR
> blackdown-jsdk1.3 BCL + LDS + LDR
> ibm-jsdk1.3 ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>