Date: Fri, 19 Mar 2004 17:52:59 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Paul Seniura <pdseniura@techie.com> Cc: freebsd-ports@freebsd.org Subject: Re: I believe lang/icc* are not open-source nor 'free', right? Message-ID: <20040319175259.2e721050@Magellan.Leidinger.net> In-Reply-To: <20040319045833.ED0D811E771@scifi.homeip.net> References: <200403122136.i2CLaCm9096276@repoman.freebsd.org> <20040318213442.D38635C35@techpc04.okladot.state.ok.us> <p0602043abc7fca5da6c6@[128.113.24.47]> <20040319015159.0B9C011E734@scifi.homeip.net> <20040319020843.GA14259@Odin.AC.HMC.Edu> <20040319045833.ED0D811E771@scifi.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 18 Mar 2004 22:58:33 -0600 (CST)
"Paul Seniura" <pdseniura@techie.com> wrote:
> Well, firstly the cvs-src@ discussion had mentioned having
> a NON-commercial FREE license granted by Intel after having
> asked them, pointedly, for the sake of the o.s. as a
No, FreeBSD got a commercial license. Normally you have to pay money for
this, but FreeBSD got it for free from Intel (a donation).
> project. And later it was an UNlimited license mentioned.
The license is not limited to a specific amount of computers or users,
as long as it is used for work @FreeBSD.org.
> It's clear now that was for distributing what icc puts out
> and only that. It's not a license so I can have and use
> icc at work in a legal way (at home here I have OSX+XCode
> on G4, and I'd say even icc has some work cut out for it ;) .
Yes, we are not allowed to distribute icc with FreeBSD.
> And someone on cvs-src@ actually said "icc is free".
As already answered by someone else: I said it's free _to obtain_ (the
non-commercial license, but this is taken out of context here).
> Right now, 'Free'BSD is created and maintained with 'free'
> and open-source tools. Using icc, it becomes a
> conglomeration of mixed licensed materials -- we cannot say
> to the world that 'Free'BSD was built in that manner.
Sorry, but you are wrong here. If you read the commit logs, you will
notice a lot of commercial tools (e.g. flexelint) where already used to
improve FreeBSD. But this has nothing to do with licenses. The source we
have in FreeBSD is mostly BSD licensed, and it will stay this way. It
does not matter if someone decides to spend some money to be able to use
a better tool to improve FreeBSD.
> Let users recompile with icc as their choice, but do not
> publish CDs or publicly available pkgs with icc, else the
> non-profit org might be liable for falsely describing
> the products.
I answered this already in the other mail. Any binary compiled with icc
(if ever) will only be available additionally to a gcc compiled binary.
> Because of these -O tests on 'dumber' Ps, I have been on
> record on this list for wanting FBSD maintainers to stop
> editting the CFLAGS from the original author's settings.
> They likely have tested it with gcc on i386, we use gcc
> on i386, so the original settings ought to stay put.
> OTOH with icc, _more_ logic might need to be added to the
> FBSD Makefiles, because the original authors probably will
> not have tested their apps with icc. Oy vey.
The goal is to incorporate changes into the original distribution, not
into our ports only (with less changes in our ports, we need less to
maintain when an update is released).
> There used to be a requirement that libs & apps had to be
> compiled similarly. There were a bunch of 'gotchyas' with
> the interplay of different compilers or even different
> levels of the same(-flavored) compiler (gcc32, gcc33) or
> even different options of the same compiler used for
> different modules that had to call each other (or something
> like that ;) .
The gcc and icc people try to track a common application binary
interface (ABI) standard (and every other C/C++ compiler vendor tries
this too). Sometimes someone finds a bug in the implementation of this
ABI, and those need to get fixed then. ATM I'm not aware of differences
in the ABI.
> After all this, the msg at the above URL totally agrees
> with me in that "we" will not be able to experience any of
> the benefits allocated to icc or other such "closed" tools.
"we" as in "you and the organization you are working for"?
> Bottom line: the net/tn3270 port I am trying to fix (I
> volunteered to be its maintainer, look at its Makefile) can
> only be tested with the tools I am allowed to use. I use
> gcc33 with p2 & dumber tweaks at work and I use Apple's
> gcc33/XCode usually with -mcpu=7450 at home. I do intend
> on making sure these two platforms (lil & big endians) can
> use this emulator, and other platforms should then be
> covered. Having to add _more_ #ifdefs on behalf of _more_
> different _compilers_ is out of my hands.
You aren't supposed to fix it for other compilers, but you are free to
do it if you are able to fix it (in case there is something broken with
other compilers).
> IMO it'd be better time spent in getting gcc up to par. ;)
> And the GNU teams ought to look at the diffs coming from
> Apple & IBM (G4/G5) and OpenDarwin on i386, and others, to
> get gcc in _really_ good shape for _all_ platforms.
> (I'm sure the GNU ppl are swamped, it'll take time.)
Compiler vendors spend a huge budget and man power on improving their
compiler on just one platform. The gcc developers already achieved a
great work with what gcc is able to do today, but a compiler which is
supposed to be good on a lot of platforms, has to jump over more hurdles
than a compiler which only has to be good on one platform.
> Keep our tools free & open, and updatable/fixable by our
> own hands, quicker, easier, better...
Being able to use icc (or any other non-free compiler) to compile
FreeBSD will not change that. But it will improve FreeBSD.
Bye,
Alexander.
--
I will be available to get hired in April 2004.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040319175259.2e721050>