You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by David Duddleston <da...@i2a.com> on 2001/06/03 21:23:31 UTC
RE: Off Topic: FSF makes peace with rest of open source world (not)
> The
> vast majority of "GPL" java projects out there violate the GPL, the FSF is
> quite aware of this and choose to ignore it (RMS called java a blight on
> the free software wordl)
I assume this is because of the way Java more or less links in with the
software, so it is considered part of the code? Licenses are so confusing...
urggg! If this is the case then, I would also assume that the vast majority
of applications that use GPL are in violation too. I know there are allot of
developers taking GPL code and using it in a prosperity software built for a
client. Does this not violate the GPL? even maybe the LGPL?
-david
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world
(not)
Posted by Peter Donald <do...@apache.org>.
At 10:26 PM 6/3/01 -0700, David Duddleston wrote:
>For alternatives, the only
>other pure Java database that is open source I know of is Hypersonic, but
>the last I checked it was not multiuser and is missing a few features I
>need. Also, InstantDB the last I checked was still not OS'ed. Maybe you have
>a gem I have not heard of?
They were the two relational RDBMS's I was thinking of - so no other gems
in that area ;) There was a few OO/psuedo-OO/XML style databases but I am
not sure if thats what you are after or if they are mature enough yet ;/
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world
(not)
Posted by Peter Donald <do...@apache.org>.
At 11:12 AM 6/4/01 -0700, David Duddleston wrote:
>> I think Berins whitepaper actually
>> describes it in more detail and how it is used in Cocoon2.
>
>Where might this be. I looked around the Cocoon2 and Avalon projects, but
>did not find it.
It is something on the horizon .. probably released post ApacheCon.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Berin Loritsch white paper
Posted by David Duddleston <da...@i2a.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> It's still being developed, and will be made available as soon as
> is possible.
Ahhh, that explains it. I'll be anticipating it along with other Avalon
docs.
Thanks Berin.
-david
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Off Topic: FSF makes peace with rest of open source world (not)
Posted by Berin Loritsch <bl...@apache.org>.
David Duddleston wrote:
>
> > So in many ways the use case it alsmost identical (except Cocoon has 3
> > stages where you only have 2).
>
> In the grand scope, there will be several stages (at least 7 in some cases)
> a newly retrieved URI will go through before the end results are achieved
> which as an indexed document. I assume that the difference of having 7+
> stages vs. 2 or 3 is no big deal.
>
> > >I hope this makes sense... I have a feeling it does, sense I
> > think this is
> > >the kind of stuff Avalon was created for and you people are doing this
> > >extact thing already. Am I on the right track here?
> >
> > It makes sense ;) You definetly want to have a look
> > org.apache.avalon.excalibur.component.* which has a ComponentManager that
> > already does the Pooling et al.
>
> Cool, I will check it out.
>
> > I think Berins whitepaper actually
> > describes it in more detail and how it is used in Cocoon2.
>
> Where might this be. I looked around the Cocoon2 and Avalon projects, but
> did not find it.
>
> Thanks
It's still being developed, and will be made available as soon as is possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world (not)
Posted by David Duddleston <da...@i2a.com>.
> So in many ways the use case it alsmost identical (except Cocoon has 3
> stages where you only have 2).
In the grand scope, there will be several stages (at least 7 in some cases)
a newly retrieved URI will go through before the end results are achieved
which as an indexed document. I assume that the difference of having 7+
stages vs. 2 or 3 is no big deal.
> >I hope this makes sense... I have a feeling it does, sense I
> think this is
> >the kind of stuff Avalon was created for and you people are doing this
> >extact thing already. Am I on the right track here?
>
> It makes sense ;) You definetly want to have a look
> org.apache.avalon.excalibur.component.* which has a ComponentManager that
> already does the Pooling et al.
Cool, I will check it out.
> I think Berins whitepaper actually
> describes it in more detail and how it is used in Cocoon2.
Where might this be. I looked around the Cocoon2 and Avalon projects, but
did not find it.
Thanks
-david
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world
(not)
Posted by Peter Donald <do...@apache.org>.
At 12:41 AM 6/4/01 -0700, David Duddleston wrote:
>I will try and explain the basic component flow for one part of my
>application which is a data miner / search engine. First the classes, there
>is a URI, ConnectionHandler (protocol based), ContentHandler (MIME based)
>and a CookieManager. A simple flow would be, a ConnectionHandler is
>determined based on the URI protocol, lets say HTTP for this one. The URI is
>passed to the HttpConnectionHandler and the handler grabs a CookieManager
>and uses it to deal with any cookie related processing. Next it checks the
>content type and gets a ContentHandler, lets say HtmlContentHandler, and
>passes off the input stream to the ContentHandler... a few steps are skipped
>in this description but I will assume you get the idea.
This is almost exactly the design of Cocoon2. It also has a pipeline design
with multiple stages (in it's case it has generators, transformers and
serializers).
* Each stage can have multiple different types of component to handle it
(ie There is generators such as FileGenerator, PHPGenerator, JSPGenerator,
VelocityGenerator etc).
* In each stage you can have multiple instances of same "type" but
different parameters supplied (ie multiple FileGenerators with different
parameters).
* Some of these components are ThreadSafe, others are Poolable and some
must be recreated with each use. Thus they have a specialized
ComponentManager that pools Poolable components, caches the ThreadSafe
components and creates the other components.
So in many ways the use case it alsmost identical (except Cocoon has 3
stages where you only have 2).
>I hope this makes sense... I have a feeling it does, sense I think this is
>the kind of stuff Avalon was created for and you people are doing this
>extact thing already. Am I on the right track here?
It makes sense ;) You definetly want to have a look
org.apache.avalon.excalibur.component.* which has a ComponentManager that
already does the Pooling et al. I think Berins whitepaper actually
describes it in more detail and how it is used in Cocoon2.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world (not)
Posted by David Duddleston <da...@i2a.com>.
> Theres a few other opensource dbs around; LGPL / BSD / Mozilla licensed. I
> would recomend you use these (or try to get "Mckoi DB developers" to give
> you an exception or change license).
I'm currenlty talking to them and they seem to think it is ok for me to use
Mckoi as long as I issue my code under the GPL license as well. But it seems
like the use of ASL code will violate the GPL license and that I need to get
them to release Mckoi under LGPL at minimum. For alternatives, the only
other pure Java database that is open source I know of is Hypersonic, but
the last I checked it was not multiuser and is missing a few features I
need. Also, InstantDB the last I checked was still not OS'ed. Maybe you have
a gem I have not heard of?
-david
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [ Was "Off Topic...", now: ] Avalon become OS.
Posted by Berin Loritsch <bl...@apache.org>.
Paul Hammant wrote:
>
> Berin : Do you want me to email you the subject of this thread? If yes, just since Saturday?
Please. Since Saturday should be fine.
>
> ---
>
> > >GPL is completely insane for toolkits, services and APIs. Its only
> > patronised by people that are
> > >new to the "cause" of open source, or those too proud to admin they have
> > made the wrong choice of
> > >open source license (the second half of that is paraphrasing your comments
> > Peter (entirely valid)
> > >during the spat with the JBoss people late last year).
> >
> > You have to realize that when the GPL was born there was a very good reason
> > for making the choices it made. I agree 100% with those decisions at that
> > time. GPL serves the users at the expense of developers. In current times
> > there is still some reasons to use GPL. Mainly if a company does not want
> > to release code only to have market-savy competitiors repackage and resell it.
>
> That's a good point - release as GPL to open it, but stifle commercial competitors use. A spolier
> of sorts.
>
> > The other reason a lot of new comers use GPL is because of advertising
> > (they believe GPL==opensource) and they don't really understand
> > implications and actually believe some of the rhetoric spouted by 'anarhy r
> > us' type peeps.
>
> That's what I meant by "new to the cause". You put it better though.
>
> [ Avalon == ApacheOS (phase 1) ]
>
> > It is definetly something I have played with as an idea. One of the main
> > reasons I ended up getting involved with Ant was to play with idea of an
> > ant init system (first process in *nix systems) and also to rebuild my
> > cron/job/at server. I am also involved with Isolate JSR (basically fork for
> > java) which should be a step in right direction.
>
> Can we go down the gap route? i.e. where does Avalon on top of J2SE on top of host OS (or BIOS or
> other) not fill the requisites for OS definition.
>
> Incidentally, Peter, you're spot on for pushing Ant down the Avalon road (as long as it remains
> multimodal).
>
> Regards,
>
> - Paul H
>
> ____________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> or your free @yahoo.ie address at http://mail.yahoo.ie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [ Was "Off Topic...", now: ] Avalon become OS.
Posted by Paul Hammant <pa...@yahoo.com>.
Berin : Do you want me to email you the subject of this thread? If yes, just since Saturday?
---
> >GPL is completely insane for toolkits, services and APIs. Its only
> patronised by people that are
> >new to the "cause" of open source, or those too proud to admin they have
> made the wrong choice of
> >open source license (the second half of that is paraphrasing your comments
> Peter (entirely valid)
> >during the spat with the JBoss people late last year).
>
> You have to realize that when the GPL was born there was a very good reason
> for making the choices it made. I agree 100% with those decisions at that
> time. GPL serves the users at the expense of developers. In current times
> there is still some reasons to use GPL. Mainly if a company does not want
> to release code only to have market-savy competitiors repackage and resell it.
That's a good point - release as GPL to open it, but stifle commercial competitors use. A spolier
of sorts.
> The other reason a lot of new comers use GPL is because of advertising
> (they believe GPL==opensource) and they don't really understand
> implications and actually believe some of the rhetoric spouted by 'anarhy r
> us' type peeps.
That's what I meant by "new to the cause". You put it better though.
[ Avalon == ApacheOS (phase 1) ]
> It is definetly something I have played with as an idea. One of the main
> reasons I ended up getting involved with Ant was to play with idea of an
> ant init system (first process in *nix systems) and also to rebuild my
> cron/job/at server. I am also involved with Isolate JSR (basically fork for
> java) which should be a step in right direction.
Can we go down the gap route? i.e. where does Avalon on top of J2SE on top of host OS (or BIOS or
other) not fill the requisites for OS definition.
Incidentally, Peter, you're spot on for pushing Ant down the Avalon road (as long as it remains
multimodal).
Regards,
- Paul H
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [ Was "Off Topic...", now: ] Avalon become OS.
Posted by Peter Donald <do...@apache.org>.
At 12:50 PM 6/4/01 +0100, Paul Hammant wrote:
>> >3) Modifications to GPL code (like other OSS licenses) must be
republished.
>>
>> Not all OSS or Free software licenses mandate republishing. (ie Apache).
>
>To a point. If you change an apache class then yes, but if you extend or
use it then replication
>is not necessary.
not sure what you mean. If you modify apache classes there is no license
clause that forces you to publish it. You can keep it private and sell it
as part of a "valued-added" product (ie Oracle did that with Apache
webserver and jserv I believe).
>> >4) GPL likes Xerces because Xerces implements a W3C interface (approved).
>> The linking of the
>> >Xerces classes is achieved through a factory that *could* have multiple
>> implementations (somthing
>> >the GPL likes very much). If you import any org.apache.* class (and other
>> utilities under many
>> >other OSI approved licenses) you are in breach of GPL.
>>
>> Actually xerces may not be used by GPL app even though it goes through a PD
>> interface. The exception is only allowed when it is considered hosted
>> component.
>
>>>From what I have read, you can use Xerces in a GPL app, but not
distribute it. This is because
>the W3C licensed SAX API allows multiple implementations. As such the
person running a GPL app
>could choose to run Xerces instead of a GPL approved parser. The point
being that as long as the
>GPL app is not compiled against, or distributed with Xerces, it's not in
breach.
okay - that works for me ;)
>Would JDK 1.4's parser? Yes, as it's part of the JDK and hence appowed as
part of the "operating
>system" or "hosted environment" concessions. Weird. Sun have a far more
closed license than
>Apache, yet pass the GPL compatability test on the basis that they are
providing it as part of the
>JDK.
;)
>Never, I am very happy with the terms of the Apache license. What I am
peed off about is that the
>FSF maintains some "Any color you like as long as it is black" attidude to
(we'll say) 20 fine OSI
>approved licenses.
They are persistent ;) Maybe not completely coherent (LGPL interpretation
seems to vary depending on what project you are talking about).
>GPL is completely insane for toolkits, services and APIs. Its only
patronised by people that are
>new to the "cause" of open source, or those too proud to admin they have
made the wrong choice of
>open source license (the second half of that is paraphrasing your comments
Peter (entirely valid)
>during the spat with the JBoss people late last year).
You have to realize that when the GPL was born there was a very good reason
for making the choices it made. I agree 100% with those decisions at that
time. GPL serves the users at the expense of developers. In current times
there is still some reasons to use GPL. Mainly if a company does not want
to release code only to have market-savy competitiors repackage and resell it.
The other reason a lot of new comers use GPL is because of advertising
(they believe GPL==opensource) and they don't really understand
implications and actually believe some of the rhetoric spouted by 'anarhy r
us' type peeps.
>Anyway, I really think by a process of declaration and gap filling we
could grant Avalon the
>status of operating system, at least to the level that the JDK has been.
ApacheOS is born.
>Avalon plus beaucoup de hosted services. We have Cocoon, Locomotive, FTP,
James. In the wings are
>others, plus some of your glimmers like DNS and mine like Jesktop.
It is definetly something I have played with as an idea. One of the main
reasons I ended up getting involved with Ant was to play with idea of an
ant init system (first process in *nix systems) and also to rebuild my
cron/job/at server. I am also involved with Isolate JSR (basically fork for
java) which should be a step in right direction.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
[ Was "Off Topic...", now: ] Avalon become OS.
Posted by Paul Hammant <pa...@yahoo.com>.
> >2) GPL code can be modified by a business or org and kept secret, provided
> the code is not
> >distributed out again.
>
> neither may the binary. RSN it will even become difficult to allow people
> to use software without giving them access to sourcecode. So if you have a
> GPLed http server then anyone who visits your site has to have access to
> source of server. RMS got miffed that service providers were using GPL code
> but not recontributing changes ;)
Blimey.
> >3) Modifications to GPL code (like other OSS licenses) must be republished.
>
> Not all OSS or Free software licenses mandate republishing. (ie Apache).
To a point. If you change an apache class then yes, but if you extend or use it then replication
is not necessary.
> >4) GPL likes Xerces because Xerces implements a W3C interface (approved).
> The linking of the
> >Xerces classes is achieved through a factory that *could* have multiple
> implementations (somthing
> >the GPL likes very much). If you import any org.apache.* class (and other
> utilities under many
> >other OSI approved licenses) you are in breach of GPL.
>
> Actually xerces may not be used by GPL app even though it goes through a PD
> interface. The exception is only allowed when it is considered hosted
> component.
>From what I have read, you can use Xerces in a GPL app, but not distribute it. This is because
the W3C licensed SAX API allows multiple implementations. As such the person running a GPL app
could choose to run Xerces instead of a GPL approved parser. The point being that as long as the
GPL app is not compiled against, or distributed with Xerces, it's not in breach.
Would JDK 1.4's parser? Yes, as it's part of the JDK and hence appowed as part of the "operating
system" or "hosted environment" concessions. Weird. Sun have a far more closed license than
Apache, yet pass the GPL compatability test on the basis that they are providing it as part of the
JDK.
Wat too about Apache licensed software if Sun included it in the JDK?
> >Avalon
> >======
> >
> >This leads us neatly on to Avalon, If Avalon's interfaces were declared
> "Operating system", then
> >they would be granted the same excepmtion as JDK classes would (they are a
> commercial license).
> >People are going to object here, citing examples like not file system
> implemented in Avalon....
> >
> >It is my opinion that OS is where we should head....
>
> The problem is that almost all of Avalon is involved with hosted components
> and thus all of it would have be BSDL or X11 licensed. This would involve
> convincing all Avalon committers, the PMC and the Board. Feel free to try ;)
Never, I am very happy with the terms of the Apache license. What I am peed off about is that the
FSF maintains some "Any color you like as long as it is black" attidude to (we'll say) 20 fine OSI
approved licenses.
If we declare Avalon to be an operating system, we might, without any further changes to terms and
conditions or licenses, be compatible with the GPL becase of it's "get out of jail" clause for
such layers in a computing environment.
Not so you say - Avalon is definately not an OS. True, but then neither is Java. Without much of
stretch of thinking, we should be able to determine that no Java code at all can possibly be
compatible with the GPL. Ahh, but the GPL zealots say that there is Kaffe/Classpath to allow
compatiblity with GPL (multiple implementations). That's great but those are massively
imcomplete. There is not Swing or other heavier APIs, and any work that they have done is so
close to the orginal art of Sun et al, that copyright infringement is probably an issue.
GPL is completely insane for toolkits, services and APIs. Its only patronised by people that are
new to the "cause" of open source, or those too proud to admin they have made the wrong choice of
open source license (the second half of that is paraphrasing your comments Peter (entirely valid)
during the spat with the JBoss people late last year).
Anyway, I really think by a process of declaration and gap filling we could grant Avalon the
status of operating system, at least to the level that the JDK has been. ApacheOS is born.
Avalon plus beaucoup de hosted services. We have Cocoon, Locomotive, FTP, James. In the wings are
others, plus some of your glimmers like DNS and mine like Jesktop.
All we have to do is define a feature gap, with the already loose definition of operating system
in mind.
Regards,
- Paul H
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world
(not)
Posted by Peter Donald <do...@apache.org>.
At 10:03 AM 6/4/01 +0100, Paul Hammant wrote:
>David (and others)...
>
>To summarize the pitfalls from the point of view of Java:
>
>1) GPL code can't import non approved licenses, nor be imported by non
approved licenses (with the
>exception of the underlying operating system, JDK, or major OS-like
interface - HTTPServlet etc).
HttpServlet is only allowed because it is part of the J2EE JDK.
>2) GPL code can be modified by a business or org and kept secret, provided
the code is not
>distributed out again.
neither may the binary. RSN it will even become difficult to allow people
to use software without giving them access to sourcecode. So if you have a
GPLed http server then anyone who visits your site has to have access to
source of server. RMS got miffed that service providers were using GPL code
but not recontributing changes ;)
>3) Modifications to GPL code (like other OSS licenses) must be republished.
Not all OSS or Free software licenses mandate republishing. (ie Apache).
>4) GPL likes Xerces because Xerces implements a W3C interface (approved).
The linking of the
>Xerces classes is achieved through a factory that *could* have multiple
implementations (somthing
>the GPL likes very much). If you import any org.apache.* class (and other
utilities under many
>other OSI approved licenses) you are in breach of GPL.
Actually xerces may not be used by GPL app even though it goes through a PD
interface. The exception is only allowed when it is considered hosted
component.
>Avalon
>======
>
>This leads us neatly on to Avalon, If Avalon's interfaces were declared
"Operating system", then
>they would be granted the same excepmtion as JDK classes would (they are a
commercial license).
>People are going to object here, citing examples like not file system
implemented in Avalon....
>
>It is my opinion that OS is where we should head....
The problem is that almost all of Avalon is involved with hosted components
and thus all of it would have be BSDL or X11 licensed. This would involve
convincing all Avalon committers, the PMC and the Board. Feel free to try ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world (not)
Posted by Paul Hammant <pa...@yahoo.com>.
David (and others)...
To summarize the pitfalls from the point of view of Java:
1) GPL code can't import non approved licenses, nor be imported by non approved licenses (with the
exception of the underlying operating system, JDK, or major OS-like interface - HTTPServlet etc).
2) GPL code can be modified by a business or org and kept secret, provided the code is not
distributed out again.
3) Modifications to GPL code (like other OSS licenses) must be republished. The difference is that
the GPL hints that you should include the source in the binary distrbution or provide a minimal
cost distro of source by snail mail (I am *not* going to do that!!!). Having to URLs - one for
src, one for binary, is not enough, but very common.
4) GPL likes Xerces because Xerces implements a W3C interface (approved). The linking of the
Xerces classes is achieved through a factory that *could* have multiple implementations (somthing
the GPL likes very much). If you import any org.apache.* class (and other utilities under many
other OSI approved licenses) you are in breach of GPL.
5) Whole situation sucks. Mozilla & Apache licenses (plus 20 others) are first class OSS
licenses. LGPL is better for toolkits (see the GPL license for commentary on glibc) than GPL.
The DB people you are dealing with will sometime soon change their license as it's unusable for
toolkits. This happend to JBoss and others, but sometimes there is great resistance to this news.
Avalon
======
This leads us neatly on to Avalon, If Avalon's interfaces were declared "Operating system", then
they would be granted the same excepmtion as JDK classes would (they are a commercial license).
People are going to object here, citing examples like not file system implemented in Avalon....
It is my opinion that OS is where we should head....
Regards,
- Paul H
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world (not)
Posted by David Duddleston <da...@i2a.com>.
> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
>
> hopefully there will be some more docs available soon (post ApacheCon).
> Until then feel free to ask questions or point out anything you feel is
> wrong ;)
Cool. After taking a quick pass through the documents, I sort of have an
idea of what I may need to do, but there is also allot I have not covered
yet. It seems that the area of most interest to me is the
...framework.component package... the ComponentManager and
ComponentSelector, along with reconfigurable. I don't have any specific
questions at this points as I want to go through the documentation a little
more first, but here is description of what I'm trying to do if you are
interested.
I will try and explain the basic component flow for one part of my
application which is a data miner / search engine. First the classes, there
is a URI, ConnectionHandler (protocol based), ContentHandler (MIME based)
and a CookieManager. A simple flow would be, a ConnectionHandler is
determined based on the URI protocol, lets say HTTP for this one. The URI is
passed to the HttpConnectionHandler and the handler grabs a CookieManager
and uses it to deal with any cookie related processing. Next it checks the
content type and gets a ContentHandler, lets say HtmlContentHandler, and
passes off the input stream to the ContentHandler... a few steps are skipped
in this description but I will assume you get the idea.
Now for the sake of argument, lets say I have several implementations of
each for the HtmlConnectionHandler, CookieManager, and HtmlContentHandler
(class/interface). Plus, I have several contexts (not shure if context is
the appropriate term) that require different configurations of the component
implementations to be used. Now for extra complexity, lets create a pool of
HttpConnectionHandler classes that can be reused in any context. I'll put
this scenario in an example. In this example the configuration in one
context requires that the implementation of the org.xyz
HttpConnectionHandler is used and the HttpConnectionHandler must use the
org.abc implementation of the HtmlContentHandler to handle the input stream
if it is HTML. When the HttpConnectionHandler is grabbed from the pool, it
needs to know that the com.foo implementation of HtmlContentHandler needs to
be used vs. com.xyz. As you can see, I need a framework to control the
components interactions, selections and configurations.
I hope this makes sense... I have a feeling it does, sense I think this is
the kind of stuff Avalon was created for and you people are doing this
extact thing already. Am I on the right track here?
-david
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world
(not)
Posted by Peter Donald <do...@apache.org>.
At 09:27 PM 6/3/01 -0700, David Duddleston wrote:
>
>> The real issue is that there is few libraries in java that are GPL
>> compatible. Even essentials like xml parsers don't really have a showing,
>> nor can you use standard extentions - thus most "GPL" java projects ignore
>> this and violate the GPL ;) The exception being the GNU projects which are
>> relatively clean.
>
>Up until recently, I have sort of ignored the license issues and just used
>whatever I could get my greedy hands on. I'm sure at sometime I may have
>technically violated a license out of confusion and laziness. Now that I'm
>working on my own free open source project, picking a license has become an
>issue. My project uses several ASL projects and one LGPL. I also want to use
>the Mckoi DB, but it is GPL. At this point, I believe I can release my code
>under both GPL and modified BSD and if a user needs to use my project code
>for propriety use, they can swap out the Mckoi DB for something else and
>everything is cool. I admit to being license illiterate and my opinion about
>them so far has been limited to... the shorter the better.
Unfortunately I don't think you could technically do that. It may be best
to approach the Mckoi DB developers and ask if they would consider LGPLing
their library. Other than that you essentially can't distribute it with
non-GPL compatible parts without violating GPL license. There are
exceptions to this but I don't think yours will be covered by it (ie it is
not a hosted component).
Theres a few other opensource dbs around; LGPL / BSD / Mozilla licensed. I
would recomend you use these (or try to get "Mckoi DB developers" to give
you an exception or change license).
>On a side note, I have a prototype of my project and it is very hardwired
>right now. I think my project may need to be re-developed using a component
>based framework, since I want the ability to swap and configure components
>at runtime, plus the components need to be context aware. I'm thinking
>Avalon may be a good fit, but I'm still pretty clueless about some parts of
>it, so I'm digging into the docs and code at this moment. I may have to ask
>a few questions...
hopefully there will be some more docs available soon (post ApacheCon).
Until then feel free to ask questions or point out anything you feel is
wrong ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world (not)
Posted by David Duddleston <da...@i2a.com>.
> The real issue is that there is few libraries in java that are GPL
> compatible. Even essentials like xml parsers don't really have a showing,
> nor can you use standard extentions - thus most "GPL" java projects ignore
> this and violate the GPL ;) The exception being the GNU projects which are
> relatively clean.
Up until recently, I have sort of ignored the license issues and just used
whatever I could get my greedy hands on. I'm sure at sometime I may have
technically violated a license out of confusion and laziness. Now that I'm
working on my own free open source project, picking a license has become an
issue. My project uses several ASL projects and one LGPL. I also want to use
the Mckoi DB, but it is GPL. At this point, I believe I can release my code
under both GPL and modified BSD and if a user needs to use my project code
for propriety use, they can swap out the Mckoi DB for something else and
everything is cool. I admit to being license illiterate and my opinion about
them so far has been limited to... the shorter the better.
On a side note, I have a prototype of my project and it is very hardwired
right now. I think my project may need to be re-developed using a component
based framework, since I want the ability to swap and configure components
at runtime, plus the components need to be context aware. I'm thinking
Avalon may be a good fit, but I'm still pretty clueless about some parts of
it, so I'm digging into the docs and code at this moment. I may have to ask
a few questions...
Thanks
-david
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: Off Topic: FSF makes peace with rest of open source world
(not)
Posted by Peter Donald <do...@apache.org>.
At 12:23 PM 6/3/01 -0700, David Duddleston wrote:
>> The
>> vast majority of "GPL" java projects out there violate the GPL, the FSF is
>> quite aware of this and choose to ignore it (RMS called java a blight on
>> the free software wordl)
>
>I assume this is because of the way Java more or less links in with the
>software, so it is considered part of the code? Licenses are so confusing...
Not sure what you mean. Almost any linking will be a violation unless the
whole work is GPL compatible except for JDK. However thats not the real
issue. The real issue is that there is few libraries in java that are GPL
compatible. Even essentials like xml parsers don't really have a showing,
nor can you use standard extentions - thus most "GPL" java projects ignore
this and violate the GPL ;) The exception being the GNU projects which are
relatively clean.
>urggg! If this is the case then, I would also assume that the vast majority
>of applications that use GPL are in violation too. I know there are allot of
>developers taking GPL code and using it in a prosperity software built for a
>client. Does this not violate the GPL? even maybe the LGPL?
It violates the GPL and depending on how they do it the LGPL. Doing things
like that can lead to
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org