You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Nick Chalko <nc...@calpine.com> on 2003/02/05 20:29:06 UTC
RE: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
-----Original Message-----
From: Andrew C. Oliver [mailto:acoliver@apache.org]
Sent: Wednesday, February 05, 2003 11:18 AM
To: Jakarta General List
Subject: Clear the air Re: ATTN: Maven developers [was: primary
distribution location]
Nick Chalko who is one of my own personal favorites (despite him not
fixing commons-vfs's funky file error this morning) is talking about a
project to extend the maven repository in such a way that all Apache
projects could use it. I'd rather not see a forked effort. This is
something I'm pretty sure we can all agree on if we focus on the larger
effort/benefits rather than details.
In the end, the ASF gets to delete the duplicate jars from CVS and all
projects can use Maven, Centipede or some ant tasks to resolve their
depencies.
------------
I hope to have a proposal started on the Wiki tonight (PST). The Maven
repository
has been an essential tool for me for me.
The next step is to play nice with gump.
Then do help with dependencies
Also to make it easy for projects to "brand" themselves with version and
dependency information.
I think Apache can grow a world class solution from the seed of the Maven
Repository.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
Posted by Costin Manolache <cm...@yahoo.com>.
+1 ( a bit too long, but good !)
Costin
Rodent of Unusual Size wrote:
> okey, i'm wading in here, noting as i do the angels high-tailing
> it in the other direction.. :-)
>
> i'm ccing community@apache because i think portions of this
> discussion are important to the entire asf developer
> community, and not just jakarta. (jakarta leads the way
> again! <grin nature="completely non-hostile"/>)
>
> this is my take on the things we need to keep in mind. i
> may be wrong; where i'm unsure, i'm erring on the side
> of conservatism. and i'm saying this stuff with my
> board hat semi-on; that is, i'll be glad to be corrected
> or overruled by the rest of the board, but in the absence
> of such i'm breaking new ground with a tentative prototype
> policy. it's all open to discussion and refinement, but
> it's semi-official. it's just my take on things at the
> moment, but it's a stake in the ground.
>
> now, then. the (at least!) two things we need to keep in
> mind are:
>
> 1. no asf package (or asf contributor acting ex officio
> being an apache contributor) may deliberately
> violate the terms of any licence.
> 2. no code nor activity is permitted that will virally
> infect any of the asf's assets, or those of any user
> of asf packages.
>
> those are pretty much non-negociable; any inadvertent
> violation needs to be corrected AT ONCE as soon as it
> is identified. violating a licence because 'everyone
> else is doing it' or 'the licence-owner has never gone
> after anyone' are not on; we need to do the Right Thing,
> not the cop-out or expedient one. if, for instance,
> we violated one of microsoft's licence terms just
> because everyone else does, the potential harm to the
> asf is enormous: not only massive monetary liability,
> but severe damage to our reputation for integrity.
>
> so we must not distribute any 3p (third-party) packages
> from asf systems if it is not permitted by their licences.
> nor may any of our code automatically go off and fetch
> such packages and start using them on the user's system
> if the packages' licences require *any* sort of acknowledgement
> by the user. that is, if the licence for package 'x' says
> the user must stand on its head and send a paypal donation
> before using 'x', none of our code may automatically download
> 'x' to the user's system. if it's *already* on the user's
> system, we can use it -- but we can't get into any position
> in which we are essentially responsible for transmitting
> someone else's licence terms to the user, and assuming they've
> agreed to comply with them. (i.e., for now i'm ruling
> click-through licences as not permissible for our stuff
> to present.)
>
> as far as sun-bin licensed stuff on ibiblio -- it's not an
> asf system, so the asf is neither liable nor responsible.
> *if* some asf package requires sun-bin stuff, and silently
> goes off to ibiblio to download it, though.. that's not
> allowed. telling the user it needs to download the
> sun-bin stuff is fine; telling it the stuff can be found
> on ibiblio.. well, i *think* that's okey, but it's kinda
> grey.
>
> if someone is using an asf package that does *not*, itself,
> require such stuff, but is using the asf package to build
> something that does, i think we're pretty much okey there
> too, since the user needs to explicitly state the dependency.
> i think it's possible to consider stating the dependency
> as equivalent to having the stuff already on the system --
> but again it's a grey area, and i hope roy can shed some
> light in this darkness. again, autofetching it by default
> from a known location -- such as ibiblio or sun -- once the
> dependency has been stated by the user *should* be okey.
> i think.
>
> i'm not even going to touch the infection issue at this point;
> it always makes my cephalic nodule hurt horribly. let's
> just say that we can't do anything that will trigger an
> infection of the asf's assets -- or those of someone using
> asf packages. if a licence permits *linking* against
> a library, there's no prohibition on our packages requiring
> the library in order to run properly. if a licence allows
> us to include the library, as a general rule we can package
> it with our stuff. if by linking with it or including it
> in our distributions we trigger a clause in its licence that
> either overrides the asf licence on our stuff, or forces
> the user to comply with rules more restrictive than the
> asf licence.. then we mustn't do that.
>
> i hope this all makes sense, to some degree. please follow
> up to community@apache.org.
>
> and because recording incremental advances before a final
> policy is published seems like an appropriate use, i've
> set up http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
> as a work area where we can distill the rules before they
> get finalised and formally published on www.apache.org.
>
> i need to stress that the wiki page is for *recording*, not
> discussing. if someone wants to take a look at the current
> state of things, the wiki is good method -- but hammering
> out the details needs to happen on the mailing list.
>
> long message.. thanks for your patience!
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Conor MacNeill <co...@cortexebusiness.com.au> writes:
> Morgan Delagrange wrote:
> > OK, Java-specific question. It seems likely that
> > altering or inlining LGPL code pollutes the Apache
> > license. Are you of the opinion that IMPORTING but
> > not altering or distributing LGPL classes pollutes the
> > Apache licecnse? And if so, can that be stated on the
> > Wiki page? If LGPL code cannot be imported, it's
> > pretty much useless in any capacity for Java projects.
> >
>
>
> Refer to Roy's messages of yesterday. Importing is enough to disallow
> the code from use within ASF code.
>
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgNo=1419
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgNo=1429
As I understand it, class loading the code via configuration files
(e.g. _not_ referencing the (L)GPL'd code in our .java sources at all)
would be okay.
--
Daniel Rall <dl...@finemaltcoding.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: [OT] Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Justin Erenkrantz <je...@apache.org> writes:
> --On Wednesday, February 05, 2003 21:25:47 -0800 Daniel Rall
> <dl...@finemaltcoding.com> wrote:
>
>
> > can't change /opt/tomcat/webapps/eyebrowse/index/apche.org/community
>
> Man, I hope our search engine doesn't index www.apche.org.
Heh, me too.
> I actually encountered this site at ApacheCon while Brian and David
> were running etherpeg. ;-) -- justin
So the Lucene index directory really was set to apche.org in the
database. I copied the Lucene meta data files over and ran a quick
SQL update against the db to activate the apache.org version. Because
of the unix permissions on that other directory, Lucene couldn't write
to it and I can't remove it. Might want to nuke when you can steal a
moment.
--
Daniel Rall <dl...@finemaltcoding.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
[OT] Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven
developers ...]
Posted by Justin Erenkrantz <je...@apache.org>.
--On Wednesday, February 05, 2003 21:25:47 -0800 Daniel Rall
<dl...@finemaltcoding.com> wrote:
> can't change /opt/tomcat/webapps/eyebrowse/index/apche.org/community
Man, I hope our search engine doesn't index www.apche.org.
I actually encountered this site at ApacheCon while Brian and David were
running etherpeg. ;-) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven
developers ...]
Posted by Pier Fumagalli <pi...@apache.org>.
On 6/2/03 5:25, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Morgan Delagrange <md...@yahoo.com> writes:
>
>> Dang, I wish that archive was searchable. [wink, wink]
>
> Pier, the unix permissions on the Lucene index directory for
> community@apache.org don't allow writes by the unix user "apache"
> which Catalina is running as:
>
> dlr@nagoya:dlr$ ls -lad
> /opt/tomcat/webapps/eyebrowse/index/apche.org/community
> drwxr-sr-x 2 root apache 1536 Jan 30 12:10
> /opt/tomcat/webapps/eyebrowse/index/apche.org/community/
>
> nagoya gave me the finger when I tried to correct them:
>
> dlr@nagoya:dlr$ chmod -R g+w
> /opt/tomcat/webapps/eyebrowse/index/apche.org/community
> chmod: WARNING: can't change
> /opt/tomcat/webapps/eyebrowse/index/apche.org/community
>
> Calvary?
Fuck, my bad... Should be fixed now...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Morgan Delagrange <md...@yahoo.com> writes:
> Dang, I wish that archive was searchable. [wink, wink]
Pier, the unix permissions on the Lucene index directory for
community@apache.org don't allow writes by the unix user "apache"
which Catalina is running as:
dlr@nagoya:dlr$ ls -lad /opt/tomcat/webapps/eyebrowse/index/apche.org/community
drwxr-sr-x 2 root apache 1536 Jan 30 12:10 /opt/tomcat/webapps/eyebrowse/index/apche.org/community/
nagoya gave me the finger when I tried to correct them:
dlr@nagoya:dlr$ chmod -R g+w /opt/tomcat/webapps/eyebrowse/index/apche.org/community
chmod: WARNING: can't change /opt/tomcat/webapps/eyebrowse/index/apche.org/community
Calvary?
--
Daniel Rall <dl...@finemaltcoding.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Ken, can we get this on the Wiki page to protect
> feeble-minded folks like me?
> http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
I had just finished doing that. I hope that I got them right.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> Morgan Delagrange wrote:
> > OK, Java-specific question. It seems likely that
> > altering or inlining LGPL code pollutes the Apache
> > license. Are you of the opinion that IMPORTING
> but
> > not altering or distributing LGPL classes pollutes
> the
> > Apache licecnse? And if so, can that be stated on
> the
> > Wiki page? If LGPL code cannot be imported, it's
> > pretty much useless in any capacity for Java
> projects.
> >
>
> Refer to Roy's messages of yesterday. Importing is
> enough to disallow the
> code from use within ASF code.
>
>
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgNo=1419
>
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgNo=1429
>
>
> Conor
>
Good enough. Section 6 does seem pretty damn rigid.
I thought we might have covered imports specifically,
but I had already deleted yesterday's mail. Dang, I
wish that archive was searchable. [wink, wink]
Ken, can we get this on the Wiki page to protect
feeble-minded folks like me?
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers
...]
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Morgan Delagrange wrote:
> OK, Java-specific question. It seems likely that
> altering or inlining LGPL code pollutes the Apache
> license. Are you of the opinion that IMPORTING but
> not altering or distributing LGPL classes pollutes the
> Apache licecnse? And if so, can that be stated on the
> Wiki page? If LGPL code cannot be imported, it's
> pretty much useless in any capacity for Java projects.
>
Refer to Roy's messages of yesterday. Importing is enough to disallow the
code from use within ASF code.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgNo=1419
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=community@apache.org&msgNo=1429
Conor
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Stefano Mazzocchi <st...@apache.org> writes:
...
> If you use *regular* programming practices you have to do
>
> import LGPLObject;
>
> then
>
> LGPLObject o = new LGPLObject();
> o.doSomething();
>
> that will
>
> 1) ask the classloader to find that object
> 2) allocate memory for it
> 3) create the object
> 4) invoke the object method doSomething
>
> This means, mostly, for legal sakes that the LGPLObject *MUST* be in
> the classloading space during compilation time.
>
>
> Now, if we use reflection, we can do
>
> Class c = Class.forName("LGPLObject");
> Object o = c.newInstance();
> Method doSomething = c.getMethod("doSomething");
> doSomething.invoke();
>
> which compiles even without having the LGPL library in your classpath.
>
> *BUT* programming java in this way is *FOOLISH*. Reflection was
> created to load classes programmatically at runtime, it was not
> created as a way to route around legal problems.
Integrating seems like it works best when said code implements a
non-viral API which can be imported (not certain whether there is
(L)GPL code which does this). In such a situation, you can import the
interfaces and class-load the implementation.
import FreeInterface;
...
String className = Sytem.getProperty("FreeInterface.implementation");
Class c = Class.forName(className);
FreeInterface obj = c.newInstance();
FreeInterface might be something like the java.sql.Connection
interface from Sun's JDBC API. The above allows you to avoid the
overhead associated with using reflection from pure Java code, while
still leveraging virally-licensed code.
--
Daniel Rall <dl...@finemaltcoding.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Santiago Gala <sg...@hisitech.com>.
Justin Erenkrantz wrote:
> --On Friday, February 7, 2003 3:31 PM +0100 Torsten Curdt
> <tc...@dff.st> wrote:
>
>> Is it really like that? I mean: how does it work for the PHP guys
>> with all the modules and libraries then?
>
>
> PHP uses C, so the LGPL rules are clear.
>
> It sorta sucks, but we *can* link against LGPL/GPL code in httpd. I
> believe we don't allow binaries to be distributed that link against such
> libraries though. The case I explicitly remember having a conversation
> at dev@apr was over the use of Electric Fence which is GPL. Someone
> (Greg?) finally said it was okay.
>
> I believe the FSF has an ulterior motive for keeping the Java situation
> quite murky. -- justin
s/java/C#/g applies equally, isn't it? (not in keeping it murky, but in
the issues of LGPL license)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Justin Erenkrantz wrote:
>
>>
>> I believe the FSF has an ulterior motive for keeping the Java
>> situation quite murky. -- justin
>
>
> I'd like to caution you against attributing motives to other's actions
> or inactions. I'm not making this suggestion with any official Apache
> hat on, but based on my experience that such statements rarely lead to
> productive consequences.
>
> As for me, I would like to observe that we have the public statements
> made by the FSF, including the text of the GPL license. We have the
> knowledge that this issue has been around for a long time and has never
> been resolved. And we know that that people like Brian have invested a
> fair amount of time on this topic.
>
> What I conclude from this is that it would be both difficult and
> unlikely for a successful resolution of this issue. Despite the fact
> that quite a number of us (myself included) would love to see this
> resolved.
As Santiago hints, I bet Mono will lead the way for this. We care to
have this resolved, but it's not vital to have the FSF flag on our camp.
For them is a different story (even if, they already released their
libraries using the MIT license and RMS wasn't pleased, to say it midly)
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Sam Ruby <ru...@apache.org>.
Justin Erenkrantz wrote:
>
> I believe the FSF has an ulterior motive for keeping the Java situation
> quite murky. -- justin
I'd like to caution you against attributing motives to other's actions
or inactions. I'm not making this suggestion with any official Apache
hat on, but based on my experience that such statements rarely lead to
productive consequences.
As for me, I would like to observe that we have the public statements
made by the FSF, including the text of the GPL license. We have the
knowledge that this issue has been around for a long time and has never
been resolved. And we know that that people like Brian have invested a
fair amount of time on this topic.
What I conclude from this is that it would be both difficult and
unlikely for a successful resolution of this issue. Despite the fact
that quite a number of us (myself included) would love to see this resolved.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, February 7, 2003 3:31 PM +0100 Torsten Curdt
<tc...@dff.st> wrote:
> Is it really like that? I mean: how does it work for the PHP guys
> with all the modules and libraries then?
PHP uses C, so the LGPL rules are clear.
It sorta sucks, but we *can* link against LGPL/GPL code in httpd. I
believe we don't allow binaries to be distributed that link against
such libraries though. The case I explicitly remember having a
conversation at dev@apr was over the use of Electric Fence which is
GPL. Someone (Greg?) finally said it was okay.
I believe the FSF has an ulterior motive for keeping the Java
situation quite murky. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Sam Ruby <ru...@apache.org>.
Torsten Curdt wrote:
>>> Actually I think we could make our lifes much easier by having better
>>> build systems! So we would only have the Apache code in out
>>> repositories and let the build system get the external dependencies
>>> for us. AFAIK this should save us from legal troubles.
>>
>> No, not necessarely. The problem with LGPL is that it doesn't define
>> (in java) where the library stops and where your program starts.
>> Having it downloaded from another machine, doesn't change that at all.
>
> Hm... but the question is: if something relies on something terms of
> *uses* it's API does this make it a problem? I mean that would be really
> like a viral infection! You couldn't even connect to software that is
> under (L)GPL. (What about protocols?)
>
> Is it really like that? I mean: how does it work for the PHP guys with
> all the modules and libraries then?
In the case of GPL, it is clear and works as you fear above. Protocols
(such as XML RPC or SOAP) are fine.
ISTR code being removed from PHP due to such considerations, but it has
been a while since I have been involved with that project.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
> <OT>Is it moch or mock? I thought it was "mock" - anyway</OT>
sorry, my fault. Mock classes :)
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Torsten Curdt <tc...@dff.st>.
>> Actually I think we could make our lifes much easier by having better
>> build systems! So we would only have the Apache code in out
>> repositories and let the build system get the external dependencies
>> for us. AFAIK this should save us from legal troubles.
>
>
> No, not necessarely. The problem with LGPL is that it doesn't define (in
> java) where the library stops and where your program starts. Having it
> downloaded from another machine, doesn't change that at all.
Hm... but the question is: if something relies on something terms of
*uses* it's API does this make it a problem? I mean that would be really
like a viral infection! You couldn't even connect to software that is
under (L)GPL. (What about protocols?)
Is it really like that? I mean: how does it work for the PHP guys with
all the modules and libraries then?
<snip/>
> For those who don't know what a moch class is (sorry Torsten, but don't
> forget you are talking to a language-neutral community here), several
yeah - sorry :)
> java projects that depend on many different libraries (potentially
> optional) created what we call "moch classes" instead of placing the
> libraries in CVS
>
> A moch class is a skeleton class.
<OT>Is it moch or mock? I thought it was "mock" - anyway</OT>
> Cocoon developers suggested that we could use moch classes to get around
> LGPL problems, but I voted against that approach because a moch class
> *IS* a derivative work of that library (even if a very dumb derivative
> work), thus we cannot license the moch class under the apache license
> and we are back on the LGPL problem, even if it covers just that thin
> moch code.
>
> There is no official statement around the use of moch classes, just my
> negative vote and Torsten is asking for more official statements on this.
Hey, it's not I don't trust you ;-) ...but IMHO it's so absurd that they
have to be the same license that I think it would be good have this
checked by laywer or something like that...
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
> Actually I think we could make our lifes much easier by having better
> build systems! So we would only have the Apache code in out repositories
> and let the build system get the external dependencies for us. AFAIK
> this should save us from legal troubles.
No, not necessarely. The problem with LGPL is that it doesn't define (in
java) where the library stops and where your program starts. Having it
downloaded from another machine, doesn't change that at all.
> The distributions would become much smaller (less load and traffic for
> the Apache web sites) and it's the ideal sollution when you don't need
> and or want some optional components.
>
> ..the only drawback is that the distributions are not self-contained and
> not compile-able out-of-the-box.
>
> I mean I hate it when I have to collect all the libraries to build a
> specific project - but hey: if the build system does that for me I am
> fine :)
This is what several different efforts are trying to do. I think there
is enough pressure for this that something will come out.
> I would even have the benefit to (de)select optional packages!!
>
> ...it's so ridiculous that even mock classes have to have the same
> license as the full implementation. (Someone really really sure about
> this?)
For those who don't know what a moch class is (sorry Torsten, but don't
forget you are talking to a language-neutral community here), several
java projects that depend on many different libraries (potentially
optional) created what we call "moch classes" instead of placing the
libraries in CVS.
A moch class is a skeleton class.
It contains only the (empty) methods and data definitions. It is used to
allow us to compile our code in a strongly-typed fashion (compared to
the reflection idea which is weakly typed - therefore, if you mispell
the method name the compiler will compile anyway and you would just fail
at runtime).
Moch classes are very handy (they allow, for example, Cocoon to be
compiled under compilation-intensive IDEs such as Eclipse without having
to download *all* the libraries that we depend on which we are not
legally allowed to redistribute)
Cocoon developers suggested that we could use moch classes to get around
LGPL problems, but I voted against that approach because a moch class
*IS* a derivative work of that library (even if a very dumb derivative
work), thus we cannot license the moch class under the apache license
and we are back on the LGPL problem, even if it covers just that thin
moch code.
There is no official statement around the use of moch classes, just my
negative vote and Torsten is asking for more official statements on this.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
RE: build systems vs. license issues [Re: Hashing it out ...]
Posted by Martin van den Bemt <ma...@mvdb.net>.
Nice url : http://nbbuild.netbeans.org/scrambler.html
I mailed Jesse Glick for more information btw..
Mvgr,
Martin
> -----Original Message-----
> From: Sam Ruby [mailto:rubys@apache.org]
> Sent: Friday, February 07, 2003 15:14
> To: community@apache.org
> Subject: Re: build systems vs. license issues [Re: Hashing it out ...]
>
>
> Santiago Gala wrote:
> > Torsten Curdt wrote:
> > (...)
> >
> >> ..the only drawback is that the distributions are not self-contained
> >> and not compile-able out-of-the-box.
> >
> > Be sure to blame the approprite culprit, so that user frustratin does
> > not stand on us. Like "company XXX forbids us to bundle a essential
> > component because of licensing issues. Please go to <url>, download it
> > and put it here".
>
> +1
>
> > OTOH, one of the main problems is Sun Binary License. This license
> > *allows* redistribution with our products, just it does not allow
> > individual download. So the problem is mainly for *new* developers,
> > having more errors and steeper learning curve.
>
> +1
>
> > A nice workaround for Sun's jars would be to have a software release
> > called "external_dependency_solver", where several or those jars could
> > be bundled, together with version checking and some documentation. This
> > would be aimed to developers, as part of the "Apache Java toolkit"
> >
> > Hei, experts, would this make a way out of this? Is it twisting things
> > too much?
>
> This is twisting things too much. I am aware of other dicussions
> outside the scope of Apache. In those discussions on other topics, the
> crucial question is one of "value add".
>
> > On the other side, negotiating exemptions or rewording of licenses is
> > good, but it is a heavy and difficult path.
> >
> > It's sad, but we want to play by the rules until we manage to change
> > them ;-)
>
> +1
>
> > Regards,
> > Santiago
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Sam Ruby <ru...@apache.org>.
Santiago Gala wrote:
> Torsten Curdt wrote:
> (...)
>
>> ..the only drawback is that the distributions are not self-contained
>> and not compile-able out-of-the-box.
>
> Be sure to blame the approprite culprit, so that user frustratin does
> not stand on us. Like "company XXX forbids us to bundle a essential
> component because of licensing issues. Please go to <url>, download it
> and put it here".
+1
> OTOH, one of the main problems is Sun Binary License. This license
> *allows* redistribution with our products, just it does not allow
> individual download. So the problem is mainly for *new* developers,
> having more errors and steeper learning curve.
+1
> A nice workaround for Sun's jars would be to have a software release
> called "external_dependency_solver", where several or those jars could
> be bundled, together with version checking and some documentation. This
> would be aimed to developers, as part of the "Apache Java toolkit"
>
> Hei, experts, would this make a way out of this? Is it twisting things
> too much?
This is twisting things too much. I am aware of other dicussions
outside the scope of Apache. In those discussions on other topics, the
crucial question is one of "value add".
> On the other side, negotiating exemptions or rewording of licenses is
> good, but it is a heavy and difficult path.
>
> It's sad, but we want to play by the rules until we manage to change
> them ;-)
+1
> Regards,
> Santiago
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On Fri, 7 Feb 2003, Santiago Gala wrote:
> OTOH, one of the main problems is Sun Binary License. This license
> *allows* redistribution with our products, just it does not allow
> individual download.
Nor would we, the ASF, like to be a 'mirror' for non ASF code.
> So the problem is mainly for *new* developers, having more errors and
> steeper learning curve.
Bear in mind that if we -really- care about this; you could ask the board
to have a quiet word with SUN to see what we can negotiate. But given that
we -can- ship them for normal end users I guess there is not that much of
a win here.
Dw
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: build systems vs. license issues [Re: Hashing it out ...]
Posted by Santiago Gala <sg...@hisitech.com>.
Torsten Curdt wrote:
(...)
>
> ..the only drawback is that the distributions are not self-contained and
> not compile-able out-of-the-box.
>
Be sure to blame the approprite culprit, so that user frustratin does
not stand on us. Like "company XXX forbids us to bundle a essential
component because of licensing issues. Please go to <url>, download it
and put it here".
OTOH, one of the main problems is Sun Binary License. This license
*allows* redistribution with our products, just it does not allow
individual download. So the problem is mainly for *new* developers,
having more errors and steeper learning curve.
A nice workaround for Sun's jars would be to have a software release
called "external_dependency_solver", where several or those jars could
be bundled, together with version checking and some documentation. This
would be aimed to developers, as part of the "Apache Java toolkit"
Hei, experts, would this make a way out of this? Is it twisting things
too much?
> I mean I hate it when I have to collect all the libraries to build a
> specific project - but hey: if the build system does that for me I am
> fine :)
>
The problem here is that the build system should not assume the
responsibility of "clicking" on behalf of the user. So short of opening
a browser window and giving instructions about the directory to put the
result into (only if the required stuff is not yet there), there is
little more that can be done on this side.
On the other side, negotiating exemptions or rewording of licenses is
good, but it is a heavy and difficult path.
It's sad, but we want to play by the rules until we manage to change
them ;-)
Regards,
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
build systems vs. license issues [Re: Hashing it out ...]
Posted by Torsten Curdt <tc...@dff.st>.
> *BUT* programming java in this way is *FOOLISH*. Reflection was created
> to load classes programmatically at runtime, it was not created as a way
> to route around legal problems.
Indeed!! Definitly, +1000
Regarding all the licensing issues...
Actually I think we could make our lifes much easier by having better
build systems! So we would only have the Apache code in out repositories
and let the build system get the external dependencies for us. AFAIK
this should save us from legal troubles.
The distributions would become much smaller (less load and traffic for
the Apache web sites) and it's the ideal sollution when you don't need
and or want some optional components.
..the only drawback is that the distributions are not self-contained and
not compile-able out-of-the-box.
I mean I hate it when I have to collect all the libraries to build a
specific project - but hey: if the build system does that for me I am
fine :)
I would even have the benefit to (de)select optional packages!!
...it's so ridiculous that even mock classes have to have the same
license as the full implementation. (Someone really really sure about this?)
my 2 cents
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers
...]
Posted by Santiago Gala <sg...@hisitech.com>.
Stefano Mazzocchi wrote:
> Santiago Gala wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Morgan Delagrange wrote:
>>>
>>>> OK, Java-specific question. It seems likely that
>>>> altering or inlining LGPL code pollutes the Apache
>>>> license. Are you of the opinion that IMPORTING but
>>>> not altering or distributing LGPL classes pollutes the
>>>> Apache licecnse? And if so, can that be stated on the
>>>> Wiki page? If LGPL code cannot be imported, it's
>>>> pretty much useless in any capacity for Java projects.
>>>
>>>
>>>
>>>
>>> Bingo.
>>>
>>> The only *reasonable* way of dealing with LGLP stuff would be thru
>>> some for of reflection (reflection, for those who don't know, is the
>>> ability for java to connect to 'named' resources of classes. it's the
>>> most *dynamic* form of loading for a language which is already
>>> entirely dynamically loaded).
>>>
>>> So, suppose that LGPLObject is there somewhere in your classloading
>>> space (the classloader is the virtual machine subsystem that looks
>>> for your classes, classes being the objects and main units for java
>>> programs, all classes are always dynamically loaded)
>>>
>>> and this LGPLObject contains the method (java terminology for a
>>> function) called doSomething()
>>>
>>> If you use *regular* programming practices you have to do
>>>
>>> import LGPLObject;
>>>
>>> then
>>>
>>> LGPLObject o = new LGPLObject();
>>> o.doSomething();
>>>
>>> that will
>>>
>>> 1) ask the classloader to find that object
>>> 2) allocate memory for it
>>> 3) create the object
>>> 4) invoke the object method doSomething
>>>
>>> This means, mostly, for legal sakes that the LGPLObject *MUST* be in
>>> the classloading space during compilation time.
>>>
>>
>> In legal terms, your program will not build without a class named
>> LGPLObject which has a public doSomething() method.
>
>
> Incorrect: it will *build*, but it will not *execute*.
>
It will not build if the class is not in your classpath, it will execute
and give an Exception if the class is not in your classpath. I'm
speaking about *plain* import up here.
>> So, you *depend* on it. In a sense, with import you're stating
>> dependency in your sources.
>
>
> True. This is the reason why this legal route-around will not work
> against GPL, but only against LGPL.
>
This dependency was stated for the plain import.
>>> Now, if we use reflection, we can do
>>>
>>> Class c = Class.forName("LGPLObject");
>>> Object o = c.newInstance();
>>> Method doSomething = c.getMethod("doSomething");
>>> doSomething.invoke();
>>>
>>> which compiles even without having the LGPL library in your classpath.
>>>
>>
>> In legal term, again, your program will *behave differently* if a
>> class named LGPLObject exists in your runtime environment and it
>> happens to have a doSomething() public method. With dynamic loading
>> you're not stating dependency, merely *acknowledging existence*.
>
>
> This accademic trick is done to prove there is a way to totally isolate
> the virality of LGPL in Java (at least, that's my personal opinion). I
> think it would be pretty hard to state that my program can be considered
> part of the LGPL-ed library if I call build it even if it's not even
> present on my disk.
>
I'm not sure about this one. You can write a work that is a derivative
work from Vivaldi's Four Seasons from your memory, without having the
score or a disk at home.
>> As the concept of "derivative work" is about something that extends or
>> change a preexisting work, the second approach will probably skip it
>> (specially if your program tests for the result of the snippet code
>> and survives when the given class is not in the path).
>
>
> Exactly.
>
>> I don't think that even reflection will stand in court if your program
>> cannot perform its duty without the given library being there. I.E.
>> fine when alternate services can perform a task, or for non-essential
>> components of a project.
>
>
> Again, you are not taking into account that I working again the LGPL,
> not the GPL. There is no way to route around GPL. It was very carefully
> designed for that purpose.
>
True. I stand corrected. But, as Andy has just pointed in
jakarta-general:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=general@jakarta.apache.org&msgNo=14335
I'm not sure a plain import will break the LGPL rules.
Dynamic loading of a full "GPL" thing (not essential) for use in a
project, I'm not sure will raise any issue, and it is in a sense routing
around it. I write this from a linux machine, and I'm not obliged to
make GPL all of my works, as Andy pointed to me privately yesterdat.
Though most of the things C stuff I compile does "#include
linux/something.h" to build. And the source of all of these includes is
in the kernel, which is GPL. I can use GNU-make to build, even to build
propietary code, I think. What I cannot do is to modify GNU-make and
keep modifications propietary. But see below.
>>> *BUT* programming java in this way is *FOOLISH*. Reflection was
>>> created to load classes programmatically at runtime, it was not
>>> created as a way to route around legal problems.
>>>
>>
>> +1
>>
>> <disclaimer type="IANAL">
>> ditto. Also, I am just a plain committer, so take it as just my
>> opinion.
>> </disclaimer>
>
The disclaimer applies doubly here.
>
> let me state again that I consider this discussion pretty accademic
> (there is no way in the world I would suggest going down the reflection
> path to use a LGPL library... it would be much easier to rewrite the
> damn library or convince the author to change the licensing!)
>
> Still, I think we need to sort out all possible cases since they're
> going to come up again in the future.
>
Yes, I'm even more interested because some of the work I do involves
using or modifying Open Source code in companies. So, it's not just
something that affects me as Apache committer, but also as a professional.
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers
...]
Posted by Stefano Mazzocchi <st...@apache.org>.
Santiago Gala wrote:
> Stefano Mazzocchi wrote:
>
>> Morgan Delagrange wrote:
>>
>>> OK, Java-specific question. It seems likely that
>>> altering or inlining LGPL code pollutes the Apache
>>> license. Are you of the opinion that IMPORTING but
>>> not altering or distributing LGPL classes pollutes the
>>> Apache licecnse? And if so, can that be stated on the
>>> Wiki page? If LGPL code cannot be imported, it's
>>> pretty much useless in any capacity for Java projects.
>>
>>
>>
>> Bingo.
>>
>> The only *reasonable* way of dealing with LGLP stuff would be thru
>> some for of reflection (reflection, for those who don't know, is the
>> ability for java to connect to 'named' resources of classes. it's the
>> most *dynamic* form of loading for a language which is already
>> entirely dynamically loaded).
>>
>> So, suppose that LGPLObject is there somewhere in your classloading
>> space (the classloader is the virtual machine subsystem that looks for
>> your classes, classes being the objects and main units for java
>> programs, all classes are always dynamically loaded)
>>
>> and this LGPLObject contains the method (java terminology for a
>> function) called doSomething()
>>
>> If you use *regular* programming practices you have to do
>>
>> import LGPLObject;
>>
>> then
>>
>> LGPLObject o = new LGPLObject();
>> o.doSomething();
>>
>> that will
>>
>> 1) ask the classloader to find that object
>> 2) allocate memory for it
>> 3) create the object
>> 4) invoke the object method doSomething
>>
>> This means, mostly, for legal sakes that the LGPLObject *MUST* be in
>> the classloading space during compilation time.
>>
>
> In legal terms, your program will not build without a class named
> LGPLObject which has a public doSomething() method.
Incorrect: it will *build*, but it will not *execute*.
> So, you *depend* on
> it. In a sense, with import you're stating dependency in your sources.
True. This is the reason why this legal route-around will not work
against GPL, but only against LGPL.
>> Now, if we use reflection, we can do
>>
>> Class c = Class.forName("LGPLObject");
>> Object o = c.newInstance();
>> Method doSomething = c.getMethod("doSomething");
>> doSomething.invoke();
>>
>> which compiles even without having the LGPL library in your classpath.
>>
>
> In legal term, again, your program will *behave differently* if a class
> named LGPLObject exists in your runtime environment and it happens to
> have a doSomething() public method. With dynamic loading you're not
> stating dependency, merely *acknowledging existence*.
This accademic trick is done to prove there is a way to totally isolate
the virality of LGPL in Java (at least, that's my personal opinion). I
think it would be pretty hard to state that my program can be considered
part of the LGPL-ed library if I call build it even if it's not even
present on my disk.
> As the concept of "derivative work" is about something that extends or
> change a preexisting work, the second approach will probably skip it
> (specially if your program tests for the result of the snippet code and
> survives when the given class is not in the path).
Exactly.
> I don't think that even reflection will stand in court if your program
> cannot perform its duty without the given library being there. I.E. fine
> when alternate services can perform a task, or for non-essential
> components of a project.
Again, you are not taking into account that I working again the LGPL,
not the GPL. There is no way to route around GPL. It was very carefully
designed for that purpose.
>> *BUT* programming java in this way is *FOOLISH*. Reflection was
>> created to load classes programmatically at runtime, it was not
>> created as a way to route around legal problems.
>>
>
> +1
>
> <disclaimer type="IANAL">
> ditto. Also, I am just a plain committer, so take it as just my opinion.
> </disclaimer>
let me state again that I consider this discussion pretty accademic
(there is no way in the world I would suggest going down the reflection
path to use a LGPL library... it would be much easier to rewrite the
damn library or convince the author to change the licensing!)
Still, I think we need to sort out all possible cases since they're
going to come up again in the future.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers
...]
Posted by Santiago Gala <sg...@hisitech.com>.
Stefano Mazzocchi wrote:
> Morgan Delagrange wrote:
>
>> OK, Java-specific question. It seems likely that
>> altering or inlining LGPL code pollutes the Apache
>> license. Are you of the opinion that IMPORTING but
>> not altering or distributing LGPL classes pollutes the
>> Apache licecnse? And if so, can that be stated on the
>> Wiki page? If LGPL code cannot be imported, it's
>> pretty much useless in any capacity for Java projects.
>
>
> Bingo.
>
> The only *reasonable* way of dealing with LGLP stuff would be thru some
> for of reflection (reflection, for those who don't know, is the ability
> for java to connect to 'named' resources of classes. it's the most
> *dynamic* form of loading for a language which is already entirely
> dynamically loaded).
>
> So, suppose that LGPLObject is there somewhere in your classloading
> space (the classloader is the virtual machine subsystem that looks for
> your classes, classes being the objects and main units for java
> programs, all classes are always dynamically loaded)
>
> and this LGPLObject contains the method (java terminology for a
> function) called doSomething()
>
> If you use *regular* programming practices you have to do
>
> import LGPLObject;
>
> then
>
> LGPLObject o = new LGPLObject();
> o.doSomething();
>
> that will
>
> 1) ask the classloader to find that object
> 2) allocate memory for it
> 3) create the object
> 4) invoke the object method doSomething
>
> This means, mostly, for legal sakes that the LGPLObject *MUST* be in the
> classloading space during compilation time.
>
In legal terms, your program will not build without a class named
LGPLObject which has a public doSomething() method. So, you *depend* on
it. In a sense, with import you're stating dependency in your sources.
> Now, if we use reflection, we can do
>
> Class c = Class.forName("LGPLObject");
> Object o = c.newInstance();
> Method doSomething = c.getMethod("doSomething");
> doSomething.invoke();
>
> which compiles even without having the LGPL library in your classpath.
>
In legal term, again, your program will *behave differently* if a class
named LGPLObject exists in your runtime environment and it happens to
have a doSomething() public method. With dynamic loading you're not
stating dependency, merely *acknowledging existence*.
As the concept of "derivative work" is about something that extends or
change a preexisting work, the second approach will probably skip it
(specially if your program tests for the result of the snippet code and
survives when the given class is not in the path).
I don't think that even reflection will stand in court if your program
cannot perform its duty without the given library being there. I.E. fine
when alternate services can perform a task, or for non-essential
components of a project.
> *BUT* programming java in this way is *FOOLISH*. Reflection was created
> to load classes programmatically at runtime, it was not created as a way
> to route around legal problems.
>
+1
<disclaimer type="IANAL">
ditto. Also, I am just a plain committer, so take it as just my opinion.
</disclaimer>
Regards,
Santiago
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers
...]
Posted by Stefano Mazzocchi <st...@apache.org>.
Morgan Delagrange wrote:
> OK, Java-specific question. It seems likely that
> altering or inlining LGPL code pollutes the Apache
> license. Are you of the opinion that IMPORTING but
> not altering or distributing LGPL classes pollutes the
> Apache licecnse? And if so, can that be stated on the
> Wiki page? If LGPL code cannot be imported, it's
> pretty much useless in any capacity for Java projects.
Bingo.
The only *reasonable* way of dealing with LGLP stuff would be thru some
for of reflection (reflection, for those who don't know, is the ability
for java to connect to 'named' resources of classes. it's the most
*dynamic* form of loading for a language which is already entirely
dynamically loaded).
So, suppose that LGPLObject is there somewhere in your classloading
space (the classloader is the virtual machine subsystem that looks for
your classes, classes being the objects and main units for java
programs, all classes are always dynamically loaded)
and this LGPLObject contains the method (java terminology for a
function) called doSomething()
If you use *regular* programming practices you have to do
import LGPLObject;
then
LGPLObject o = new LGPLObject();
o.doSomething();
that will
1) ask the classloader to find that object
2) allocate memory for it
3) create the object
4) invoke the object method doSomething
This means, mostly, for legal sakes that the LGPLObject *MUST* be in the
classloading space during compilation time.
Now, if we use reflection, we can do
Class c = Class.forName("LGPLObject");
Object o = c.newInstance();
Method doSomething = c.getMethod("doSomething");
doSomething.invoke();
which compiles even without having the LGPL library in your classpath.
*BUT* programming java in this way is *FOOLISH*. Reflection was created
to load classes programmatically at runtime, it was not created as a way
to route around legal problems.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Hashing it out [was: Re: Clear the air Re: ATTN: Maven developers ...]
Posted by Morgan Delagrange <md...@yahoo.com>.
OK, Java-specific question. It seems likely that
altering or inlining LGPL code pollutes the Apache
license. Are you of the opinion that IMPORTING but
not altering or distributing LGPL classes pollutes the
Apache licecnse? And if so, can that be stated on the
Wiki page? If LGPL code cannot be imported, it's
pretty much useless in any capacity for Java projects.
- Morgan
--- Rodent of Unusual Size <Ke...@Golux.Com> wrote:
[snip]
> i'm not even going to touch the infection issue at
> this point;
> it always makes my cephalic nodule hurt horribly.
> let's
> just say that we can't do anything that will trigger
> an
> infection of the asf's assets -- or those of someone
> using
> asf packages. if a licence permits *linking*
> against
> a library, there's no prohibition on our packages
> requiring
> the library in order to run properly. if a licence
> allows
> us to include the library, as a general rule we can
> package
> it with our stuff. if by linking with it or
> including it
> in our distributions we trigger a clause in its
> licence that
> either overrides the asf licence on our stuff, or
> forces
> the user to comply with rules more restrictive than
> the
> asf licence.. then we mustn't do that.
[snip]
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
Posted by robert burrell donkin <ro...@AlmostHuman.com>.
On Wednesday, February 5, 2003, at 09:29 PM, Rodent of Unusual Size wrote:
<snip>
> so we must not distribute any 3p (third-party) packages
> from asf systems if it is not permitted by their licences.
> nor may any of our code automatically go off and fetch
> such packages and start using them on the user's system
> if the packages' licences require *any* sort of acknowledgement
> by the user. that is, if the licence for package 'x' says
> the user must stand on its head and send a paypal donation
> before using 'x', none of our code may automatically download
> 'x' to the user's system. if it's *already* on the user's
> system, we can use it -- but we can't get into any position
> in which we are essentially responsible for transmitting
> someone else's licence terms to the user, and assuming they've
> agreed to comply with them. (i.e., for now i'm ruling
> click-through licences as not permissible for our stuff
> to present.)
what would be allowed (though) in these cases (i suppose) is *not*
downloading the package but instead presenting the user with a nice
message saying that 3rd party package XXX is required by function YYY -
and giving an official url where it can be obtained.
this would be a *big* improvement over the situation (without automated
download) where the user has to find out where a copy of the necessary
package can be downloaded from.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
okey, i'm wading in here, noting as i do the angels high-tailing
it in the other direction.. :-)
i'm ccing community@apache because i think portions of this
discussion are important to the entire asf developer
community, and not just jakarta. (jakarta leads the way
again! <grin nature="completely non-hostile"/>)
this is my take on the things we need to keep in mind. i
may be wrong; where i'm unsure, i'm erring on the side
of conservatism. and i'm saying this stuff with my
board hat semi-on; that is, i'll be glad to be corrected
or overruled by the rest of the board, but in the absence
of such i'm breaking new ground with a tentative prototype
policy. it's all open to discussion and refinement, but
it's semi-official. it's just my take on things at the
moment, but it's a stake in the ground.
now, then. the (at least!) two things we need to keep in
mind are:
1. no asf package (or asf contributor acting ex officio
being an apache contributor) may deliberately
violate the terms of any licence.
2. no code nor activity is permitted that will virally
infect any of the asf's assets, or those of any user
of asf packages.
those are pretty much non-negociable; any inadvertent
violation needs to be corrected AT ONCE as soon as it
is identified. violating a licence because 'everyone
else is doing it' or 'the licence-owner has never gone
after anyone' are not on; we need to do the Right Thing,
not the cop-out or expedient one. if, for instance,
we violated one of microsoft's licence terms just
because everyone else does, the potential harm to the
asf is enormous: not only massive monetary liability,
but severe damage to our reputation for integrity.
so we must not distribute any 3p (third-party) packages
from asf systems if it is not permitted by their licences.
nor may any of our code automatically go off and fetch
such packages and start using them on the user's system
if the packages' licences require *any* sort of acknowledgement
by the user. that is, if the licence for package 'x' says
the user must stand on its head and send a paypal donation
before using 'x', none of our code may automatically download
'x' to the user's system. if it's *already* on the user's
system, we can use it -- but we can't get into any position
in which we are essentially responsible for transmitting
someone else's licence terms to the user, and assuming they've
agreed to comply with them. (i.e., for now i'm ruling
click-through licences as not permissible for our stuff
to present.)
as far as sun-bin licensed stuff on ibiblio -- it's not an
asf system, so the asf is neither liable nor responsible.
*if* some asf package requires sun-bin stuff, and silently
goes off to ibiblio to download it, though.. that's not
allowed. telling the user it needs to download the
sun-bin stuff is fine; telling it the stuff can be found
on ibiblio.. well, i *think* that's okey, but it's kinda
grey.
if someone is using an asf package that does *not*, itself,
require such stuff, but is using the asf package to build
something that does, i think we're pretty much okey there
too, since the user needs to explicitly state the dependency.
i think it's possible to consider stating the dependency
as equivalent to having the stuff already on the system --
but again it's a grey area, and i hope roy can shed some
light in this darkness. again, autofetching it by default
from a known location -- such as ibiblio or sun -- once the
dependency has been stated by the user *should* be okey.
i think.
i'm not even going to touch the infection issue at this point;
it always makes my cephalic nodule hurt horribly. let's
just say that we can't do anything that will trigger an
infection of the asf's assets -- or those of someone using
asf packages. if a licence permits *linking* against
a library, there's no prohibition on our packages requiring
the library in order to run properly. if a licence allows
us to include the library, as a general rule we can package
it with our stuff. if by linking with it or including it
in our distributions we trigger a clause in its licence that
either overrides the asf licence on our stuff, or forces
the user to comply with rules more restrictive than the
asf licence.. then we mustn't do that.
i hope this all makes sense, to some degree. please follow
up to community@apache.org.
and because recording incremental advances before a final
policy is published seems like an appropriate use, i've
set up http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
as a work area where we can distill the rules before they
get finalised and formally published on www.apache.org.
i need to stress that the wiki page is for *recording*, not
discussing. if someone wants to take a look at the current
state of things, the wiki is good method -- but hammering
out the details needs to happen on the mailing list.
long message.. thanks for your patience!
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by Santiago Gala <sg...@hisitech.com>.
Santiago Gala wrote:
(...)
> While trying to fullfill my self-infringed deed yesterday (namely
s/infringed/inflicted/ #just after pressing Send ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by Sam Ruby <ru...@intertwingly.net>.
Santiago Gala wrote:
> Sam Ruby wrote:
> (...)
>
>> Excellent.
>>
>> All I ask now is that developers in Jakarta, particularly those
>> involved in tools such as Maven that are a critical part of a number
>> of build processes and involve the automatic downloading of
>> dependencies, do a self assessment for license violations.
>>
>> Do NOT simply wait and be reactive on this.
>
> While trying to fullfill my self-infringed deed yesterday (namely
> removing mail.jar from the Jetspeed Repository without distrupting too
> much build process and distribution), I came to the fact that we also have
>
> jdbc-se2.0.jar in the cvs repo
>
> I've tryied to google my way through to the license, to no avail.
>
> Can anybody confirm if:
>
> - it is OK (I'm afraid not, though it is inside jdk1.4 )
> - where can I point people to download it (I've been trying, but Sun
> excels at making search difficult in their site) for 1.3 use.
>
> Specially the first point, since I'll eventually find it (I hope).
Not OK.
A good resource for finding such information:
http://cvs.apache.org/builds/gump/latest/packages.html
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by Santiago Gala <sg...@hisitech.com>.
Sam Ruby wrote:
(...)
> Excellent.
>
> All I ask now is that developers in Jakarta, particularly those involved
> in tools such as Maven that are a critical part of a number of build
> processes and involve the automatic downloading of dependencies, do a
> self assessment for license violations.
>
> Do NOT simply wait and be reactive on this.
>
While trying to fullfill my self-infringed deed yesterday (namely
removing mail.jar from the Jetspeed Repository without distrupting too
much build process and distribution), I came to the fact that we also have
jdbc-se2.0.jar in the cvs repo
I've tryied to google my way through to the license, to no avail.
Can anybody confirm if:
- it is OK (I'm afraid not, though it is inside jdk1.4 )
- where can I point people to download it (I've been trying, but Sun
excels at making search difficult in their site) for 1.3 use.
Specially the first point, since I'll eventually find it (I hope).
> - Sam Ruby
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
okey, i'm wading in here, noting as i do the angels high-tailing
it in the other direction.. :-)
i'm ccing community@apache because i think portions of this
discussion are important to the entire asf developer
community, and not just jakarta. (jakarta leads the way
again! <grin nature="completely non-hostile"/>)
this is my take on the things we need to keep in mind. i
may be wrong; where i'm unsure, i'm erring on the side
of conservatism. and i'm saying this stuff with my
board hat semi-on; that is, i'll be glad to be corrected
or overruled by the rest of the board, but in the absence
of such i'm breaking new ground with a tentative prototype
policy. it's all open to discussion and refinement, but
it's semi-official. it's just my take on things at the
moment, but it's a stake in the ground.
now, then. the (at least!) two things we need to keep in
mind are:
1. no asf package (or asf contributor acting ex officio
being an apache contributor) may deliberately
violate the terms of any licence.
2. no code nor activity is permitted that will virally
infect any of the asf's assets, or those of any user
of asf packages.
those are pretty much non-negociable; any inadvertent
violation needs to be corrected AT ONCE as soon as it
is identified. violating a licence because 'everyone
else is doing it' or 'the licence-owner has never gone
after anyone' are not on; we need to do the Right Thing,
not the cop-out or expedient one. if, for instance,
we violated one of microsoft's licence terms just
because everyone else does, the potential harm to the
asf is enormous: not only massive monetary liability,
but severe damage to our reputation for integrity.
so we must not distribute any 3p (third-party) packages
from asf systems if it is not permitted by their licences.
nor may any of our code automatically go off and fetch
such packages and start using them on the user's system
if the packages' licences require *any* sort of acknowledgement
by the user. that is, if the licence for package 'x' says
the user must stand on its head and send a paypal donation
before using 'x', none of our code may automatically download
'x' to the user's system. if it's *already* on the user's
system, we can use it -- but we can't get into any position
in which we are essentially responsible for transmitting
someone else's licence terms to the user, and assuming they've
agreed to comply with them. (i.e., for now i'm ruling
click-through licences as not permissible for our stuff
to present.)
as far as sun-bin licensed stuff on ibiblio -- it's not an
asf system, so the asf is neither liable nor responsible.
*if* some asf package requires sun-bin stuff, and silently
goes off to ibiblio to download it, though.. that's not
allowed. telling the user it needs to download the
sun-bin stuff is fine; telling it the stuff can be found
on ibiblio.. well, i *think* that's okey, but it's kinda
grey.
if someone is using an asf package that does *not*, itself,
require such stuff, but is using the asf package to build
something that does, i think we're pretty much okey there
too, since the user needs to explicitly state the dependency.
i think it's possible to consider stating the dependency
as equivalent to having the stuff already on the system --
but again it's a grey area, and i hope roy can shed some
light in this darkness. again, autofetching it by default
from a known location -- such as ibiblio or sun -- once the
dependency has been stated by the user *should* be okey.
i think.
i'm not even going to touch the infection issue at this point;
it always makes my cephalic nodule hurt horribly. let's
just say that we can't do anything that will trigger an
infection of the asf's assets -- or those of someone using
asf packages. if a licence permits *linking* against
a library, there's no prohibition on our packages requiring
the library in order to run properly. if a licence allows
us to include the library, as a general rule we can package
it with our stuff. if by linking with it or including it
in our distributions we trigger a clause in its licence that
either overrides the asf licence on our stuff, or forces
the user to comply with rules more restrictive than the
asf licence.. then we mustn't do that.
i hope this all makes sense, to some degree. please follow
up to community@apache.org.
and because recording incremental advances before a final
policy is published seems like an appropriate use, i've
set up http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing
as a work area where we can distill the rules before they
get finalised and formally published on www.apache.org.
i need to stress that the wiki page is for *recording*, not
discussing. if someone wants to take a look at the current
state of things, the wiki is good method -- but hammering
out the details needs to happen on the mailing list.
long message.. thanks for your patience!
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by Sam Ruby <ru...@apache.org>.
Jason van Zyl wrote:
> On Wed, 2003-02-05 at 14:45, Henri Yandell wrote:
>
>>The Sun licence stuff on there is more quesitonable. I figure as long as
>>ibiblio are aware they are liable, and that they have happily accepted
>>that liability, then it doesn't matter. Or do they pass the liability on
>>to the individual who set it up, [Jason?] ?
>
> I removed them this morning and will remove any other JARs that are
> brought to my attention. Sam named JAF, JavaMail and EJBs so I removed
> those. I just got off the phone and I got a clear answer as to what
> Apache could be liable for. If Maven, being an ASF piece of software, is
> party to illegal assembly then the ASF could be liable. This I did not
> think was the case as the JARs were not on ASF hardware but that doesn't
> seem to matter. So the Sun violations can't happen anymore. Now we just
> have to deal with LGPL and GPL issues.
Excellent.
All I ask now is that developers in Jakarta, particularly those involved
in tools such as Maven that are a critical part of a number of build
processes and involve the automatic downloading of dependencies, do a
self assessment for license violations.
Do NOT simply wait and be reactive on this.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
> I just got off the phone and I got a clear answer as to what
>Apache could be liable for. If Maven, being an ASF piece of software, is
>party to illegal assembly then the ASF could be liable.
>
>
I'd like to thank you and applaud you for being so concientious about
this. I would not have thought that the case
either.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-05 at 14:45, Henri Yandell wrote:
> The Sun licence stuff on there is more quesitonable. I figure as long as
> ibiblio are aware they are liable, and that they have happily accepted
> that liability, then it doesn't matter. Or do they pass the liability on
> to the individual who set it up, [Jason?] ?
I removed them this morning and will remove any other JARs that are
brought to my attention. Sam named JAF, JavaMail and EJBs so I removed
those. I just got off the phone and I got a clear answer as to what
Apache could be liable for. If Maven, being an ASF piece of software, is
party to illegal assembly then the ASF could be liable. This I did not
think was the case as the JARs were not on ASF hardware but that doesn't
seem to matter. So the Sun violations can't happen anymore. Now we just
have to deal with LGPL and GPL issues.
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by Henri Yandell <ba...@generationjava.com>.
On 5 Feb 2003, Jason van Zyl wrote:
> On Wed, 2003-02-05 at 14:29, Nick Chalko wrote:
>
> >
> > ------------
> >
> > I hope to have a proposal started on the Wiki tonight (PST). The Maven
> > repository
> > has been an essential tool for me for me.
> > The next step is to play nice with gump.
> > Then do help with dependencies
> > Also to make it easy for projects to "brand" themselves with version and
> > dependency information.
>
> This can be done with Maven already. We have got a grip on generational
> transition, transitive dependencies and evolution. The non-trivial part
> is the collection of the information. The tools are present and I don't
> mind splitting them out if they want to be used elsewhere.
>
> > I think Apache can grow a world class solution from the seed of the Maven
> > Repository.
> >
>
> I don't actually see why any project can't use the Maven repository
> right now.
I don't yet either.
http://www.generationjava.com/jars2/ is a maven repository.
If I put Jakarta Commons-Lang there, am I breaking the Apache licence in
some way by re-distributing Lang?
If not, then the only thing I could see being wrong about ibiblio would be
that an ASF project, Maven, uses it as its default repository. Which
doesn't seem wrong, but might have some bad aspect I don't see.
The Sun licence stuff on there is more quesitonable. I figure as long as
ibiblio are aware they are liable, and that they have happily accepted
that liability, then it doesn't matter. Or do they pass the liability on
to the individual who set it up, [Jason?] ?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
RE: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-05 at 14:29, Nick Chalko wrote:
>
> ------------
>
> I hope to have a proposal started on the Wiki tonight (PST). The Maven
> repository
> has been an essential tool for me for me.
> The next step is to play nice with gump.
> Then do help with dependencies
> Also to make it easy for projects to "brand" themselves with version and
> dependency information.
This can be done with Maven already. We have got a grip on generational
transition, transitive dependencies and evolution. The non-trivial part
is the collection of the information. The tools are present and I don't
mind splitting them out if they want to be used elsewhere.
> I think Apache can grow a world class solution from the seed of the Maven
> Repository.
>
I don't actually see why any project can't use the Maven repository
right now.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 5 Feb 2003, Nicola Ken Barozzi wrote:
>
>
> Geir Magnusson Jr. wrote, On 05/02/2003 20.35:
> >
> > On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
> >
> >>
> > JJAR in commons sandbox had some of these ideas in there... But can you
> > build this into maven rather than in parallel?
>
> We had started using JJAR in Centipede. Then one of our developers
> decided to write Ruper, that works with Maven repositories.
> Now we come to the point that we need the features that JJAR gives too,
> although we have now a clearer picture of what is needed.
>
> JJAR functionality and codebase (merging) will be part of the proposal.
>
> BTW, we are not Maven developers.
Why not work with Jason to extract the current Maven functionality for
this feature, then enhance it as a sibling/child of the overall Maven
project?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Geir Magnusson Jr. wrote, On 05/02/2003 20.35:
>
> On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
>
>>
>> I hope to have a proposal started on the Wiki tonight (PST). The Maven
>> repository
>> has been an essential tool for me for me.
>> The next step is to play nice with gump.
>> Then do help with dependencies
>> Also to make it easy for projects to "brand" themselves with version and
>> dependency information.
>>
>
> JJAR in commons sandbox had some of these ideas in there... But can you
> build this into maven rather than in parallel?
We had started using JJAR in Centipede. Then one of our developers
decided to write Ruper, that works with Maven repositories.
Now we come to the point that we need the features that JJAR gives too,
although we have now a clearer picture of what is needed.
JJAR functionality and codebase (merging) will be part of the proposal.
BTW, we are not Maven developers.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by Santiago Gala <sg...@hisitech.com>.
Costin Manolache wrote:
> Andrew C. Oliver wrote:
(...)
>>
>>wow... :-(
>
>
> I don't know what "wow" means - but it is absolutely normal for any
> community. I'm sure there are people who don't like working with me ( or
> anyone else )- and the reverse.
> I don't think anyone can reasonably expect anything else.
>
+1
> What's important is for everyone to keep having some fun and decide for
> himself if beeing in a community like jakarta ( and benefiting from the
> diversity of opinions and ideas - even from people we don't like ) is worth
> the effort of dealing with the people we don't like ( or strongly disagree
> with, or both ).
>
There is a positive aspect to this, and it starts when (project)
frontiers are established between non-working-together (but respectful)
teams. These frontiers are likely to evolve into APIs and products that
are strictly controlled for compliancy (I would say fiercly ;-) and this
is A Good Thing.
But the premise is having the parties to agree in the frontiers, i.e.
having clear concerns for subprojects, modularising the essential parts
and competing with the rest of it.
I mean, we're not as Microsoft, breaking compatibility for the sake of it.
I think such a scenario is one of the best possible ones, provided that
the heat does not make things explode.
Just my two cents,
Santiago
> As ( and if ) jakarta becomes a single community - everyone will have to
> deal with this decision.
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by Costin Manolache <cm...@yahoo.com>.
Andrew C. Oliver wrote:
>>
>>
>>Can't do it. I will never collaborate on anything with Nicola Ken
>>Barozzi. And if I have to say it in public I will. I would probably
>>participate in anything but not with him.
>>
>>
>>
> wow... :-(
I don't know what "wow" means - but it is absolutely normal for any
community. I'm sure there are people who don't like working with me ( or
anyone else )- and the reverse.
I don't think anyone can reasonably expect anything else.
What's important is for everyone to keep having some fun and decide for
himself if beeing in a community like jakarta ( and benefiting from the
diversity of opinions and ideas - even from people we don't like ) is worth
the effort of dealing with the people we don't like ( or strongly disagree
with, or both ).
As ( and if ) jakarta becomes a single community - everyone will have to
deal with this decision.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>Can't do it. I will never collaborate on anything with Nicola Ken
>Barozzi. And if I have to say it in public I will. I would probably
>participate in anything but not with him.
>
>
>
wow... :-(
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Seriously people, just forget this strand of the thread. Jason hasn't
slept and is under stress due to family issues.
Jason will probably be mad at me for posting this, but I wanted to say
something.
geir
On Wednesday, February 5, 2003, at 05:30 PM, Jason van Zyl wrote:
> On Wed, 2003-02-05 at 17:26, Jason van Zyl wrote:
>> On Wed, 2003-02-05 at 16:08, Andrew C. Oliver wrote:
>>> Jason,
>>>
>>> Can you please add your name to this as a committer and/or a
>>> sponsoring
>>> member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
>>> Also other maven folks?
>>>
>>> I value your previous experience and existing source code.
>>
>> Can't do it. I will never collaborate on anything with Nicola Ken
>> Barozzi. And if I have to say it in public I will. I would probably
>> participate in anything but not with him.
>
> Ah damn, when it rains it pours. The old man is in a coma, I haven't
> slept in days and I can't read reply-to headers. That was not meant for
> public consumption.
>
>>> -Andy
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: general-help@jakarta.apache.org
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-247-1713(m)
geirm@adeptra.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-05 at 17:26, Jason van Zyl wrote:
> On Wed, 2003-02-05 at 16:08, Andrew C. Oliver wrote:
> > Jason,
> >
> > Can you please add your name to this as a committer and/or a sponsoring
> > member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
> > Also other maven folks?
> >
> > I value your previous experience and existing source code.
>
> Can't do it. I will never collaborate on anything with Nicola Ken
> Barozzi. And if I have to say it in public I will. I would probably
> participate in anything but not with him.
Ah damn, when it rains it pours. The old man is in a coma, I haven't
slept in days and I can't read reply-to headers. That was not meant for
public consumption.
> > -Andy
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-05 at 16:08, Andrew C. Oliver wrote:
> Jason,
>
> Can you please add your name to this as a committer and/or a sponsoring
> member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
> Also other maven folks?
>
> I value your previous experience and existing source code.
Can't do it. I will never collaborate on anything with Nicola Ken
Barozzi. And if I have to say it in public I will. I would probably
participate in anything but not with him.
> -Andy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Proposal
Posted by Ted Leung <tw...@sauria.com>.
Let me second Andy's request. The proposal is much less interesting if what
is developed is not usable by Maven -- Having a new project which competes
with a piece of Maven will leave us with a bad solution for this problem
space. Also, I think it's clear that the Maven developers have thought
carefully about this problem, and I don't want to waste time reinventing the
wheel or rediscovering the hard problems.
Ted
----- Original Message -----
From: "Andrew C. Oliver" <ac...@apache.org>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Sent: Wednesday, February 05, 2003 1:08 PM
Subject: Proposal
> Jason,
>
> Can you please add your name to this as a committer and/or a sponsoring
> member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
> Also other maven folks?
>
> I value your previous experience and existing source code.
>
> -Andy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Proposal
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Jason,
Can you please add your name to this as a committer and/or a sponsoring
member: http://nagoya.apache.org/wiki/apachewiki.cgi?RuperProposal
Also other maven folks?
I value your previous experience and existing source code.
-Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary
distribution location]
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-05 at 14:50, Ted Leung wrote:
> I'd like to see this broken out of Maven / Centipede whatever, and put into
> libraries that can be used independent of the build tools.
>
> I also think that we need to plan for multiple repositories, whether they be
> ASF, ibiblio, what have you.
That's dealt with in Maven.
> There are two ideas going on in this thread. One is about the mechanism --
> the repository, version management, dependency tracing, resource retreival
> etc.
All dealt with in Maven.
> The other is about policy -- what kind of stuff can be in a particular
> repository. If the ASF ultimately decides to run its own repository with
> ASF policy that's fine. That shouldn't prevent the iBiblio repository (with
> a different policy) from continuing to exist.
Right. We can probably also assist people in knowing about violations as
well. If for example a dependency could have a license type associated
with someone trying to assemble a set of JARs could be notified of
meaning of doing so.
> I'd hate to see us build mechanism that enforced policy.
Definitely not enforce but certainly warnings. People can do what they
like. We can provide information vis-a-vis possible license violations
but ultimately individual projects are responsible for watching their
own asses.
> I'd like to lend a hand if this gets broken out into a separate project.
I can certainly strip out the dependency resolution code in Maven.
> Ted
> ----- Original Message -----
> From: "Jason van Zyl" <ja...@zenplex.com>
> To: "Jakarta General List" <ge...@jakarta.apache.org>
> Sent: Wednesday, February 05, 2003 11:40 AM
> Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary
> distribution location]
>
>
> > On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote:
> > > On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
> > > >
> > > > I hope to have a proposal started on the Wiki tonight (PST). The
> Maven
> > > > repository
> > > > has been an essential tool for me for me.
> > > > The next step is to play nice with gump.
> > > > Then do help with dependencies
> > > > Also to make it easy for projects to "brand" themselves with version
> > > > and
> > > > dependency information.
> > > >
> > >
> > > JJAR in commons sandbox had some of these ideas in there... But can
> > > you build this into maven rather than in parallel?
> >
> > The stuff in Maven can certainly be split out. As I said to Nick, it can
> > already handle generation changes, evolution and the dependency
> > mechanism in Maven already deals with non-JAR artifacts like WAR files,
> > maven POMs, docs or whatever you want.
> >
> >
> > --
> > jvz.
> >
> > Jason van Zyl
> > jason@zenplex.com
> > http://tambora.zenplex.org
> >
> > In short, man creates for himself a new religion of a rational
> > and technical order to justify his work and to be justified in it.
> >
> > -- Jacques Ellul, The Technological Society
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution
location]
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>I'd hate to see us build mechanism that enforced policy.
>
>
+1
>I'd like to lend a hand if this gets broken out into a separate project.
>
>
+1
>Ted
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
Posted by Ted Leung <tw...@sauria.com>.
I'd like to see this broken out of Maven / Centipede whatever, and put into
libraries that can be used independent of the build tools.
I also think that we need to plan for multiple repositories, whether they be
ASF, ibiblio, what have you.
There are two ideas going on in this thread. One is about the mechanism --
the repository, version management, dependency tracing, resource retreival
etc. The other is about policy -- what kind of stuff can be in a particular
repository. If the ASF ultimately decides to run its own repository with
ASF policy that's fine. That shouldn't prevent the iBiblio repository (with
a different policy) from continuing to exist.
I'd hate to see us build mechanism that enforced policy.
I'd like to lend a hand if this gets broken out into a separate project.
Ted
----- Original Message -----
From: "Jason van Zyl" <ja...@zenplex.com>
To: "Jakarta General List" <ge...@jakarta.apache.org>
Sent: Wednesday, February 05, 2003 11:40 AM
Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary
distribution location]
> On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote:
> > On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
> > >
> > > I hope to have a proposal started on the Wiki tonight (PST). The
Maven
> > > repository
> > > has been an essential tool for me for me.
> > > The next step is to play nice with gump.
> > > Then do help with dependencies
> > > Also to make it easy for projects to "brand" themselves with version
> > > and
> > > dependency information.
> > >
> >
> > JJAR in commons sandbox had some of these ideas in there... But can
> > you build this into maven rather than in parallel?
>
> The stuff in Maven can certainly be split out. As I said to Nick, it can
> already handle generation changes, evolution and the dependency
> mechanism in Maven already deals with non-JAR artifacts like WAR files,
> maven POMs, docs or whatever you want.
>
>
> --
> jvz.
>
> Jason van Zyl
> jason@zenplex.com
> http://tambora.zenplex.org
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
> -- Jacques Ellul, The Technological Society
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distri
bution location]
Posted by Jason van Zyl <ja...@zenplex.com>.
On Wed, 2003-02-05 at 14:35, Geir Magnusson Jr. wrote:
> On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
> >
> > I hope to have a proposal started on the Wiki tonight (PST). The Maven
> > repository
> > has been an essential tool for me for me.
> > The next step is to play nice with gump.
> > Then do help with dependencies
> > Also to make it easy for projects to "brand" themselves with version
> > and
> > dependency information.
> >
>
> JJAR in commons sandbox had some of these ideas in there... But can
> you build this into maven rather than in parallel?
The stuff in Maven can certainly be split out. As I said to Nick, it can
already handle generation changes, evolution and the dependency
mechanism in Maven already deals with non-JAR artifacts like WAR files,
maven POMs, docs or whatever you want.
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Clear the air Re: ATTN: Maven developers [was: primary distri bution location]
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, February 5, 2003, at 02:29 PM, Nick Chalko wrote:
>
> I hope to have a proposal started on the Wiki tonight (PST). The Maven
> repository
> has been an essential tool for me for me.
> The next step is to play nice with gump.
> Then do help with dependencies
> Also to make it easy for projects to "brand" themselves with version
> and
> dependency information.
>
JJAR in commons sandbox had some of these ideas in there... But can
you build this into maven rather than in parallel?
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-247-1713(m)
geirm@adeptra.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org