On Fri, 13 Aug 1999 12:52:05 -0400, "Brian F. Feldman" wrote:
> Direct veto by core member (Jordan) prevents this. I really think it
> should be in libcompat, the more I consider every option.
Regardless of what Jordan says, you should do your best to put it where
most other folks put it. Other
On Fri, 13 Aug 1999, Jamie Howard wrote:
> On Fri, 13 Aug 1999, Sheldon Hearn wrote:
>
> > Close, but what I said was more along the lines that following NetBSD's
> > footsteps on issues relating to portability is _seldom_ a bad idea.
>
> I was close enough that you know the exact quote so I thi
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
> Close, but what I said was more along the lines that following NetBSD's
> footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I did alright.
Back to the point, just stick it in
On Fri, 13 Aug 1999 12:52:05 -0400, "Brian F. Feldman" wrote:
> Direct veto by core member (Jordan) prevents this. I really think it
> should be in libcompat, the more I consider every option.
Regardless of what Jordan says, you should do your best to put it where
most other folks put it. Othe
On Fri, 13 Aug 1999, Jamie Howard wrote:
> On Fri, 13 Aug 1999, Sheldon Hearn wrote:
>
> > Close, but what I said was more along the lines that following NetBSD's
> > footsteps on issues relating to portability is _seldom_ a bad idea.
>
> I was close enough that you know the exact quote so I th
On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote:
> I saw someone say that anything NetBSD did in the name of portability must
> be right (in the test thread). :)
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seldo
On Fri, 13 Aug 1999, Sheldon Hearn wrote:
> Close, but what I said was more along the lines that following NetBSD's
> footsteps on issues relating to portability is _seldom_ a bad idea.
I was close enough that you know the exact quote so I think I did alright.
Back to the point, just stick it i
On Fri, 13 Aug 1999 09:16:09 -0400, Jamie Howard wrote:
> I saw someone say that anything NetBSD did in the name of portability must
> be right (in the test thread). :)
Close, but what I said was more along the lines that following NetBSD's
footsteps on issues relating to portability is _seld
On Thu, 12 Aug 1999, Jamie Howard wrote:
> How would those functions which also exist in libc (or possibly other
> libraries, I don't know) be handled?
Just following up to myself here, NetBSD has a getopt_long() in libc
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/stdlib/
I saw
On Thu, 12 Aug 1999, Jamie Howard wrote:
> How would those functions which also exist in libc (or possibly other
> libraries, I don't know) be handled?
Just following up to myself here, NetBSD has a getopt_long() in libc
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/lib/libc/stdlib/
I saw
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
> On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
> >
> > I don't care if most of the
> > directories called "gnu" in the current tree contain GPLd code. How
>
> I had to read your message ab
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
> On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
> >
> > I don't care if most of the
> > directories called "gnu" in the current tree contain GPLd code. How
>
> I had to read your message a
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
> src/lib/libgnucompat seems to be the best suggestion so far. I wonder
> where the line between libgnucompat and libfreebsdextension is,
> though.
I've only been active here a few weeks but I've grown used to the "go
ahead and do it" I know I'm about t
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
>
> I don't care if most of the
> directories called "gnu" in the current tree contain GPLd code. How
I had to read your message about 4 or 5 times before I realized that
"Oh, the ``gnu''
On Thu, 12 Aug 1999, Tim Vanderhoek wrote:
> src/lib/libgnucompat seems to be the best suggestion so far. I wonder
> where the line between libgnucompat and libfreebsdextension is,
> though.
I've only been active here a few weeks but I've grown used to the "go
ahead and do it" I know I'm about
On Thu, Aug 12, 1999 at 02:21:11PM -0400, Brian F. Feldman wrote:
>
> I don't care if most of the
> directories called "gnu" in the current tree contain GPLd code. How
I had to read your message about 4 or 5 times before I realized that
"Oh, the ``gnu'
On Thu, 12 Aug 1999, Steve Kargl wrote:
> Brian F. Feldman wrote:
>
> If you're writing unencumbered code, placing it under
> libcompat/gnu may lead to confusion because all other
> directory paths containing gnu contain GPL'd code.
> Just stick it into libcompat.
How about libcompat/gnuish? (F
On Thu, 12 Aug 1999, Steve Kargl wrote:
> Brian F. Feldman wrote:
>
> If you're writing unencumbered code, placing it under
> libcompat/gnu may lead to confusion because all other
> directory paths containing gnu contain GPL'd code.
> Just stick it into libcompat.
How about libcompat/gnuish? (
> : There
> : is simply no reason to assume that anything under a gnu directory is GPLd,
> : or that anything GPLd is going to be under a gnu directory (which it's not.)
>
> I'm afraid there is. It has been stated many times in the past that
> all GPL'd software resides under gnu. This is true i
In message "Brian
F. Feldman" writes:
: There
: is simply no reason to assume that anything under a gnu directory is GPLd,
: or that anything GPLd is going to be under a gnu directory (which it's not.)
I'm afraid there is. It has been stated many times in the past that
all GPL'd software reside
On Thu, 12 Aug 1999, Steve Kargl wrote:
> >
> > That doesn't fit with the current organization.
> >
> > Choose:
> > a. fsf
> > b. gnu
> > c. glibc
> d. other
>
> src/lib/libcompat/{fsf,gnu,glibc} connotes GPL code.
>
> src/lib/libcompat/other allows SysV, Solaris, Linux, etc.
> : There
> : is simply no reason to assume that anything under a gnu directory is GPLd,
> : or that anything GPLd is going to be under a gnu directory (which it's not.)
>
> I'm afraid there is. It has been stated many times in the past that
> all GPL'd software resides under gnu. This is true
In message <[EMAIL PROTECTED]> "Brian F.
Feldman" writes:
: There
: is simply no reason to assume that anything under a gnu directory is GPLd,
: or that anything GPLd is going to be under a gnu directory (which it's not.)
I'm afraid there is. It has been stated many times in the past that
all G
On Thu, 12 Aug 1999, Steve Kargl wrote:
> >
> > That doesn't fit with the current organization.
> >
> > Choose:
> > a. fsf
> > b. gnu
> > c. glibc
> d. other
>
> src/lib/libcompat/{fsf,gnu,glibc} connotes GPL code.
>
> src/lib/libcompat/other allows SysV, Solaris, Linux, etc.
Brian F. Feldman wrote:
> On Thu, 12 Aug 1999, Steve Kargl wrote:
>
> >
> > If you're writing unencumbered code, placing it under
> > libcompat/gnu may lead to confusion because all other
> > directory paths containing gnu contain GPL'd code.
> > Just stick it into libcompat.
>
> That doesn't fi
On Thu, 12 Aug 1999, Warner Losh wrote:
> I hate the GPL. It has too many different interpretations. Look at
> the currentsituation with Linux: Linus says loadable drivers in Linux
> aren't covered by the GPL, while Stallman insists that they are. Its
> interpretation is open to too many variab
In message <199908121632.jaa26...@troutmask.apl.washington.edu> Steve Kargl
writes:
: If you're writing unencumbered code, placing it under
: libcompat/gnu may lead to confusion because all other
: directory paths containing gnu contain GPL'd code.
: Just stick it into libcompat.
Or libiberty :-)
On Thu, 12 Aug 1999, Steve Kargl wrote:
>
> If you're writing unencumbered code, placing it under
> libcompat/gnu may lead to confusion because all other
> directory paths containing gnu contain GPL'd code.
> Just stick it into libcompat.
That doesn't fit with the current organization.
Choose:
Brian F. Feldman wrote:
> On Wed, 11 Aug 1999, Warner Losh wrote:
>
> > In message
> > "Brian F. Feldman" writes:
> > : What do you all think about growing a gnu subdirectory in
> > src/lib/libcompat?
> > : Things like a getopt_long implementation (yes, if it will be accepted,
> > : I am volunt
Brian F. Feldman wrote:
> On Thu, 12 Aug 1999, Steve Kargl wrote:
>
> >
> > If you're writing unencumbered code, placing it under
> > libcompat/gnu may lead to confusion because all other
> > directory paths containing gnu contain GPL'd code.
> > Just stick it into libcompat.
>
> That doesn't f
On Thu, 12 Aug 1999, Warner Losh wrote:
> I hate the GPL. It has too many different interpretations. Look at
> the currentsituation with Linux: Linus says loadable drivers in Linux
> aren't covered by the GPL, while Stallman insists that they are. Its
> interpretation is open to too many varia
In message <[EMAIL PROTECTED]> Steve Kargl writes:
: If you're writing unencumbered code, placing it under
: libcompat/gnu may lead to confusion because all other
: directory paths containing gnu contain GPL'd code.
: Just stick it into libcompat.
Or libiberty :-) That way we can have a GPL-free
On Thu, 12 Aug 1999, Steve Kargl wrote:
>
> If you're writing unencumbered code, placing it under
> libcompat/gnu may lead to confusion because all other
> directory paths containing gnu contain GPL'd code.
> Just stick it into libcompat.
That doesn't fit with the current organization.
Choose
Brian F. Feldman wrote:
> On Wed, 11 Aug 1999, Warner Losh wrote:
>
> > In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> > : What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> > : Things like a getopt_long implementation (yes, if it will be accepted,
> > :
On Wed, 11 Aug 1999, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> : Things like a getopt_long implementation (yes, if it will be accepted,
> : I am volunteering to write it...) would go there, and
On Wed, 11 Aug 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> : Things like a getopt_long implementation (yes, if it will be accepted,
> : I am volunteering to write it...) w
ch...@calldei.com (Chris Costello) writes:
>I'm in favor of a libgnucompat rather than gnu functions in
> libcompat.
And how would a libgnucompat be different from libiberty? Except of
course that it would be maintained by the FreeBSD folks... Or that it
would be maintained at all. ;--)
[EMAIL PROTECTED] (Chris Costello) writes:
>I'm in favor of a libgnucompat rather than gnu functions in
> libcompat.
And how would a libgnucompat be different from libiberty? Except of
course that it would be maintained by the FreeBSD folks... Or that it
would be maintained at all. ;--)
In message "Brian
F. Feldman" writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am volunteering to write it...) would go there, and all sorts of lame
: GNU libc cruft that we can try
In message <[EMAIL PROTECTED]> "Brian F.
Feldman" writes:
: What do you all think about growing a gnu subdirectory in src/lib/libcompat?
: Things like a getopt_long implementation (yes, if it will be accepted,
: I am volunteering to write it...) would go there, and all sorts of lame
: GNU libc cr
On Wed, Aug 11, 1999, Brian F. Feldman wrote:
> What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> Things like a getopt_long implementation (yes, if it will be accepted,
> I am volunteering to write it...) would go there, and all sorts of lame
> GNU libc cruft that we ca
On 12-Aug-99 Brian F. Feldman wrote:
> What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> Things like a getopt_long implementation (yes, if it will be accepted,
> I am volunteering to write it...) would go there, and all sorts of lame
> GNU libc cruft that we can tr
On Wed, Aug 11, 1999, Brian F. Feldman wrote:
> What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> Things like a getopt_long implementation (yes, if it will be accepted,
> I am volunteering to write it...) would go there, and all sorts of lame
> GNU libc cruft that we c
On 12-Aug-99 Brian F. Feldman wrote:
> What do you all think about growing a gnu subdirectory in src/lib/libcompat?
> Things like a getopt_long implementation (yes, if it will be accepted,
> I am volunteering to write it...) would go there, and all sorts of lame
> GNU libc cruft that we can t
44 matches
Mail list logo
