reopen 370295
thanks
Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 04, 2006 at 08:16:24AM -0700, Walter Landry wrote:
> > In the Distributor License for Java, there is the clause
> >
> > (c) you do not combine, configure or distribute the Software to
> > run in conjunction with any additional software that implements
> > the same or similar functionality or APIs as the Software;
> >
> > Debian distributes Jython, which can run with sun-java. However,
> > Jython, being a reimplementation of Python, implements a great deal of
> > similar functionality as sun-java.
>
> In Sun's, ftp-master's, nor package maintainer's opinion, this is
> something that the license is seeking to prevent at all -- see also the
> FAQ questions now included in upstream's LICENSE file (and in Debian in
> 'copyright').
The FAQ makes it clear that shipping Python and Perl are not problems.
It does not make it clear that Jython is ok, although Tom's reply
clearly states that. Not as good as I would like, but I will take it.
<snip>
> > Any libfoo-java package in Debian will run with the current installed
> > JDK. Thus, any libfoo-java package in Debian which implements "the same
> > or similar functionality" as Sun Java causes Debian to violate the
> > license on Sun Java. Obvious examples include libswingwt-java (which
> > implements much of the Swing API), libcharva1-java, libcommons-*-java
> > ("similar functionality"), Java XML processing tools that implement the
> > standard APIs, libgnu-regexp-java (since, if I recall correctly, Sun
> > Java includes regular expression handling), liboro-java (same reason),
> > libregexp-java (same reason), libgetenv-java (specifically notes itself
> > as a replacement for java.lang.System.getenv), and probably others.
>
> I don't think any of these are a violation of the license, most clearly
> as per FAQ#14.
Sun clearly does not want to allow hybrid implementations, where parts
of Sun's JDK is replaced by another. It seems they even object if the
new parts use a different namespace. From the FAQ #14
However, you can't use pieces of the JDK configured in conjunction
with any alternative technologies to create hybrid implementations,
or mingle the code from the JDK with non-JDK components of any kind
so that they run together.
All of the examples given above are good, but libgetenv-java is about
as clear as you can get. It only depends on java2-runtime and libc,
and it serves as a replacement for java.lang.System.getenv. It
creates a hybrid implementation.
If you want to argue that it is the other packages fault, go ahead.
That would make the java2-runtime virtual package much less useful, in
which case there should be a java2-runtime-free virtual package.
> Since I believe that there are no doubt-points left legal-wise,
> especially and specifically not on sun-java5 itself, I'm now closing
> this bug.
I have reopened the bug. As I noted earlier, a simple technical fix
is to make sun-java not provide java2-runtime etc.
Cheers,
Walter Landry
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
