I think you covered RMS feelings on the issue quite well. GPL should be
used for all code and it should infect everything. Sort of like the borg.
I personally don't see the value in using GPL vs the other licenses, but I'm
a user not a developer. I can see value in the integration of tomcat or
another servlet engine and jBoss. If others can do it, but jBoss can't, it
will hurt jBoss. Maybe not alot, but it will always be a checkbox unchecked
in any evaluation.
Just my two cents
-----Original Message-----
From: Vincent Sheffer [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 30, 2000 8:31 PM
To: jBoss Developer
Subject: Re: [jBoss-Dev] Re: jboss on tomcat update
I have to confess that this is a rather disheartening response. I have
always
had a naive and obviously wrong understanding of when the virality of the
GPL
is triggered because I would have throught that the answer to all of the
questions would have been "yes, that is okay."
In my view the FSF people are taking an overly aggressive stance to try and
trigger the virality of the GPL where I wouldn't have thought it applies.
This
radical interpretation of the GPL makes it virtually unusable for any
endeavor
where you might want to use the software commercially, or in any way
combined
with non-GPL'ed software. I also wonder if this view would be upheld by the
courts.
The long and the short of it seems to be that the GPL is a hopelessly
complex
license that ensures that the software licensed under it's conditions will
be
engulfed in a legal quagmire anytime it is combined with other, non-GPL'ed
software. A most unfortunate conclusion, in my opinion.
Since it is folly to believe that the Apache group will change to the GPL it
seems the following options are the only way forward:
1.) change the jBoss license to some BSD-style license or at least dual
license jBoss.
2.) remove all of the Tomcat integration and force people to run Tomcat and
jBoss in separate VM's.
3.) blatantly ignore the legal issues and proceed forward with the
integration.
Realistically, I think the only viable option is 1.), and given the FSF's
opinion on the subject I would, in fact, welcome the license change.
I am not a member of the jBoss board, so this is just one man's opinion.
-vince
On Mon, 30 Oct 2000, you wrote:
> For what it's worth...
>
> ---------- Forwarded message ----------
> Date: Mon, 30 Oct 2000 19:03:39 -0500
> From: Free Software Foundation <[EMAIL PROTECTED]>
> To: Aaron Mulder <[EMAIL PROTECTED]>
> Subject: Re: Java, GPL, & APL
>
> Aaron Mulder wrote:
>
> > Okay, I've heard too many opinions on the GPL, so I'm taking it to
> > the source. I will discuss this in general terms if it's OK with you.
> >
> > There exist two open-source products. One uses an Apache license.
> > One uses a GPL license. They are complimentary products - the
capabilites
> > of both together are greater than that of either alone. They can be run
> > totally independently, communicating over the network, but the
performance
> > is not great. They can also be run together, in the same Java VM, and
the
> > performance is much better. The GPL product has included some code that
> > configures and launches the APL product. It directly references Java
> > classes (such as the startup class) that are part of the APL product.
> > This is what allows you to run them together within one VM. The APL
> > product does not ever reference the GPL code directly - only through the
> > standard interfaces defined by Sun in one of the javax.* packages.
After
> > the startup sequence, the GPL product never refers to the APL code
> > directly at all (essentially, the APL product is a client of the GPL
> > product).
> > So the questions are:
> >
> > 1) Is it legal for the APL product to work with the GPL product through
> > the standard interfaces defined by Sun in the javax.* packages? We
> > suspect yes, since this is a standard and the APL program never reaches
> > "through" those standard interfaces to deal directly with the GPL code.
>
> It appears that you combine the APL'ed software with the GPL'ed software
to
> form a larger program. This is not permitted, since the APL is
incompatible
> with the GPL.
>
> > 2) Is it legal for the GPL product to directly reference APL classes to
> > configure and start the APL product?
>
> No, that is not legal, because you are combining the two programs to form
a
> larger program.
>
>
> > 2b) If there is a problem with this, is there any way to configure and
> > start the two products in the same VM?
>
> Not if they make calls to each other. You'll need to get the license of
one
> or the other changed to a dual license---the disjunction of the GPL and
the
> APL.
>
>
> > 3) Would it be appropriate to package the GPL product and "glue
> > code" (startup and configuration for APL product) together, and leave
the
> > APL product separate?
>
> We believe this is legally the same as distributing them together, and
thus,
> is not permitted.
>
>
> > 4) Would it be legal to package everything together, and create one
> > combined download that "out-of-the-box" runs both products together?
This
> > is the subject of much debate.
>
> That is not permitted since the APL is incompatible with the GPL.
>
>
> > So it's not clear whether the phrase "contains or is derived
> > from" would apply to this single unified package.
>
> We argue that it definitely does, when you combine them together to form a
> larger program.
>
> --
> Bradley M. Kuhn
> Free Software Foundation | Phone: +1-617-542-5942
> 59 Temple Place, Suite 330 | Fax: +1-617-542-2652
> Boston, MA 02111-1307 USA | Web: http://www.gnu.org
