geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Project Dependencies: TranQL & maybe someday
Date Wed, 06 Jul 2005 11:35:05 GMT

On Jul 5, 2005, at 9:19 PM, wrote:

> I was just thinking about the issues of external project  
> dependencies in
> general.. Should there be a process for evaluating the introduction  
> of new
> 'critical' dependencies in Geronimo.
> I think we should at least ensure that a 'critical' external  
> project meets
> a minimum criteria, for example:
> * An operational web site and documentation that describes the  
> dependency
> (more than just a paragraph).
> * Operational mailing lists and mail archives
> * Operational bug tracking system
> * More than one Geronimo committer on the project

The last one is a hard one.  It's an ideal, but for well-established,  
stable technology, I don't think we need to require this.  (I'm  
trying to find a good example, but can't at the moment)

> Currently some of the projects being discussed in this thread do  
> not meet
> the 'example' criteria above.  Just picture yourself as a new Geronimo
> developer wanting to get involved.  Go to these project websites  
> and try
> looking at the mailing list archives and see how much information  
> you can
> find about the project.
> What would be the impact to the Geronimo community if a critical  
> project
> initially met this criterial then stops meeting the 'example'  
> criteria?

This is an interesting point.  One of the side-benefits of using  
dependences under the Apache license, or one as liberal, is that in a  
dire emergency, we could copy the code and keep going with it,  
assuming the community around such code died or decided to do  
something really wacky, like re-license under the GPL, or completely  
change functionality.

> Have we identified the risks of depending on 'critical' external  
> projects.
>  I'm not saying we shouldn't rely upon them, but at least think  
> about the
> risks and how they can be minimised.  For example is it safe to  
> rely upon
> these assumptions?:
> * that the project host will always be operating
> * that the project host will backup the project source (mistakes can
> happen) and that we will always have access to the source.
> * that mailing list archives for the project kept by the hosting  
> project
> will always be available.
> * that the bug tracking records for the project will always be  
> available
> If Geronimo is integrating best of breed external components, then  
> the project infrastructure and community around those components  
> should be
> well established.

I agree 100% and want to add more.  We also want to be sure that for  
critical components

- there is a healthy, diverse community surrounding the codebase  
(which IMO is a short way of saying what you said above)
- we have reasonable belief that the code contributed to projects we  
use is free of claims of copyright infringement or knowingly  
"submarined" patents (we can never be sure about patents we  
accidentally infringe...)

For the last point, we can *never* be sure of this elsewhere, just  
like we aren't sure of it here.  However, the ASF system of legal  
documents pertaining to incoming IP via our ICLA and CCLA combined  
with our practice of using the incubator and specifically tasking  
each PMC to be vigilant and conservative about IP issues ("when in  
doubt, punt to Incubator...") means we have a demonstrated and  
visible structure in place.  This seems to provide a good basis for  
a) catching any problems before they happen and b) in the unfortunate  
event that a problem occurs, protecting the ASF, the project and the  
community as much as possible from things like claims of contributory  
infringement, etc.

I think that copyright, patent and other issues are going to continue  
to be the focal point for the larger debate about OSS and the  
software industry, and given that Geronimo's community is growing,  
and Geronimo is growing in usefulness (and thus value to users), we  
need to always remind ourselves that these issues are of tantamount  
importance to the importance of a solid, healthy community.


> John
> This e-mail message and any attachments may contain confidential,
> proprietary or non-public information.  This information is intended
> solely for the designated recipient(s).  If an addressing or  
> transmission
> error has misdirected this e-mail, please notify the sender  
> immediately
> and destroy this e-mail.  Any review, dissemination, use or  
> reliance upon
> this information by unintended recipients is prohibited.  Any opinions
> expressed in this e-mail are those of the author personally.
> Aaron Mulder <> wrote on 06/07/2005  
> 09:08:13
> AM:
>>    Changing the subject since we're drifting again.  This is related
>> to another issue that's come up off-list, but we may as well open  
>> it to
> a
>> broader discussion here.
>> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>>> TranQL is a Codehaus project so it is down to the despots, currently
> me.
>>> The barrier to entry is not high but so far I've not seen anything
>>> except that problematic patch.
>>    Okay.  Well, without getting into specifics, I'm not real
>> comfortable with Geronimo being heavily dependent on a Codehaus  
>> project
>> with precisely one, er, despot.  I feel the same about the
>> kernel, which while not currently a part of Geronimo, will likely  
>> be a
>> candidate for it (and this of course is one of the issues around it).
>>    Jeremy, would you consider either substantially enlarging the
>> community of despots for TranQL, bringing it to Apache, or merging
>> it into OpenEJB?
>>    Dain, would you consider either substantially enlarging the
>> community of despots for, bringing it to Apache, or  
>> merging it
>> into Geronimo (as a branch or sandbox module for the present, I
> presume)?
>> Thanks,
>>    Aaron

Geir Magnusson Jr                                  +1-203-665-6437

View raw message