> How much should be encoded in a URI, and how much in data associated with
> the URI? You seem to be trying to encode all of the data into the URI
> naming space. Why not have a single URI for the target, and then trigger
> behavior based upon the content? That would seem more extensible and l
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote on 01/03/2003 06:45:42 AM:
[snip]
> How much should be encoded in a URI, and how much in data associated
with
> the URI? You seem to be trying to encode all of the data into the URI
> naming space. Why not have a single URI for the target, and then
t
Nick Chalko <[EMAIL PROTECTED]> wrote on 01/03/2003 05:09:50 AM:
> A somewhat standard layout is the important part.
>
> If we are changing current practice I think
>
> project/[subproject]/version/(jar|zip|gz|docs|liscenses)
> is very good.
Sub project is, IMHO, way too fragile to be part of
Nick,
As long as you want to start with first principles ...
> >If we have a layout and metadata we agree on - any tool could work.
> >If it is an ant task or a perl program or we just rsync - it doesn't
> >matter.
> A somewhat standard layout is the important part.
> project/[subproject]/versi
Costin Manolache wrote:
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote:
Seeing the interest it has raised, I tend to think think it's time to
get the act together and start working on it. I'd like to propose this
for incubation ASAP, so to not loose momentum.
...
Codebases or part of codebases
On Fri, 28 Feb 2003, Nicola Ken Barozzi wrote:
> Seeing the interest it has raised, I tend to think think it's time to
> get the act together and start working on it. I'd like to propose this
> for incubation ASAP, so to not loose momentum.
> ...
>
> Codebases or part of codebases that could co
Are you arguing that the ASF should stop striving to keep licenses
compatible?
No. Where did you get that idea?
Probably entirely from my own paranoia that people would rather write
code than deliver easy to adopt software. My apologies. - ben
---
Henri Gomez wrote:
FYI, the JPackage project where I'm also involved, as set up
a Java RPM centric distribution where you could find many
(still not all) apache's java projects.
http://.jpackage.org/
Hi, Henry. I'm using them and they are awful to simplify maintenance of
linux rpm based machin
Henri Gomez wrote, On 28/02/2003 15.08:
Leo Simons wrote:
Hi all,
(sorry for the massive crosspost up front, as this is a proposal that
should in the end come from the various PMCs towards the
infrastructure team I'm doing lots of CCing, just once)
FYI, the JPackage project where I'm also involv
Leo Simons wrote:
Hi all,
(sorry for the massive crosspost up front, as this is a proposal that
should in the end come from the various PMCs towards the infrastructure
team I'm doing lots of CCing, just once)
FYI, the JPackage project where I'm also involved, as set up
a Java RPM centric distribu
Noel J. Bergman wrote:
Not sure what you mean by "lead" ( do you propose a new PMC with Dion as
chair ? ). I'm +1 on Dion - however the layout and recommendations must be
decided by the normal apache community process
I meant as in "chair", except that it wouldn't be a PMC, so I don't know if
> Not sure what you mean by "lead" ( do you propose a new PMC with Dion as
> chair ? ). I'm +1 on Dion - however the layout and recommendations must be
> decided by the normal apache community process
I meant as in "chair", except that it wouldn't be a PMC, so I don't know if
the word "chair" woul
--- Costin Manolache <[EMAIL PROTECTED]> wrote:
> On Fri, 28 Feb 2003 [EMAIL PROTECTED] wrote:
>
> >
> > > In other words - as long as maven decisions
> affect only maven - I don't
> > > care. But if it affects other projects, and the
> repository certainly does
> > > - then the PMCs of t
On Wed, 26 Feb 2003, Noel J. Bergman wrote:
> - the ASF repository shall contain ASF jars, which don't
>require oversight beyond the issuing PMC.
> - the ASF repository should contain shared third party
>jars for which the ASF has approved their use and
>distribution.
> - the ASF
On Thu, 27 Feb 2003 [EMAIL PROTECTED] wrote:
> > Few simple questions:
> >
> > Should we use 2 different dirs for src and binary distribution ? Or
> > maybe 3 dirs ( src, bin, doc ) ?
>
> Why duplicate the existing distributions? They're available, mirrored and
> well understood.
+1
I was j
On Fri, 28 Feb 2003 [EMAIL PROTECTED] wrote:
>
> > In other words - as long as maven decisions affect only maven - I don't
> > care. But if it affects other projects, and the repository certainly does
> > - then the PMCs of those projects or the apache community are the ones
> > that deci
Ben Hyde <[EMAIL PROTECTED]> wrote on 28/02/2003 01:46:43 AM:
> [EMAIL PROTECTED] wrote:
> > You know that ASF jars aren't 'freely' distributable, right? The
> > license
> > specifies some conditions on binary distribution.
>
[snip good stuff]
> Are you arguing that the ASF should stop striving
[EMAIL PROTECTED] wrote:
You know that ASF jars aren't 'freely' distributable, right? The
license
specifies some conditions on binary distribution.
All the open source sub-communities have various conventions about how
to manage the legal tangles around IPR. We, the foundation, currently
have
Costin Manolache <[EMAIL PROTECTED]> wrote on 27/02/2003 08:28:05 AM:
> On Wed, 26 Feb 2003, Noel J. Bergman wrote:
>
> > differing views on how to make use of the repository. Costin and I
seem to
> > be of the option that a significant portion of the value of the
repository
> > comes from sha
Costin Manolache <[EMAIL PROTECTED]> writes:
> Few simple questions:
>
> Should we use 2 different dirs for src and binary distribution ? Or
> maybe 3 dirs ( src, bin, doc ) ?
Why duplicate the existing distributions? They're available, mirrored and
well understood.
> Are "milestone" builds
--On Wednesday, February 26, 2003 6:15 PM +0100 Leo Simons
<[EMAIL PROTECTED]> wrote:
my take: keep everything. Again, policy should be the same as for
the contents of /dist/. I dunno if there is an asf-wide policy for
that...looking at http://www.apache.org/dist/httpd/old/, those guys
don't shar
My opinion is that the board should take this suggestion very seriously.
Original Message
Subject: RE: [proposal] daedalus jar repository (was: primary
distribution location)
Date: Wed, 26 Feb 2003 14:54:20 -0500
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
Rep
> you get an ok on [sharing and centralizing the managment
> of ASF-acceptable third party jars] from the board and/or
> the infrastructure team, and consensus across the community,
> and I'll be absolutely 100% behind any such plan.
I can't see how it would be acceptable to anyone without all of
Leo Simons wrote:
you get an ok on that from the board and/or the infrastructure team,
and consensus across the
community, and I'll be absolutely 100% behind any such plan.
scratch that, I'm in a "Just Do It" mood today. Just sent a message to
the board (who are
reading already anyway, but hey,
Noel J. Bergman wrote:
As you have seen from some of our exchange and Costin's comments, there are
differing views on how to make use of the repository. Costin and I seem to
be of the option that a significant portion of the value of the repository
comes from sharing and centralizing the managment
+1
Noel J. Bergman wrote:
Costin,
I agree with pretty much all of your particulars. To summarize, if I might:
- the ASF repository shall contain ASF jars, which don't
require oversight beyond the issuing PMC.
- the ASF repository should contain shared third party
jars for which the ASF has app
Costin,
I agree with pretty much all of your particulars. To summarize, if I might:
- the ASF repository shall contain ASF jars, which don't
require oversight beyond the issuing PMC.
- the ASF repository should contain shared third party
jars for which the ASF has approved their use and
On Wed, 2003-02-26 at 16:28, Costin Manolache wrote:
> On Wed, 26 Feb 2003, Noel J. Bergman wrote:
>
> Well, Maven doesn't seem to be that concerned with duplication, and values
> the competition :-) To paraphrase Jason - what's wrong with multiple
> competing repositories ? A smart tool should
Noel J. Bergman wrote:
If the fundamental philosophy of the ASF is Community First, how do you feel
that you contributed to that today?
Quite simple: the ASF has the honour to host mr. Van Zyl's project on
its servers. In return, they get flamed with FUD and ownership.
Bah.
--
Steven Noels
On Wed, 26 Feb 2003, Noel J. Bergman wrote:
> differing views on how to make use of the repository. Costin and I seem to
> be of the option that a significant portion of the value of the repository
> comes from sharing and centralizing the managment of ASF-acceptable third
> party jars.
Not enti
Jason van Zyl wrote:
What irks the hell out of me is people like Nicola constantly whining
about being excluded. Excluded from what?
I find this message quite interesting in this context:
http://www.mail-archive.com/general@jakarta.apache.org/msg07046.html
Expecially your signature.
--
Stefano Mazz
Jason,
> > why aren't Ant and Maven two related projects under a single PMC?
> Well, because when Ant formed they had no desire to be grouped with
> Maven
Based upon your attitude today towards Greg, Sam, Nicola (who isn't even
here, but was accused of whining), etc., I can't say that I blame th
Costin Manolache wrote:
On Wed, 26 Feb 2003, Nick Chalko wrote:
So I am for
/projectname/[subproject]/[version]/file[-version].jar
That leo suggested.
I'm not sure that's what Leo suggested.
The [] imply optional. But my main point is Centipede will adapt to
whatever Apache uses.
Havi
On Wed, 26 Feb 2003, Nick Chalko wrote:
> So I am for
> /projectname/[subproject]/[version]/file[-version].jar
>
> That leo suggested.
I'm not sure that's what Leo suggested.
Having the version in both dir and jar seems a bit too much. The common
practice in many projects ( at least in jakarta
Leo,
As you have seen from some of our exchange and Costin's comments, there are
differing views on how to make use of the repository. Costin and I seem to
be of the option that a significant portion of the value of the repository
comes from sharing and centralizing the managment of ASF-acceptabl
My proposal is that Dion Gillard be asked to chair a repository committee.
He is the most familar with the issues, he works with a lot of the Java
technologies (Tomcat, Ant, Maven, James, Jetspeed, Struts, Turbine), and
although he is a Maven fan, he is agnostic in terms of ensuring that all
build
Leo Simons wrote:
do that, but the big disadvantage with deviating from the existing
maven/centipede/ruper
practice is that it deviates from that practice, thus requiring work
and reducing compatibility. If you
feel like holding a vote, by all means feel free, I'll probably vote
-1 for deviating
Costin Manolache wrote:
What policy should we use for removing older versions ( or we just keep
everything ) ?
my take: keep everything. Again, policy should be the same as for the
contents of /dist/. I dunno
if there is an asf-wide policy for that...looking at
http://www.apache.org/dist
On Wed, 26 Feb 2003, Leo Simons wrote:
> >Should we use 2 different dirs for src and binary distribution ? Or maybe
> >3 dirs ( src, bin, doc ) ?
> >
> based on current practice at http://www.ibiblio.org/maven, the answer to
> both is "no". A quick
> glance at the java projects @ http://www.apa
Costin Manolache wrote:
On Tue, 25 Feb 2003, Leo Simons wrote:
files in /dist/java-repository besides perhaps HEADER.html and
README.htmls...
Few simple questions:
Should we use 2 different dirs for src and binary distribution ? Or maybe
3 dirs ( src, bin, doc ) ?
based on current pract
On Wed, 2003-02-26 at 10:55, Noel J. Bergman wrote:
>
> I wouldn't phrase it quite that way, but as long as the question is on the
> table: why aren't Ant and Maven two related projects under a single PMC?
Well, because when Ant formed they had no desire to be grouped with
Maven which is perfect
Conor,
I could be wrong, but I don't believe that Dion was refering to the
repository; rather he was commenting in response to my aside regarding Ant
and Maven:
On Wed, Feb 26, 2003 at 09:48:42PM +1100, [EMAIL PROTECTED] wrote:
> Noel Bergman writes:
> > I like the idea of a central repository.
[EMAIL PROTECTED] wrote:
Read the Ant missionit specifically states the Ant build system as
it's scope.
Hi Dion,
Your subject got my attention :-) Is there an Ant PMC issue here? We're
certainly open to working with other projects within Apache and beyond. Is
Ant's scope statement preventing
Noel Bergman writes:
> I like the idea of a central repository. It would simplify the issue by
> centralizing maintenance of jars and licenses. I just want to know how
it
> is going to operate. A joint operation between Ant and Maven?
> Infrastructure?
>
> [I won't even get into the question o
On Tue, 25 Feb 2003, Noel J. Bergman wrote:
> > all PMCs whose committers 'commit' to the repository should maintain
> > some oversight.
>
> Infrastructure hasn't considered that a good model for the Wiki, and I don't
> know that it would work any better for the repository. Someone needs to
> ta
On Tue, 25 Feb 2003, Leo Simons wrote:
> files in /dist/java-repository besides perhaps HEADER.html and
> README.htmls...
Few simple questions:
Should we use 2 different dirs for src and binary distribution ? Or maybe
3 dirs ( src, bin, doc ) ?
Are "milestone" builds acceptable ? Should we g
Noel J. Bergman wrote:
all PMCs whose committers 'commit' to the repository should maintain
some oversight.
Infrastructure hasn't considered that a good model for the Wiki, and I don't
know that it would work any better for the repository. Someone needs to
take responsibility for the oversigh
> all PMCs whose committers 'commit' to the repository should maintain
> some oversight.
Infrastructure hasn't considered that a good model for the Wiki, and I don't
know that it would work any better for the repository. Someone needs to
take responsibility for the oversight.
> I'm not suggestin
well, I put in place a basic readme (actually, HEADER.html) and a sample
package to
indicate what I think would be the right organisation. I've basically
copied over the
layout used by the maven repo at ibiblio and explained how that works.
This info
should be sufficient for people to start addi
Noel J. Bergman wrote:
Which PMC is going to oversee the repository?
all PMCs whose committers 'commit' to the repository should maintain
some oversight. I
don't think there's an "official" precedent wrt how this works @ apache.
It might be possible
to get the infrastructure peeps to take on the
On Mon, 24 Feb 2003, Noel J. Bergman wrote:
> > I thought this was for Apache only jars. Just a place for projects to
> > place there "Released jars" as a compliment to the zip and qz
> > distributions. So there should be no license issues.
>
> Well, I'm still waiting to hear about some of thi
Sam Ruby wrote:
- Leo (avalon pmc member acting sort-of on behalf of "the java peeps"
using the
lazy consensus model and the Just-Do-It-in-the-event-of-consensus
mindset :D)
I like that mindset. Note: the essence of lazy consensus is that such
actions are immeditely rolled back if an issue is r
> I thought this was for Apache only jars. Just a place for projects to
> place there "Released jars" as a compliment to the zip and qz
> distributions. So there should be no license issues.
Well, I'm still waiting to hear about some of this. From Dion's review, he
mentioned to me that he belie
Noel J. Bergman wrote:
Note: the essence of lazy consensus is that such actions
are immeditely rolled back if an issue is raised. I plan
to do exactly that.
I assume that you mean roll it back if an issue is raised, because obviously
you wouldn't have put it up if you had an objection. :-)
W
On Mon, 2003-02-24 at 19:13, Noel J. Bergman wrote:
> > Note: the essence of lazy consensus is that such actions
> > are immeditely rolled back if an issue is raised. I plan
> > to do exactly that.
>
> I assume that you mean roll it back if an issue is raised, because obviously
> you wouldn't hav
> Note: the essence of lazy consensus is that such actions
> are immeditely rolled back if an issue is raised. I plan
> to do exactly that.
I assume that you mean roll it back if an issue is raised, because obviously
you wouldn't have put it up if you had an objection. :-)
Which PMC is going to
On Mon, 24 Feb 2003, Leo Simons wrote:
> Leo Simons wrote:
>
> > Normally, I'd just ask the infrastructure peeps to
> >
> > umask 002
> > mkdir /www/www.apache.org/dist/java-repository
> > chown :apcvs /www/www.apache.org/dist/java-repository
> >
> > and get things started, but given the unusual (w
Leo Simons wrote:
Leo Simons wrote:
Normally, I'd just ask the infrastructure peeps to
umask 002
mkdir /www/www.apache.org/dist/java-repository
chown :apcvs /www/www.apache.org/dist/java-repository
and get things started, but given the unusual (well, maybe not ;)
amount of controversy
okay, so it
Leo Simons wrote:
Normally, I'd just ask the infrastructure peeps to
umask 002
mkdir /www/www.apache.org/dist/java-repository
chown :apcvs /www/www.apache.org/dist/java-repository
and get things started, but given the unusual (well, maybe not ;)
amount of controversy
okay, so it looks like controv
On Fri, 21 Feb 2003, Conor MacNeill wrote:
> Brian Behlendorf wrote:
> >
> > +1. I see nothing wrong with the plan. Hopefully Ant can be made smart
> > enough to pull the jars down from mirrors, too.
> >
>
> Patches always welcome, Brian :-)
The mirror CGI script should be able to handle this
Brian Behlendorf wrote:
+1. I see nothing wrong with the plan. Hopefully Ant can be made smart
enough to pull the jars down from mirrors, too.
Patches always welcome, Brian :-)
Conor
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
F
On Thu, 20 Feb 2003, Leo Simons wrote:
> Based on the above, I suggest we create such a machine-readable
> repository @
> daedalus.apache.org:/www/www.apache.org/dist/java-repository
+1. I see nothing wrong with the plan. Hopefully Ant can be made smart
enough to pull the jars down from mirrors,
Hi all,
(sorry for the massive crosspost up front, as this is a proposal that
should in the end come from the various PMCs towards the infrastructure
team I'm doing lots of CCing, just once)
I've been giving this some thought. It has been pointed out that the
primary distribution lo
On Wednesday, February 5, 2003, at 09:29 PM, Rodent of Unusual Size wrote:
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 syst
okey, i'm wading in here, noting as i do the angels high-tailing
it in the other direction.. :-)
i'm ccing [EMAIL PROTECTED] because i think portions of this
discussion are important to the entire asf developer
community, and not just jakarta. (jakarta leads the way
again! )
this is my take on
On Wed, 5 Feb 2003, Sam Ruby wrote:
> In two weeks, there is a board meeting. At that time, I would like to
> be able to report that the contents of the Maven repository conforms to
> the policies of the Apache Software Foundation.
>
> Code under the ASF License is clearly OK. As is the IBM P
[Retry with a better subject line and the proper mailing lists addreses
... sigh]
Rodent of Unusual Size wrote:
>
>>Roy T. Fielding wrote:
>>
>>>In short, the answer is no, and this applies to any software with
>>>copyright of The Apache Software Foundation.
>>
>>which brings up a very good point t
Rodent of Unusual Size wrote:
Roy T. Fielding wrote:
In short, the answer is no, and this applies to any software with
copyright of The Apache Software Foundation.
which brings up a very good point that may have been overlooked:
this applies to anything on ibiblio or elsewhere that is copyright
th
> We could link to their site and recommend downloading their jar? :)
We could. Not very convenient for users; just make-work on their part which
would be nice to avoid.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTEC
On Wed, 5 Feb 2003, Rodent of Unusual Size wrote:
> Roy T. Fielding wrote:
> >
> > In short, the answer is no, and this applies to any software with
> > copyright of The Apache Software Foundation.
>
> which brings up a very good point that may have been overlooked:
> this applies to anything on
Roy T. Fielding wrote:
>
> In short, the answer is no, and this applies to any software with
> copyright of The Apache Software Foundation.
which brings up a very good point that may have been overlooked:
this applies to anything on ibiblio or elsewhere that is copyright
the asf. it does not app
Noel J. Bergman wrote:
Not to put too fine a point on this, but just to understand. A number of
Java packages, such as JNDI and JavaMail, completely decouple the client
code from the service provider.
I realize that this is addressing a completely different point, but if
you take a look at the li
On Wed, 5 Feb 2003, Noel J. Bergman wrote:
> > > It will typically have import statements - something like:
> > > import lgpl.sshlibrary.Thingy;
>
> Thank you very much for this explanation. It should help explain to authors
> why we are asking them to provide their LGPL code under a different
On Wed, 5 Feb 2003, Noel J. Bergman wrote:
> Thank you very much for this explanation. It should help explain to authors
> why we are asking them to provide their LGPL code under a different open
> source license.
Bear in mind that although, i.e the ASF, may be allowed to do so and
distribute
The import statement alone is sufficient to make the source code a
work based on the Library, which means we could distribute under the
terms of section 6. Those terms are viral and disallow binary-only
releases, making our product viral because the Apache license does
not require redistribution o
Roy T. Fielding wrote:
Can I explore the issue a little bit further? The question that
usually arises on Ant is not the storing and distribution of LGPL code
itself, but the storing of code that "links" with or depends on the
LGPL code. As an example, let's say we want to provide an SSH task for
> > It will typically have import statements - something like:
> > import lgpl.sshlibrary.Thingy;
> The import statement alone is sufficient to make the source code a
> work based on the Library, which means we could distribute under the
> terms of section 6. Those terms are viral and disallow bi
On Wed, 5 Feb 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> You do win.. You don't have to have the direct implementation in
> apache cvs and ask if the eg gpl'ed software would include an
> implementation of that in their distro's.
OK, the interface is there, Ant's Task class. I'm just
Bodewig [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 05, 2003 09:35
> To: community@apache.org
> Subject: Re: primary distribution location
>
>
> On Wed, 5 Feb 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
>
> > There is a way around all this if you writ
Roy T. Fielding wrote:
The import statement alone is sufficient to make the source code a
work based on the Library, which means we could distribute under the
terms of section 6. Those terms are viral and disallow binary-only
releases, making our product viral because the Apache license does
not r
On Wed, 5 Feb 2003, Martin van den Bemt <[EMAIL PROTECTED]> wrote:
> There is a way around all this if you write an interface that is
> used to be generic, and have the interface implementation stored
> elsewhere.
But "the interface implementation" would have to be LGPLed again, so
you don't real
round
some problems.
Mvgr,
Martin
> -Original Message-
> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 05, 2003 01:01
> To: community@apache.org
> Subject: Re: primary distribution location
>
>
> Rodent of Unusual Size wrote:
> >
Can I explore the issue a little bit further? The question that
usually arises on Ant is not the storing and distribution of LGPL code
itself, but the storing of code that "links" with or depends on the
LGPL code. As an example, let's say we want to provide an SSH task for
Ant (a recent questio
Henri Yandell wrote:
How about side-stepping the issue entirely and organising some kind of
collation of projects on sourceforge/ibiblio, or even if lgpl is the main
problem, setting up a project at savannah to host all the lgpl plugins to
asf licenced works?
... which was one of the suggestions at
On Wed, 5 Feb 2003, Conor MacNeill wrote:
> Noel J. Bergman wrote:
> > Conor,
> >
> > I expect that people are worried about the viral implications of LGPL,
I'm worried about it :) If it's LGPL, I can use it at work, but I can't
release any code that imports from the LGPL'd jar.
And with RMS'
Noel J. Bergman wrote:
Conor,
I expect that people are worried about the viral implications of LGPL,
although I am not sure how that applies with a jar. One of the long
standing issues with the FSF licenses is how to apply them in a Java
environment.
Totally agree. I'm OK if the answer is "No, you
Conor,
I expect that people are worried about the viral implications of LGPL,
although I am not sure how that applies with a jar. One of the long
standing issues with the FSF licenses is how to apply them in a Java
environment.
We're trying to get alternate licensing from any LGPL code. So far
Rodent of Unusual Size wrote:
in fact, until such time as a clear determination
is made, i'm ruling that it is *not* allowed. it is not worth the
risk. so lgpl-licensed materials in the asf repositories are
forbidden until a final decision is made.
that may seem heavy-handed and arbitrary; i ap
On Tue, 4 Feb 2003, Andrew C. Oliver wrote:
> >
> >
> > in fact, until such time as a clear determination
> >is made, i'm ruling that it is *not* allowed. it is not worth the
> >risk. so lgpl-licensed materials in the asf repositories are
> >forbidden until a final decision is made.
That's fin
in fact, until such time as a clear determination
is made, i'm ruling that it is *not* allowed. it is not worth the
risk. so lgpl-licensed materials in the asf repositories are
forbidden until a final decision is made.
that may seem heavy-handed and arbitrary; i apologise ahead of
time, partic
Costin Manolache wrote:
>>
>> Where is this policy defined? I'd really like a definitive statement about
>> this from someone with the authority to make such a pronouncement :-)
>
> Good luck...
>
> Since I doubt this will happen - I'm inclined to just start using LGPL and
> force someone to m
91 matches
Mail list logo
