[rfa] FRV input files

[rfa] FRV input files

[Doug Evans]

Andrew Cagney writes:
 > Please note that I didn't write this (but I also work for Red Hat :-).
 > 
 > Andrew
 > 2003-05-02  Andrew Cagney  <cagney@redhat.com>
 > 
 > 	* frv.cpu: New file.  Written by Dave Brolley, Catherine Moore,
 > 	and Eric Christopher.  All of Red Hat.
 > 	* frv.opc: New file.  Written by Catherine Moore, and Dave
 > 	Brolley.  All of Red Hat.
 > 	* simplify.inc: New file.  Written by Doug Evans.  All of Red Hat.

I'm confused.

Given that src/cgen/frv.cpu already exists,
I'm guessing the intent here is to move these files to src/cpu
(given the recent activity there).

Why don't we move all the .cpu files over en masse?
Or is there something else going on here?

[rfa] FRV input files

[Doug Evans]

Doug Evans writes:
 > Given that src/cgen/frv.cpu already exists,

Obvious typo: s,cgen,cgen/cpu,

Re: [rfa] FRV input files

[Doug Evans]

[note: I added cgen@sources.redhat.com back to the cc list.]

Andrew Cagney writes:
 > Doug, see
 > http://sources.redhat.com/ml/binutils/2002-09/msg00689.html

