This is the mail archive of the cgen@sourceware.org mailing list for the CGEN project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: copyright issues for cgen-generated tools


Hi, Joern -

Long time no see.

On Mon, Jan 15, 2007 at 11:37:49AM +0000, Joern Rennecke wrote:
> We (ARC International) are currently evaluating the feasibility of using
> cgen to generate simulators and binutils for the ARCompact family of cores.
> The desired outcome is that the gdb sim simulator and binutils will be
> integrated into the FSF mainline tree.

OK.

> [...] However, the cgen framework and cpu files that are recommended
> as templates to writing your own cpu file (m32r is directly
> recommended, and I've also found relevant bits for features not
> covered in m32r.cpu in arc*.cpu, sh*.cpu sparc*.cpu and xstormy.cpu)
> are copyright Red Hat.

Of course you're not obligated to use these templates.  Plus a bunch of
these cpu/opc files have been donated to the FSF copyright pile; see the
src/cpu directory for those.

> I'm not sure to what extend the generated files are then copyright
> Red Hat.  [...]

They aren't really; cgen is just too naive to properly mark up its
generated code.  IMO, if it can't propagate a copyright-holder tag
from the input files into the outputs, it should not emit copyright
notices at all.

> Also, I'm not sure if the FSF requires the cgen source code to be
> assigned to them.  [...]

Apparently not, but I wasn't privy to those early discussions when the
first cgen-based binutils/gdb ports appeared.

> There are copies of some old cgen cpu files in the sourceware.org
> main tree which purport to be copyright FSF, but at the same time
> the master copies in the cgen repository don't carry any FSF
> copyright notices [...]

That does not pose a problem.  The copyright holder for the old .cpu
files (Red Hat) has signed over many of those files, and happened to
keep around some of the older versions.  There is too little
development going on to be too worried about master copy-ness or
whatnot.

I believe the gist of the situation is this.  Write your model within
the cpu/ directory.  Use cgen to generate your
binutils/simulator/whatnot into opcodes/ etc.  If the copyright
messages cgen emits are not correct ((C) FSF presumably), then edit
them before submitting the inputs and outputs.  Don't worry about the
cgen program proper.  Or something like that.

- FChE


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]