[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
:)