Righto (and my thanks to the powers that be for letting it be src/cpu!),
but I don't see how this clears up my confusion.
Why did you submit a patch for frv.cpu,et.al. to binutils?
[I'm not suggesting you shouldn't have.  I'm just asking why.]
frv.cpu already exists in src/cgen/cpu (as do other files of course).
What needs to happen is for most/all of the files in src/cgen/cpu to move
to src/cpu. [No?]

There's also the issue of copyright.
One might take it as a given, but for my own education:
When the files in src/cgen/cpu/* get moved to src/cpu will
Redhat assign copyright over to the FSF?
I see that src/cgen/cpu/frv.cpu has copyright Redhat
and the patch you've submitted to binutils has copyright FSF.
I think it's not strictly necessary, but I'd still like to
know where people stand on the issue.  Is that Redhat's plan of record?
[i.e. assign copyright of *.cpu,*.opc,simplify.inc over to the FSF]
What about cgen itself?

There's also the issue of the kind of copyright attached to these files
(which I think needs to be unambiguous).
Cgen files use the cgen copyright (aka autoconf copyright).
Yet the copyright notice at the top of the frv.cpu file you've
submitted is pure GPL.  Which is it?

I'd also like to repeat my earlier question which didn't get answered.
Is the plan to move src/cgen/cpu/* to src/cpu
in a piecemeal fashion or all at once?

And for completeness' sake I guess:
If en-masse, has anyone taken on the task of doing the en-masse move?
[and what's the schedule?]
I'm certainly willing to take on the task of doing the physical move,
but obviously I have no say in copyright issues (other than expressing
an opinion).

Re: [rfa] FRV input files

[Doug Evans]

[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.

Re: [rfa] FRV input files

[Frank Ch. Eigler]

cagney wrote:

> Red Hat has given me the authority to contribute these FRV files to
> the FSF.

Did you receive instructions to change the license too?

> Since src/cpu/ is part of binutils, I applied the standard binutils
> licence (which turned out to be the GPL).

That's not necessarily appropriate.  The original licenses were fine,
and more useful for some purposes, like dje outlined.

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

Please publish your plans, so one can tell what possible relationship
this has to that.

(And BTW, until cgen is taught to scan src/cpu in addition to
src/cgen/cpu for input models, this rearrangement will make dual
maintenance necessary on the unused new and the used old variants of
these files.)


- FChE

Re: [rfa] FRV input files

[Andrew Cagney]

>> This is part of the very slow and very long term goal of cleaning up
>> GDB's src/sim directory.
> 
> 
> Please publish your plans, so one can tell what possible relationship
> this has to that.

Plan?  Get stuff contributed to the FSF.

Andrew

Re: [rfa] FRV input files

[Frank Ch. Eigler]

cagney wrote:

> >> This is part of the very slow and very long term goal of cleaning up
> >> GDB's src/sim directory.
>
> > Please publish your plans, so one can tell what possible relationship
> > this has to that.
> 
> Plan?  Get stuff contributed to the FSF.

Which part of sim/foo (for any cgen-generated foo) is not already
(C)FSF?  And what does this have to do with your improvised license
change?


- FChE

Re: [rfa] FRV input files

[Andrew Cagney]

> cagney wrote:
> 
> 
>> >> This is part of the very slow and very long term goal of cleaning up
>> >> GDB's src/sim directory.
> 
>>
> 
>> > Please publish your plans, so one can tell what possible relationship
>> > this has to that.
> 
>> 
>> Plan?  Get stuff contributed to the FSF.
> 
> 
> Which part of sim/foo (for any cgen-generated foo) is not already

The input?

> (C)FSF?  And what does this have to do with your improvised license
> change?

What "improvised license change"?

Andrew

Re: [rfa] FRV input files

[Doug Evans]

Andrew Cagney writes:
 > > (C)FSF?  And what does this have to do with your improvised license
 > > change?
 > 
 > What "improvised license change"?

Uh, do a diff between your submitted frv.cpu and src/cgen/cpu/frv.cpu.
["I did, and src/cgen/cpu/frv.cpu is copyright Redhat!"
"Uh, I'm refering to the copyright terms."]

Also, I'm not sure I want *.cpu to say it's part of Binutils.
I might very well want to make a cgen release all by itself,
and I'd like to maintain the separation between cgen and its
clients.  Binutils is just another client of cgen.
A minor point, but early warning that I'll probably make the change
at some point.
["But cgen isn't copyright FSF."
"Doesn't mean some version can't be."]


1,4c1,21
< ; Fujitsu FRV CPU description.  -*- Scheme -*-
< ; Copyright (C) 2000, 2001 Red Hat, Inc.
< ; This file is part of CGEN.
< ; See file COPYING.CGEN for details.
---
> ; Fujitsu FRV opcode support, for GNU Binutils.  -*- Scheme -*-
> ;
> ; Copyright 2003 Free Software Foundation, Inc.
> ;
> ; Contributed by Red Hat Inc; developed under contract from Fujitsu.
> ;
> ; This file is part of the GNU Binutils.
> ;
> ; This program is free software; you can redistribute it and/or modify
> ; it under the terms of the GNU General Public License as published by
> ; the Free Software Foundation; either version 2 of the License, or
> ; (at your option) any later version.
> ;
> ; This program is distributed in the hope that it will be useful,
> ; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> ; GNU General Public License for more details.
> ;
> ; You should have received a copy of the GNU General Public License
> ; along with this program; if not, write to the Free Software
> ; Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Re: [rfa] FRV input files

[Andrew Cagney]

> Andrew Cagney writes:
>  > > (C)FSF?  And what does this have to do with your improvised license
>  > > change?
>  > 
>  > What "improvised license change"?
> 
> Uh, do a diff between your submitted frv.cpu and src/cgen/cpu/frv.cpu.
> ["I did, and src/cgen/cpu/frv.cpu is copyright Redhat!"
> "Uh, I'm refering to the copyright terms."]

(licence terms?)

Having the FSF distribute this code under anything other than the 
standard GPL would be an "improvised license change".

I [wearing a Red Hat] can't dictate the licencing terms under which the 
FSF distributes these FSF (C) files.

> Also, I'm not sure I want *.cpu to say it's part of Binutils.

A file identified as being part of "binutils", is covered by an FSF 
"binutils" assignment.  This makes everyones life a lot easier.

Andrew

Re: [rfa] FRV input files

[Doug Evans]

Andrew Cagney writes:
 > Having the FSF distribute this code under anything other than the 
 > standard GPL would be an "improvised license change".

Ah, so if I wanted to add, say, a regexp package to Binutils releases
and use it in libopcodes, I'd have to make it GPL right?
[no answers from the peanut gallery please, I want to hear Andrew's opinion]

 > I [wearing a Red Hat] can't dictate the licencing terms under which the 
 > FSF distributes these FSF (C) files.

Strawman.  Who said anything about dictating.

 > > Also, I'm not sure I want *.cpu to say it's part of Binutils.
 > 
 > A file identified as being part of "binutils", is covered by an FSF 
 > "binutils" assignment.  This makes everyones life a lot easier.

Easier for who and why?

Re: [rfa] FRV input files

[Andrew Cagney]

> Andrew Cagney writes:
>  > Having the FSF distribute this code under anything other than the 
>  > standard GPL would be an "improvised license change".

This statement is in reference to new (C) FSF code, that is part of 
binutils.

Andrew

Re: [rfa] FRV input files

[Andrew Cagney]

>  > > Also, I'm not sure I want *.cpu to say it's part of Binutils.
>  > 
>  > A file identified as being part of "binutils", is covered by an FSF 
>  > "binutils" assignment.  This makes everyones life a lot easier.
> 
> Easier for who and why?

Anyone wanting to contribute changes to the FSF.  It falls under the 
existing FSF "binutils" assignment.

Andrew