You are viewing a plain text version of this content. The canonical link for it is here.
Posted to community@apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/02/05 18:28:01 UTC
licensing review
> Code under the ASF License is clearly OK. As is the IBM Public License
> (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> public domain components are also approved: Antlr and Doug Lea's
> concurrency package.
> Licenses clearly not conforming to the ASF's policies for distribution:
> LGPL, GPL, Sun's Binary Code License.
Please also take a look at this: http://www.gnu.org/software/classpath/.
The authors intend and believe that the exception granted allows that code
so licensed "can be used to run free as well as proprietary applications and
applets." I have spoken with Nic Ferrier about this license exception.
They specifically intend for it to remove any viral implications related to
their binary distribution, and redistribution, and they believe that it does
so.
In the specific case, this is related to the service provider example, so I
am only concerned about the permissible use of their binary jars.
If there are problems with it, please let me know the specifics so that I
can pass them on to Nic & Co.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: licensing review
Posted by Costin Manolache <co...@apache.org>.
On Wed, 5 Feb 2003, Noel J. Bergman wrote:
> > I don't get these GPL people who license their work as GPL, but don't
> > want the viral aspect...
>
> I believe that they are trying to separate the licensing of the source code
> vs. the binary. If you want to use their SOURCE, you have to keep the
> source code GPL; no proprietary changes. If you just want to use their
> BINARY, do with it as you wish, unencumbered.
>
> In any case, the only issue in my mind is receiving their binary releases
> unconstrained and unencumbered.
This is very similar with some of the other licenses from Sun ( and IBM )
that allow redistribution of the (original) binary - but don't provide the
source code under the same terms.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: licensing review
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Certainly we need an official reading on
[http://www.gnu.org/software/classpath/],
> but Classpath is specifically licensed as GPL, the least compatible
open-source
> license out there (not even a murkier LGPL).
The issues with GPL are well-known.
> The Classpath author adds an addendum to allow bundling of this library
> into an executable, but that still won't allow us to distribute jars in
> CVS or downloadable with source builds (never mind Java doesn't have
> executables).
I don't believe that to be a correct reading, but we can get additional
clarification from them. AIUI, they intend for their binaries to be freely
distributable without constraint.
> I don't get these GPL people who license their work as GPL, but don't
> want the viral aspect...
I believe that they are trying to separate the licensing of the source code
vs. the binary. If you want to use their SOURCE, you have to keep the
source code GPL; no proprietary changes. If you just want to use their
BINARY, do with it as you wish, unencumbered.
In any case, the only issue in my mind is receiving their binary releases
unconstrained and unencumbered.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: licensing review
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 5 Feb 2003, Serge Knystautas wrote:
> Certainly we need an official reading on this, but Classpath is
> specifically licensed as GPL, the least compatible open-source license
> out there (not even a murkier LGPL). The Classpath author adds an
> addendum to allow bundling of this library into an executable, but that
> still won't allow us to distribute jars in CVS or downloadable with
> source builds (never mind Java doesn't have executables). ibiblio would
> still be in violation of the license, as would CVSWeb, CVS, and anything
> that allowed these Jars to be downloaded independently.
If it's based on GPL, ie) LGPL or GPL with a clause, then until there's
any form of legal ruling on it, surely it's as good as GPL.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: licensing review
Posted by Serge Knystautas <se...@lokitech.com>.
Costin Manolache wrote:
>>Please also take a look at this: http://www.gnu.org/software/classpath/.
>>The authors intend and believe that the exception granted allows that code
>>so licensed "can be used to run free as well as proprietary applications and
>>applets." I have spoken with Nic Ferrier about this license exception.
>>They specifically intend for it to remove any viral implications related to
>>their binary distribution, and redistribution, and they believe that it does
>>so.
>>
>>In the specific case, this is related to the service provider example, so I
>>am only concerned about the permissible use of their binary jars.
>
>
> +1 - if Classpath license is found to be compatible, this will solve a lot
> of problems, as they provide alternative implementation for JNDI and
> many other APIs.
>
> I think this particular one deserves special attention !
Certainly we need an official reading on this, but Classpath is
specifically licensed as GPL, the least compatible open-source license
out there (not even a murkier LGPL). The Classpath author adds an
addendum to allow bundling of this library into an executable, but that
still won't allow us to distribute jars in CVS or downloadable with
source builds (never mind Java doesn't have executables). ibiblio would
still be in violation of the license, as would CVSWeb, CVS, and anything
that allowed these Jars to be downloaded independently.
I don't get these GPL people who license their work as GPL, but don't
want the viral aspect... The fact that they don't understand the
implications of their licensing decision doesn't make us any less liable
to use it. If a commercial EULA had a clause that the company then
stated they didn't intend, if they don't reissue the code with a
different license, the original license is still enforceable.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: licensing review
Posted by Costin Manolache <co...@apache.org>.
On Wed, 5 Feb 2003, Noel J. Bergman wrote:
> > Code under the ASF License is clearly OK. As is the IBM Public License
> > (the pre-Jakarta BSF, for example) and the MPL (Rhino). The following
> > public domain components are also approved: Antlr and Doug Lea's
> > concurrency package.
>
> > Licenses clearly not conforming to the ASF's policies for distribution:
> > LGPL, GPL, Sun's Binary Code License.
>
> Please also take a look at this: http://www.gnu.org/software/classpath/.
> The authors intend and believe that the exception granted allows that code
> so licensed "can be used to run free as well as proprietary applications and
> applets." I have spoken with Nic Ferrier about this license exception.
> They specifically intend for it to remove any viral implications related to
> their binary distribution, and redistribution, and they believe that it does
> so.
>
> In the specific case, this is related to the service provider example, so I
> am only concerned about the permissible use of their binary jars.
+1 - if Classpath license is found to be compatible, this will solve a lot
of problems, as they provide alternative implementation for JNDI and
many other APIs.
I think this particular one deserves special attention !
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org