public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: Joern Rennecke <joernr@arc.com>
Cc: cgen@sources.redhat.com
Subject: Re: copyright issues for cgen-generated tools
Date: Mon, 15 Jan 2007 19:39:00 -0000	[thread overview]
Message-ID: <20070115193844.GA22188@redhat.com> (raw)
In-Reply-To: <20070115113749.GA27642@elsdt-razorfish.arc.com>

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

  reply	other threads:[~2007-01-15 19:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-15 11:38 Joern Rennecke
2007-01-15 19:39 ` Frank Ch. Eigler [this message]
2007-01-16 13:31   ` Joern Rennecke
2007-01-16 15:01     ` Dave Brolley
2007-01-16 19:29     ` Frank Ch. Eigler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070115193844.GA22188@redhat.com \
    --to=fche@redhat.com \
    --cc=cgen@sources.redhat.com \
    --cc=joernr@arc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).