commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <bay...@generationjava.com>
Subject RE: [codec] Update dependencies.html with Java req, and more.
Date Thu, 07 Aug 2003 14:54:07 GMT


On Thu, 7 Aug 2003, Tim O'Brien wrote:

> On Wed, 6 Aug 2003, Henri Yandell wrote:
> >
> > Yeah. How to integrate either commercial tools like Clover, or GPL tools
> > like JDiff, is something that confuses me at the moment. We could have a
> > separate project.xml/project.properties or a build.xml, but I'm not sure
> > that would work easily.
>
> It is a touchy situation.  If I have the commercial binary for Clover 1.2
> licensed to Codec, where do I put it?, and  Who can I give it to?  I think
> putting the binaries on Icarus is a good solution, other committers can
> grab the binaries and use them for site generation.

I say you don't put it anywhere. Merely provide instructions on how the
committer/contributor would obtain it [and if they can]. Thus my thoughts
on it being a build-extension to the main one.

> But, who is allowed to use this binary?  We expect contributors to submit

Case by case basis.

> My point being, even though we have some very active, valuebale
> contributors, I don't think we're allowed to distribute Clover binaries to
> non-committers.

Yep. Possibly you could have a sandbox for pending code and a clover that
ran on that. But not nice. Or the person integrating the patch in would
run clover.

> I'll turn the clover report back on, but I think that we should favor free
> when there is a choice.  I'd rather not even hav to deal with the above

When the open-source product can compete, yeah.

> unit tests - but, last time I checked JCoverage didn't work very well and
> was available under one of those annoying GPL/commercial schemes (like
> MySQL).  Quilt is reportedly close to a maven plugin.  We'll see what
> happens with that.

That reportedly close built is at least a year old. I've not heard much on
it since Maven started 18 months ago.

> > > Now, here's some philosophy.  Clover is a great tool, but, it isn't free
> > > or open source.  I worry that the ASF makes a mistake when it starts to
> > > rely on proprietary utilities such as Clover and JIRA.  I'm not sure if a
> > > good discussion has been started on the subject.
> >
> > I believe in supporting commercial tools which provide open source
> > projects with a good deal. If an open source variant with competable
> > features [and a usable licence] exists, then it's the better choice.
> >
>
> I think getting into commercial tools reduces the accessibility of the
> project for non-committers.  I like Clover, but I'd like it much better if
> I knew that some college student interested in working on this project
> could download a free version.

At no point should a commercial, GPL or other non-compatible licensed
software be on the critical path for any Apache project. I see no problem
with Apache paying 50,000 dollars for some commercial application, if it
is licensed under BSD and we are then able to distribute it for free to
our users. Unlikely to happen, but not a problem :)

> A few months ago there was an email war on community@ about licensing
> issues, and, if I remember correctly, there is nothing prohibiting us from
> using GPL, LGPL "tools".

We cannot distribute them basically. So it's the same as a commercial
tool. Only use it as an aid/extension, not as a critical path. ie) No real
need for people to run clover or jdiff themselves, what they really care
about is the output of clover/jdiff, so we just need to be able to produce
that regularly.

Hen


Mime
View raw message