Subject: Re: Anyone working on an unencumbered toolchain?
To: None <mheller@student.uni-kl.de, port-alpha@NetBSD.ORG>
From: Ross Harvey <ross@teraflop.com>
List: port-alpha
Date: 04/08/1998 09:08:04
> Hi!
> Is someone working on unencumbered toolchain for
> NetBSD/alpha? If I remember old postings long ago
> correctly, the toolchain has patches in it which
> can't be included by FSF because of unsolved 
> licensing questions.
> If nobody is working on it, I could start doing it,
> but I need to know, what exactly needs to be re-
> written and what can be used - some files lack licensing
> information . 
> Do we still need ecoff-format in our toolchain?
> an ELF-only would ?perhaps? simplify the work-to-do. 
> MARTIN
> 
> 

Thanks for your offer, any help would be appreciated. Here is my
understanding of the issue.

It's not really encumbered in the sense that there are any problems
in distributing it, it's just that the FSF requires more rights to
a single module than a commercial or BSD-license organization would,
for the obvious FSF-specific reasons. However, there are lots of
code management problems with using a divergent toolchain; we would
very much like to resolve this issue. It's only a few hundred lines
all total, and I believe the equivalent linux files almost DTRT.

The ecoff question is a good one, and the answer is: NO, it is NOT
needed any more.

As to which files, I've talked with Chris about this.  The files are
not marked, but they are the config files for netbsd, and possibly in a
few cases, for alpha. Files that have no FSF banner on them are
suspicious.

	gcc/config/alpha/netbsd.h
	gcc/config/alpha/netbsdelf.h
	configure.in stuff here and there.
	the internal ld script ("% ld --verbose")

I believe we have submitted the diffs in our toolchain...the problem is
the files that are completely new.

The right way to solve this problem is to either start over on those files
with linux files that already have FSF banners on them, or for person A
to diff those files against corresponding linux ones, and describe the
diffs to person B, who then reimplements the module by applying the
changes.

The desired end result is to fill out the assignment paperwork and get
the modules integrated in the official binutils. That is, there isn't
much point in doing the work if the end result is just the technical
side of the integration. We can't do the assignment for you, because
the author has to sign something that says he did original work.

Ross Harvey