avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Is the Caldera license acceptable?


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] Is the Caldera license acceptable?
Date: Tue, 22 Oct 2002 14:01:36 -0700 (PDT)

I'm not too keen on adding new licenses. I think in the long run we're
better off only adding new code which uses the common license (as at the
end of the LICENSE file).

I hate all this licensing crap. :-\

What does OSI say about the 4-claus bsd license?

Does FreeBSD use the 4-claus?

Ted Roth

On Tue, 22 Oct 2002, E. Weddington wrote:

:) On 16 Oct 2002 at 21:31, Joerg Wunsch wrote:
:)
:) > While trying to add floating point conversions to vfprintf(), i
:) > contemplate using the V7 UNIX approach, which uses ecvt(), fcvt(), and
:) > gcvt() to convert the numbers.  For some reasons, this currently looks
:) > more promising to me than dtostre()/dtostrf() (in particular, since
:) > these functions already implement array boundary checks to not
:) > overflow the resulting string).
:) >
:) > Since old Unices are now opensource, we could use the original
:) > implementation directly.  However, the Caldera license that made
:) > these Unices opensource is basically the old 4-clause BSD-style
:) > license, i. e. it contains the clause with ``All advertising
:) > materials...'' which GNU folks seem to hate.  So the question is,
:) > would this be a problem to us (including hosting it on savannah), or
:) > could we use that code literally?
:) >
:) > The original Caldera document can be found e. g. at
:) > ftp://minnie.tuhs.org/UnixArchive/Caldera-license.pdf.  I'm
:) > appending a text translation of it for reference.
:)
:) I would be loathe to accept it. If any code had the "advertising"
:) clause on it, I would not use it on the commercial products that I'm
:) working on, or any other products for that matter.
:)
:) If it does get included, then a caveat had better be put in somewhere
:) explaining this to end-users. Doing this could prove to be a head-
:) ache.
:)
:) How hard would it be to mod the current dtostr[e|f]() to achieve the
:) desired results?
:)
:) Eric
:)
:)
:)
:)
:) _______________________________________________
:) AVR-libc-dev mailing list
:) address@hidden
:) http://mail.nongnu.org/mailman/listinfo/avr-libc-dev
:)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]