You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rpc-dev@xml.apache.org by Nicolas RAOUL <ni...@makina-corpus.com> on 2002/10/31 13:44:24 UTC
GNU-GPL compatibility question
John Wilson's license states:
"Redistributions in binary form must reproduce the
above copyright notice, this list of conditions and
the following disclaimer in the documentation and/or
other materials provided with the distribution."
My java project include the xmlrpc-1.1.jar, so it also includes MinML, which has a BSD-like license.
Can I release and distribute my project under the GNU-GPL license ?
Can I apply the GNU-GPL to my own code and ship it in a tar.gz including xmlrpc-1.1.jar ?
In that case, can I say "myproject is GNU GPL licensed" ?
Thanks.
Re: GNU-GPL compatibility question
Posted by John Wilson <tu...@wilson.co.uk>.
Nicolas RAOUL wrote:
> John Wilson's license states:
> "Redistributions in binary form must reproduce the
> above copyright notice, this list of conditions and
> the following disclaimer in the documentation and/or
> other materials provided with the distribution."
>
> My java project include the xmlrpc-1.1.jar, so it also includes
> MinML, which has a BSD-like license.
>
> Can I release and distribute my project under the GNU-GPL license ?
I beleive that this does cause problems for GNU programs.
I will release the next version under the version of the BSD licence which
does not have this clasue.
If you wish I would be very happy to send you a MinML release under this
licence if you contact me off list.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: GNU-GPL compatibility question
Posted by John Wilson <tu...@wilson.co.uk>.
Nicolas RAOUL wrote:
> John Wilson's license states:
> "Redistributions in binary form must reproduce the
> above copyright notice, this list of conditions and
> the following disclaimer in the documentation and/or
> other materials provided with the distribution."
>
> My java project include the xmlrpc-1.1.jar, so it also includes
> MinML, which has a BSD-like license.
>
> Can I release and distribute my project under the GNU-GPL license ?
I beleive that this does cause problems for GNU programs.
I will release the next version under the version of the BSD licence which
does not have this clasue.
If you wish I would be very happy to send you a MinML release under this
licence if you contact me off list.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Sounds like I'm not the only outsider interested in this code! How
> >about a short-lived CLIENT_REFACTORING branch in CVS? We could give
> >Ryan commit access, and you guys could proceed with the development
> >from here on out in ASF CVS. Everyone would be free to comment, and
> >we can merge into the mainline when you think things are ready. I'd
> >be happy to help with any CVS/branching/merging issues. Thoughts?
> >
> Well we are having a bit of a feature creep here. It is no longer
> just CLIENT_REFACTORING as we are looking at abstracting the transport
> layer for the XmlRpcServer code as well. I would be interested in
> having this code up in CVS somewhere, although I've never worked with
> CVS branches before.
Working with branches mostly involves appending -rBRANCH_NAME to your
cvs checkout and update commands. Eventually, you learn how to use
update -j to merge branches together.
> Another thing I'm not sure about is design documentation. Sometimes
> it helps me to draw up larger refactorings like this one in quasi-UML
> so I can see the bigger picture. If I do this, do I store the
> .VSD/.PNGs in CVS somewhere? Where? It would be nice to have them as
> a resource when we are talking over some of the design decisions we
> are making.
Yes, they should live in the repository, possibly under xdocs/
(assuming they have associated content).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Daniel Rall wrote:
>
> >Sounds like I'm not the only outsider interested in this code! How
> >about a short-lived CLIENT_REFACTORING branch in CVS? We could give
> >Ryan commit access, and you guys could proceed with the development
> >from here on out in ASF CVS. Everyone would be free to comment, and
> >we can merge into the mainline when you think things are ready. I'd
> >be happy to help with any CVS/branching/merging issues. Thoughts?
> >
> Well we are having a bit of a feature creep here. It is no longer
> just CLIENT_REFACTORING as we are looking at abstracting the transport
> layer for the XmlRpcServer code as well. I would be interested in
> having this code up in CVS somewhere, although I've never worked with
> CVS branches before.
Working with branches mostly involves appending -rBRANCH_NAME to your
cvs checkout and update commands. Eventually, you learn how to use
update -j to merge branches together.
> Another thing I'm not sure about is design documentation. Sometimes
> it helps me to draw up larger refactorings like this one in quasi-UML
> so I can see the bigger picture. If I do this, do I store the
> .VSD/.PNGs in CVS somewhere? Where? It would be nice to have them as
> a resource when we are talking over some of the design decisions we
> are making.
Yes, they should live in the repository, possibly under xdocs/
(assuming they have associated content).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Sounds like I'm not the only outsider interested in this code! How
>about a short-lived CLIENT_REFACTORING branch in CVS? We could give
>Ryan commit access, and you guys could proceed with the development
>from here on out in ASF CVS. Everyone would be free to comment, and
>we can merge into the mainline when you think things are ready. I'd
>be happy to help with any CVS/branching/merging issues. Thoughts?
>
Well we are having a bit of a feature creep here. It is no longer just
CLIENT_REFACTORING as we are looking at abstracting the transport layer
for the XmlRpcServer code as well. I would be interested in having this
code up in CVS somewhere, although I've never worked with CVS branches
before.
Another thing I'm not sure about is design documentation. Sometimes it
helps me to draw up larger refactorings like this one in quasi-UML so I
can see the bigger picture. If I do this, do I store the .VSD/.PNGs in
CVS somewhere? Where? It would be nice to have them as a resource when
we are talking over some of the design decisions we are making.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
>
>
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Daniel Rall wrote:
>Sounds like I'm not the only outsider interested in this code! How
>about a short-lived CLIENT_REFACTORING branch in CVS? We could give
>Ryan commit access, and you guys could proceed with the development
>from here on out in ASF CVS. Everyone would be free to comment, and
>we can merge into the mainline when you think things are ready. I'd
>be happy to help with any CVS/branching/merging issues. Thoughts?
>
Well we are having a bit of a feature creep here. It is no longer just
CLIENT_REFACTORING as we are looking at abstracting the transport layer
for the XmlRpcServer code as well. I would be interested in having this
code up in CVS somewhere, although I've never worked with CVS branches
before.
Another thing I'm not sure about is design documentation. Sometimes it
helps me to draw up larger refactorings like this one in quasi-UML so I
can see the bigger picture. If I do this, do I store the .VSD/.PNGs in
CVS somewhere? Where? It would be nice to have them as a resource when
we are talking over some of the design decisions we are making.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
>
>
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > I have the CLDC code, but didn't find the interface. Is it hidden in
> > CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> > recollection is that there are plans for this that will modify it
> > significantly.
>
> Ryan and I are sharing code via private email at the moment.
Sounds like I'm not the only outsider interested in this code! How
about a short-lived CLIENT_REFACTORING branch in CVS? We could give
Ryan commit access, and you guys could proceed with the development
from here on out in ASF CVS. Everyone would be free to comment, and
we can merge into the mainline when you think things are ready. I'd
be happy to help with any CVS/branching/merging issues. Thoughts?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Andrew Evers" <ae...@redwood.nl> writes:
> > I have the CLDC code, but didn't find the interface. Is it hidden in
> > CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> > recollection is that there are plans for this that will modify it
> > significantly.
>
> Ryan and I are sharing code via private email at the moment.
Sounds like I'm not the only outsider interested in this code! How
about a short-lived CLIENT_REFACTORING branch in CVS? We could give
Ryan commit access, and you guys could proceed with the development
from here on out in ASF CVS. Everyone would be free to comment, and
we can merge into the mainline when you think things are ready. I'd
be happy to help with any CVS/branching/merging issues. Thoughts?
--
Daniel Rall <dl...@finemaltcoding.com>
Re: XmlRpcClient Interface
Posted by Andrew Evers <ae...@redwood.nl>.
> I have the CLDC code, but didn't find the interface. Is it hidden in
> CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> recollection is that there are plans for this that will modify it
> significantly.
Ryan and I are sharing code via private email at the moment.
> This is the gist of the modifications. I removed the superclass
> (XmlRpcClient) and copied a couple of methods across and removed the
> superclass of LiteWorker (Worker) and copied some methods. I think
> that I also trashed the Async code. There are minor changes to
> XmlRpc.java (removing "properties"), other than that, you need
> Base64.java, ServerInputStream.java and XmlRpcException.java which
> compile unchanged. I think that there also some supporting classes
> that we had already created (StringTokenizer?), maybe others.
> References to URL and associated exceptions have been removed, if we
> need these to match a new interface (likely) we will need to create
> substitutes.
>
> If anyone else has an immediate interest in this code, let me know.
> I'll be testing over this week, the goal is to get it on the
> iPaq/Jeode.
I wouldn't mind seeing a copy (either a unidiff against HEAD or a
..jar of .java files). I can tell you fairly quickly how easy it would
be to integrate this.
I've not done any CLDC programming myself. What are the constraints we
are looking at? How important is code size, and the number of classes?
are there particular classes that we are using that aren't available
under CLDC?
>>> I only vaguely remember the discussion of adding an interface for
>>> the client. Can someone provide a quick synopsis and the status?
Well, the idea is to split the XML-RPC and HTTP processing. The
XML-RPC processing on the client side will be done in a similar
manner to the server side code in HEAD. There are three new classes:
XmlRpcClientRequestProcessor, XmlRpcClientResponseProcessor and
XmlRpcClientWorker. These contain the request/response/worker
code that was common to XmlRpcClient and XmlRpcClientLite. Look how
this is done on the server for an idea.
The HTTP processing is handled by having XmlRpcClient make a call
to an XmlRpcTransport instance:
public InputStream sendXmlRpc(byte [] request)
throws IOException, XmlRpcClientException;
Creation of these instances is via a factory method in XmlRpcClient:
protected XmlRpcTransport createTransport()
The default is to create a new transport (== new connection) for
each XML-RPC. It is possible to set things up to do XML-RPC on
a persistent connection.
>>> It just became relevent to me because I have a need for a CLDC
>>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>>> (just about) CLDC compliant, if I can easily convert the
>>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>>> this, I might as well make it compliant with the forthcoming
>>> interface.
The solution may be to create an org.apache.xmlrpc.cldc.CLDCXmlRpcClient
class that depends on the MinML package, and a subset of the core
org.apache.xmlrpc package:
XmlRpc
XmlRpcException
XmlRpcClientRequestProcessor (see above)
XmlRpcClientResponseProcessor (see above)
HttpClient (I've factored this out of XmlRpcClientLite).
Base64
ServerInputStream
This would have no main(), no asynchronous handling, no workers or
worker stack, etc. But, it would be _very_ small.
Andrew.
Re: XmlRpcClient Interface
Posted by Andrew Evers <ae...@redwood.nl>.
> I have the CLDC code, but didn't find the interface. Is it hidden in
> CVS or elsewhere? Also I modified the XmlRpcClientLite, my
> recollection is that there are plans for this that will modify it
> significantly.
Ryan and I are sharing code via private email at the moment.
> This is the gist of the modifications. I removed the superclass
> (XmlRpcClient) and copied a couple of methods across and removed the
> superclass of LiteWorker (Worker) and copied some methods. I think
> that I also trashed the Async code. There are minor changes to
> XmlRpc.java (removing "properties"), other than that, you need
> Base64.java, ServerInputStream.java and XmlRpcException.java which
> compile unchanged. I think that there also some supporting classes
> that we had already created (StringTokenizer?), maybe others.
> References to URL and associated exceptions have been removed, if we
> need these to match a new interface (likely) we will need to create
> substitutes.
>
> If anyone else has an immediate interest in this code, let me know.
> I'll be testing over this week, the goal is to get it on the
> iPaq/Jeode.
I wouldn't mind seeing a copy (either a unidiff against HEAD or a
..jar of .java files). I can tell you fairly quickly how easy it would
be to integrate this.
I've not done any CLDC programming myself. What are the constraints we
are looking at? How important is code size, and the number of classes?
are there particular classes that we are using that aren't available
under CLDC?
>>> I only vaguely remember the discussion of adding an interface for
>>> the client. Can someone provide a quick synopsis and the status?
Well, the idea is to split the XML-RPC and HTTP processing. The
XML-RPC processing on the client side will be done in a similar
manner to the server side code in HEAD. There are three new classes:
XmlRpcClientRequestProcessor, XmlRpcClientResponseProcessor and
XmlRpcClientWorker. These contain the request/response/worker
code that was common to XmlRpcClient and XmlRpcClientLite. Look how
this is done on the server for an idea.
The HTTP processing is handled by having XmlRpcClient make a call
to an XmlRpcTransport instance:
public InputStream sendXmlRpc(byte [] request)
throws IOException, XmlRpcClientException;
Creation of these instances is via a factory method in XmlRpcClient:
protected XmlRpcTransport createTransport()
The default is to create a new transport (== new connection) for
each XML-RPC. It is possible to set things up to do XML-RPC on
a persistent connection.
>>> It just became relevent to me because I have a need for a CLDC
>>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>>> (just about) CLDC compliant, if I can easily convert the
>>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>>> this, I might as well make it compliant with the forthcoming
>>> interface.
The solution may be to create an org.apache.xmlrpc.cldc.CLDCXmlRpcClient
class that depends on the MinML package, and a subset of the core
org.apache.xmlrpc package:
XmlRpc
XmlRpcException
XmlRpcClientRequestProcessor (see above)
XmlRpcClientResponseProcessor (see above)
HttpClient (I've factored this out of XmlRpcClientLite).
Base64
ServerInputStream
This would have no main(), no asynchronous handling, no workers or
worker stack, etc. But, it would be _very_ small.
Andrew.
Re: XmlRpcClient Interface
Posted by Jim Redman <ji...@ergotech.com>.
I have the CLDC code, but didn't find the interface. Is it hidden in
CVS or elsewhere? Also I modified the XmlRpcClientLite, my
recollection is that there are plans for this that will modify it
significantly.
Kudos to all the committers of this project, the changes were fairly
simple. This is due to a number things, a desire to keep the
architecture fairly simple, maintaining JDK 1.1 compliance and using
MinML. Special thanks to John for this last.
This is the gist of the modifications. I removed the superclass
(XmlRpcClient) and copied a couple of methods across and removed the
superclass of LiteWorker (Worker) and copied some methods. I think
that I also trashed the Async code. There are minor changes to
XmlRpc.java (removing "properties"), other than that, you need
Base64.java, ServerInputStream.java and XmlRpcException.java which
compile unchanged. I think that there also some supporting classes
that we had already created (StringTokenizer?), maybe others.
References to URL and associated exceptions have been removed, if we
need these to match a new interface (likely) we will need to create
substitutes.
If anyone else has an immediate interest in this code, let me know.
I'll be testing over this week, the goal is to get it on the iPaq/Jeode.
Jim
On 2002.11.03 17:30 Ryan Hoegg wrote:
> Jim,
>
> Sounds great! I think the status now is that we are keeping the
> XmlRpcClient class but pulling out the salient bits into more focused
> classes. The XmlRpcClient class will depend only on interfaces, and
> implementations for those interfaces will be distributed in separate
> packages to facilitate building JARs that are tailored to specific
> users. This is all still pre-alpha of course, and we weclome further
> discussion.
>
> Your's looks like a great use case to help us with the design
> direction here. If you search the archives for the "HttpClient
> Integration" thread you can read a lot of the recent progress in this
> area, with the bulk of the tangible code coming from Andrew Evers.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
> Jim Redman wrote:
>
>> I only vaguely remember the discussion of adding an interface for
>> the client. Can someone provide a quick synopsis and the status?
>>
>> It just became relevent to me because I have a need for a CLDC
>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>> (just about) CLDC compliant, if I can easily convert the
>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>> this, I might as well make it compliant with the forthcoming
>> interface.
>>
>> Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: XmlRpcClient Interface
Posted by Jim Redman <ji...@ergotech.com>.
I have the CLDC code, but didn't find the interface. Is it hidden in
CVS or elsewhere? Also I modified the XmlRpcClientLite, my
recollection is that there are plans for this that will modify it
significantly.
Kudos to all the committers of this project, the changes were fairly
simple. This is due to a number things, a desire to keep the
architecture fairly simple, maintaining JDK 1.1 compliance and using
MinML. Special thanks to John for this last.
This is the gist of the modifications. I removed the superclass
(XmlRpcClient) and copied a couple of methods across and removed the
superclass of LiteWorker (Worker) and copied some methods. I think
that I also trashed the Async code. There are minor changes to
XmlRpc.java (removing "properties"), other than that, you need
Base64.java, ServerInputStream.java and XmlRpcException.java which
compile unchanged. I think that there also some supporting classes
that we had already created (StringTokenizer?), maybe others.
References to URL and associated exceptions have been removed, if we
need these to match a new interface (likely) we will need to create
substitutes.
If anyone else has an immediate interest in this code, let me know.
I'll be testing over this week, the goal is to get it on the iPaq/Jeode.
Jim
On 2002.11.03 17:30 Ryan Hoegg wrote:
> Jim,
>
> Sounds great! I think the status now is that we are keeping the
> XmlRpcClient class but pulling out the salient bits into more focused
> classes. The XmlRpcClient class will depend only on interfaces, and
> implementations for those interfaces will be distributed in separate
> packages to facilitate building JARs that are tailored to specific
> users. This is all still pre-alpha of course, and we weclome further
> discussion.
>
> Your's looks like a great use case to help us with the design
> direction here. If you search the archives for the "HttpClient
> Integration" thread you can read a lot of the recent progress in this
> area, with the bulk of the tangible code coming from Andrew Evers.
>
> --
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net
>
> Jim Redman wrote:
>
>> I only vaguely remember the discussion of adding an interface for
>> the client. Can someone provide a quick synopsis and the status?
>>
>> It just became relevent to me because I have a need for a CLDC
>> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is
>> (just about) CLDC compliant, if I can easily convert the
>> XmlRpcClient to CLDC I may have a good solution. If I'm going to do
>> this, I might as well make it compliant with the forthcoming
>> interface.
>>
>> Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Jim,
Sounds great! I think the status now is that we are keeping the
XmlRpcClient class but pulling out the salient bits into more focused
classes. The XmlRpcClient class will depend only on interfaces, and
implementations for those interfaces will be distributed in separate
packages to facilitate building JARs that are tailored to specific
users. This is all still pre-alpha of course, and we weclome further
discussion.
Your's looks like a great use case to help us with the design direction
here. If you search the archives for the "HttpClient Integration"
thread you can read a lot of the recent progress in this area, with the
bulk of the tangible code coming from Andrew Evers.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jim Redman wrote:
> I only vaguely remember the discussion of adding an interface for the
> client. Can someone provide a quick synopsis and the status?
>
> It just became relevent to me because I have a need for a CLDC
> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just
> about) CLDC compliant, if I can easily convert the XmlRpcClient to
> CLDC I may have a good solution. If I'm going to do this, I might as
> well make it compliant with the forthcoming interface.
>
> Jim
Re: XmlRpcClient Interface
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Jim,
Sounds great! I think the status now is that we are keeping the
XmlRpcClient class but pulling out the salient bits into more focused
classes. The XmlRpcClient class will depend only on interfaces, and
implementations for those interfaces will be distributed in separate
packages to facilitate building JARs that are tailored to specific
users. This is all still pre-alpha of course, and we weclome further
discussion.
Your's looks like a great use case to help us with the design direction
here. If you search the archives for the "HttpClient Integration"
thread you can read a lot of the recent progress in this area, with the
bulk of the tangible code coming from Andrew Evers.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Jim Redman wrote:
> I only vaguely remember the discussion of adding an interface for the
> client. Can someone provide a quick synopsis and the status?
>
> It just became relevent to me because I have a need for a CLDC
> client. kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just
> about) CLDC compliant, if I can easily convert the XmlRpcClient to
> CLDC I may have a good solution. If I'm going to do this, I might as
> well make it compliant with the forthcoming interface.
>
> Jim
XmlRpcClient Interface
Posted by Jim Redman <ji...@ergotech.com>.
I only vaguely remember the discussion of adding an interface for the
client. Can someone provide a quick synopsis and the status?
It just became relevent to me because I have a need for a CLDC client.
kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just about)
CLDC compliant, if I can easily convert the XmlRpcClient to CLDC I may
have a good solution. If I'm going to do this, I might as well make it
compliant with the forthcoming interface.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
XmlRpcClient Interface
Posted by Jim Redman <ji...@ergotech.com>.
I only vaguely remember the discussion of adding an interface for the
client. Can someone provide a quick synopsis and the status?
It just became relevent to me because I have a need for a CLDC client.
kxmlrpc assumes MIDP (HttpConnection). Since MinML is (just about)
CLDC compliant, if I can easily convert the XmlRpcClient to CLDC I may
have a good solution. If I'm going to do this, I might as well make it
compliant with the forthcoming interface.
Jim
--
Jim Redman
(505) 662 5156
http://www.ergotech.com
Re: GNU-GPL compatibility question
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Andrew Evers wrote:
>
> >In any case, the MinML license would have to be brought up with
> >the license holder (whom I believe is on this list).
> >
> >Andrew.
> >
> This brings up an interesting point. Could I create my own
> xmlrpc-1-1.jar that does not include the uk.co.wilson tree and avoid
> any MinML licensing issues? It is possible to use Xerces as the XML
> parser anyway.
Yes, it is. My tests against Xerces 1.4 show MinML to be 60% faster,
however. Not needing the extra features Xerces has to offer for this
use case, I'd be loathe to swith.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: GNU-GPL compatibility question
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Ryan Hoegg <rh...@isisnetworks.net> writes:
> Andrew Evers wrote:
>
> >In any case, the MinML license would have to be brought up with
> >the license holder (whom I believe is on this list).
> >
> >Andrew.
> >
> This brings up an interesting point. Could I create my own
> xmlrpc-1-1.jar that does not include the uk.co.wilson tree and avoid
> any MinML licensing issues? It is possible to use Xerces as the XML
> parser anyway.
Yes, it is. My tests against Xerces 1.4 show MinML to be 60% faster,
however. Not needing the extra features Xerces has to offer for this
use case, I'd be loathe to swith.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: GNU-GPL compatibility question
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Andrew Evers wrote:
>In any case, the MinML license would have to be brought up with
>the license holder (whom I believe is on this list).
>
>Andrew.
>
This brings up an interesting point. Could I create my own
xmlrpc-1-1.jar that does not include the uk.co.wilson tree and avoid any
MinML licensing issues? It is possible to use Xerces as the XML parser
anyway.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: GNU-GPL compatibility question
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Andrew Evers wrote:
>In any case, the MinML license would have to be brought up with
>the license holder (whom I believe is on this list).
>
>Andrew.
>
This brings up an interesting point. Could I create my own
xmlrpc-1-1.jar that does not include the uk.co.wilson tree and avoid any
MinML licensing issues? It is possible to use Xerces as the XML parser
anyway.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
Re: GNU-GPL compatibility question
Posted by Andrew Evers <ae...@redwood.nl>.
> My java project include the xmlrpc-1.1.jar, so it also includes MinML,
> which has a BSD-like license.
>
> Can I release and distribute my project under the GNU-GPL license ?
>
> Can I apply the GNU-GPL to my own code and ship it in a tar.gz
> including xmlrpc-1.1.jar ?
>
> In that case, can I say "myproject is GNU GPL licensed" ?
Disclaimer: I am not a laywer, I am a coder. This is not legal advice.
Note that the Apache license is not the same as the GNU GPL. Since
you want to release under the GPL, check out the FSF's licencing page:
http://www.fsf.org/licenses/gpl-faq.html
In particular:
http://www.fsf.org/licenses/gpl-faq.html#MereAggregation
-- Quote --
What is the difference between "mere aggregation" and "combining
two modules into one program"?
[snip]
What constitutes combining two parts into one program?
[snip]
If modules are designed to run linked together in a shared
address space, that almost surely means combining them into
one program.
--End Quote--
Java certainally runs loads and executes classes in the same
address space. So, this would imply that releasing a project
containing non-GPL code under the GPL is going to be difficult.
Furthermore, the Apache licence for the XML-RPC code contains
the following clause. From a random source file in the XML-RPC
project:
--Quote--
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
--End Quote--
Consider this in the context of the compatibility of the original
BSD license and the GPL.
http://www.fsf.org/licenses/gpl-faq.html#OrigBSD
--Quote--
Why is the original BSD license incompatible with the GPL?
Because it imposes a specific requirement that is not in the
GPL; namely, the requirement on advertisements of the program.
The GPL states:
You may not impose any further restrictions on the recipients'
exercise of the rights granted herein.
The advertising clause provides just such a further restriction,
and thus is GPL-incompatible.
The revised BSD license does not have the advertising clause,
which eliminates the problem.'
--End Quote--
So it would seem that you can't re-release Apache code under the
GPL. If you are using a significant amount of Apache licensed code
in your project, consider using the Apache license, or a similar
one.
In any case, the MinML license would have to be brought up with
the license holder (whom I believe is on this list).
Andrew.
Re: GNU-GPL compatibility question
Posted by Andrew Evers <ae...@redwood.nl>.
> My java project include the xmlrpc-1.1.jar, so it also includes MinML,
> which has a BSD-like license.
>
> Can I release and distribute my project under the GNU-GPL license ?
>
> Can I apply the GNU-GPL to my own code and ship it in a tar.gz
> including xmlrpc-1.1.jar ?
>
> In that case, can I say "myproject is GNU GPL licensed" ?
Disclaimer: I am not a laywer, I am a coder. This is not legal advice.
Note that the Apache license is not the same as the GNU GPL. Since
you want to release under the GPL, check out the FSF's licencing page:
http://www.fsf.org/licenses/gpl-faq.html
In particular:
http://www.fsf.org/licenses/gpl-faq.html#MereAggregation
-- Quote --
What is the difference between "mere aggregation" and "combining
two modules into one program"?
[snip]
What constitutes combining two parts into one program?
[snip]
If modules are designed to run linked together in a shared
address space, that almost surely means combining them into
one program.
--End Quote--
Java certainally runs loads and executes classes in the same
address space. So, this would imply that releasing a project
containing non-GPL code under the GPL is going to be difficult.
Furthermore, the Apache licence for the XML-RPC code contains
the following clause. From a random source file in the XML-RPC
project:
--Quote--
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
--End Quote--
Consider this in the context of the compatibility of the original
BSD license and the GPL.
http://www.fsf.org/licenses/gpl-faq.html#OrigBSD
--Quote--
Why is the original BSD license incompatible with the GPL?
Because it imposes a specific requirement that is not in the
GPL; namely, the requirement on advertisements of the program.
The GPL states:
You may not impose any further restrictions on the recipients'
exercise of the rights granted herein.
The advertising clause provides just such a further restriction,
and thus is GPL-incompatible.
The revised BSD license does not have the advertising clause,
which eliminates the problem.'
--End Quote--
So it would seem that you can't re-release Apache code under the
GPL. If you are using a significant amount of Apache licensed code
in your project, consider using the Apache license, or a similar
one.
In any case, the MinML license would have to be brought up with
the license holder (whom I believe is on this list).
Andrew.