Re: [rfa] FRV input files

[Doug Evans <dje at transmeta dot com>]

[cgen re-added to cc list, what is it with this?]

Notes:
- It appears the current plan is to move src/cgen/cpu piecemeal to src/cpu.
  Perhaps obvious, but why do it this way?
  Seems a whole lot easier to just have a flag day and do it
  en-masse.  Procedure-wise, just have Redhat change the copyright
  in src/cgen/cpu/*.cpu to what folks want first.  Then get Nick
  (or whomever needs to approve additions to src/cpu) to sign off on
  moving all the .cpu files over.  Then after that it's just
  mechanical source movement and makefile changes, which, it seems to me,
  would be preferable to do all at once rather than having a mix that
  slowly gets cleaned up.
- I'm going to assume that Redhat will assign copyright ownership over
  to the FSF.  [That's A Good Thing.]
  What the copyright terms are is a subsequent issue.

Andrew Cagney writes:
 > Red Hat has given me the authority to contribute these FRV files to the 
 > FSF.  Since src/cpu/ is part of binutils, I applied the standard 
 > binutils licence (which turned out to be the GPL).  If you feel that the 
 > FSF should in some way vary the licencing terms then can I encourage you 
 > to take that matter up with the FSF executive.

Why the FSF executive?  [ok fine if appropriate, but first things first]
[N.B. Clearly I'm not asking any change to the libopcodes, libbfd,
gas, ld, objdump/etc. copyrights.  One would hope that is taken as a given.]
However, Binutils releases already contain files that are a mixture
of copyrights.  GDB too.
There's no a-priori reason to have to make .cpu files GPL.
Obviously what's wanted is what's best for free software.
Cgen-generated files are already in binutils.
Why the sudden need to _change_ the copyright of the .cpu files?
Suppose I want to use .cpu-derived generated files to assist in building
things like gdb stubs? Maybe even be part of such stubs.
[to pick one quick example]

Anyone else on this list (namely binutils maintainers past and
present) feel that src/cpu/frv.cpu _has_ to be GPL
given that src/cgen/cpu/frv.cpu is not GPL and yet the existing
src/opcodes/frv-*.c are derived from them?
Anyone have an opinion on what the copyright of .cpu files should be?

To repeat: What's desired is what's best for free software.
Way back when, I made cgen+.cpu files have the autoconf copyright
because I wanted the generators GPL but I didn't want to preclude
non-GPL'd uses of the generated files.
I don't think we should *a-priori change* the existing copyright
of .cpu files without discussion.
If in the end the powers that be feel .cpu files should be GPL
so be it.  It's the changing of the copyright without discussion
that I question.

 > This is part of the very slow and very long term goal of cleaning up 
 > GDB's src/sim directory.

I'm curious what happens after src/cpu/frv.cpu appears.

Just dumping files in src/cpu doesn't accomplish very much.
Sure, it's a necessary step.
But without a plan for what happens next what's the point?
And I think that plan needs to be made clear to everyone
to avoid confusion and wasted effort.

fwiw, I don't think this patch should go in without
accompanying changes to opcodes/Makefile.am to use the relocated files.
Otherwise bug fixes/additions to frv.{cpu,opc} have to go into two places.