RE: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
-Original Message- From: Andrew C. Oliver [mailto:[EMAIL PROTECTED]] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distri bution location]
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) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
JJAR has stalled. but maybe restarting that is a good solution. I think building outside of maven is a worthwhile because not every one uses maven. I would like to see the tools and standards developed be independent of the build tool. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:36 AM To: Jakarta General List Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary distri bution location] 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) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
On Wed, 2003-02-05 at 14:38, Nick Chalko wrote: JJAR has stalled. but maybe restarting that is a good solution. It's not a good idea. Again, it was started at my behest and I've absorbed everything in JJAR into Maven's mechanism. Which can be split out. I think building outside of maven is a worthwhile because not every one uses maven. I would like to see the tools and standards developed be independent of the build tool. It can be a separate tiny build and then anyone can use it. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:36 AM To: Jakarta General List Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary distri bution location] JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? -- jvz. Jason van Zyl [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
On Wed, 5 Feb 2003, Nick Chalko wrote: JJAR has stalled. but maybe restarting that is a good solution. I think building outside of maven is a worthwhile because not every one uses maven. I would like to see the tools and standards developed be independent of the build tool. This doesn't compute. You think _build_ing outside of maven is worthwhile, because you want things to be independent of the _build_ tool. Are these different uses of the same word? If Maven is the build tool, surely you build inside it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air
On Wednesday, February 5, 2003, at 02:38 PM, Nick Chalko wrote: JJAR has stalled. but maybe restarting that is a good solution. I just wanted to suggest that you might get something out of what was there, not that it should be restarted. I think building outside of maven is a worthwhile because not every one uses maven. Would more people use maven if you 'scratched your itch'? (I really hate that cliche', but it does apply :) I would like to see the tools and standards developed be independent of the build tool. -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:36 AM To: Jakarta General List Subject: Re: Clear the air Re: ATTN: Maven developers [was: primary distri bution location] 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) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
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 [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:42 AM To: Jakarta General List Subject: RE: Clear the air On Wed, 5 Feb 2003, Nick Chalko wrote: JJAR has stalled. but maybe restarting that is a good solution. I think building outside of maven is a worthwhile because not every one uses maven. I would like to see the tools and standards developed be independent of the build tool. This doesn't compute. You think _build_ing outside of maven is worthwhile, because you want things to be independent of the _build_ tool. Are these different uses of the same word? If Maven is the build tool, surely you build inside it. Bad wording. I don't use maven to do my builds. I use a different tool(centipede or ant). I am proposing an Project to handle dependencies, versioning, and downloads. The new project being separate from both Maven and Centipede but useable by both (or other advanced build tools) is a worth while goal. R, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
On Wed, 5 Feb 2003, Nick Chalko wrote: I don't use maven to do my builds. I use a different tool(centipede or ant). I am proposing an Project to handle dependencies, versioning, and downloads. The new project being separate from both Maven and Centipede but useable by both (or other advanced build tools) is a worth while goal. *nod*. +1 on using what Maven currently has, merged with anything Ruper has learnt about being outside of Maven and tested by both the Maven and Centipede communities. -1 to JJAR as it's just never made it into reality. Why use a dead-component, or aspects of it, when there are two versions of a live component in place. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
-Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:57 AM To: Jakarta General List Subject: RE: Clear the air On Wed, 5 Feb 2003, Nick Chalko wrote: I don't use maven to do my builds. I use a different tool(centipede or ant). I am proposing an Project to handle dependencies, versioning, and downloads. The new project being separate from both Maven and Centipede but useable by both (or other advanced build tools) is a worth while goal. *nod*. +1 on using what Maven currently has, merged with anything Ruper has learnt about being outside of Maven and tested by both the Maven and Centipede communities. -1 to JJAR as it's just never made it into reality. Why use a dead-component, or aspects of it, when there are two versions of a live component in place. --- Well said. I hope the wiki proposal page will be ready tonight (PST) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air
On Wednesday, February 5, 2003, at 03:01 PM, Nick Chalko wrote: *nod*. +1 on using what Maven currently has, merged with anything Ruper has learnt about being outside of Maven and tested by both the Maven and Centipede communities. -1 to JJAR as it's just never made it into reality. Why use a dead-component, or aspects of it, when there are two versions of a live component in place. sigh Read what I said... -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air
On Wed, 5 Feb 2003, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 03:01 PM, Nick Chalko wrote: *nod*. +1 on using what Maven currently has, merged with anything Ruper has learnt about being outside of Maven and tested by both the Maven and Centipede communities. -1 to JJAR as it's just never made it into reality. Why use a dead-component, or aspects of it, when there are two versions of a live component in place. sigh Read what I said... Sorry. I replied to the reply to the reply and not your initial bit *whistle hopefully* Geir said: JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? Apologies, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air
On Wednesday, February 5, 2003, at 03:06 PM, Henri Yandell wrote: On Wed, 5 Feb 2003, Geir Magnusson Jr. wrote: On Wednesday, February 5, 2003, at 03:01 PM, Nick Chalko wrote: *nod*. +1 on using what Maven currently has, merged with anything Ruper has learnt about being outside of Maven and tested by both the Maven and Centipede communities. -1 to JJAR as it's just never made it into reality. Why use a dead-component, or aspects of it, when there are two versions of a live component in place. sigh Read what I said... Sorry. I replied to the reply to the reply and not your initial bit *whistle hopefully* :) This is getting silly. All I was saying was that my note about JJAR should not be interpreted as a push to get it going. If I thought that, I'd rekindle it... Geir said: JJAR in commons sandbox had some of these ideas in there... But can you build this into maven rather than in parallel? Apologies, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-956-2604(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primarydistribution location]
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 [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clear the air
-Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 05, 2003 11:48 AM To: Jakarta General List Subject: Re: Clear the air I think building outside of maven is a worthwhile because not every one uses maven. Would more people use maven if you 'scratched your itch'? (I really hate that cliche', but it does apply :) Valid point. I did use maven this summer and then decided not to, for reasons that are not relevant to this discussion. My point is not everyone will use maven, but the repository and the tools to support it have value beyond maven. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distributionlocation]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distributionlocation]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clear the air Re: ATTN: Maven developers [was: primary distributionlocation]
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 [EMAIL PROTECTED] 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! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author,
Re: Clear the air Re: ATTN: Maven developers [was: primary distribution location]
+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 [EMAIL PROTECTED] 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
