public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Edelsohn <dje.gcc@gmail.com>
To: David SAUVAGE - AdaLabs Ltd <david.sauvage@adalabs.com>
Cc: "gérard Calliet" <gerard.calliet@pia-sofer.fr>,
	"GCC Development" <gcc@gcc.gnu.org>
Subject: Re: Ada gcc compiler for ia64-hp-openvms
Date: Mon, 15 May 2017 20:01:00 -0000	[thread overview]
Message-ID: <CAGWvny=pPz5tttE29oJwQVEZhDAbgOCS=g1Wt9d-c1zcZtsRYA@mail.gmail.com> (raw)
In-Reply-To: <2da1a732-99f7-81af-ff20-81471e2bcea8@adalabs.com>

On Mon, May 15, 2017 at 12:54 PM, David SAUVAGE - AdaLabs Ltd
<david.sauvage@adalabs.com> wrote:
> On 04/29/2017 06:31 PM, David SAUVAGE - AdaLabs Ltd wrote:
>> On 04/28/2017 06:47 PM, David Edelsohn wrote:
>>> On Thu, Apr 27, 2017 at 10:55 AM, David SAUVAGE - AdaLabs Ltd
>>> <david.sauvage@adalabs.com> wrote:
>>>> Dear GCC Steering Committee,
>>>>
>>>> I am David, founder of AdaLabs Ltd, a software engineering startup
>>>> having expertise in Ada programming language technologies. As a summary,
>>>> we would like to know if gcc has interest in an assignment of copyright
>>>> to FSF from our work. We are not used to this process, and are kindly
>>>> soliciting your support on this task. Our work is about Ada compiler
>>>> support on GCC for OpenVMS.
>>>>
>>>> AdaLabs Ltd (http://adalabs.com) and PIA-SOFER SARL
>>>> (http://pia-sofer.fr) have worked hard to make Ada available again on
>>>> OpenVMs using GCC (ia64-hp-openvms). Both entities share ownership,
>>>> while AdaLabs is also the author of the work.
>>>>
>>>> Our work is based on gcc-4.7.4, and consists in building a gcc compiler
>>>> for openvms ia64 (through native, cross and canadian build, starting
>>>> from x86_64-linux-gnu to finally reach ia64-hp-openvms). The
>>>> modifications are of two flavours:
>>>> - patches to make the builds successful (in native, cross and canadian
>>>> builds)
>>>> - patches/backports to implement Ada/VMS related features, that are
>>>> present in gcc version after gcc-4.7.4 (in native, cross and canadian
>>>> builds).
>>>>
>>>> In the case you are interested in our copyright assignment proposal, we
>>>> would be pleased to continue this process.
>>>>
>>>> In the case you are not interested in our copyright assignment proposal,
>>>> we would be pleased if you could advise us on the best way to make our
>>>> work available to the GNU/FSF community, especially concerning the
>>>> licenses and copyrights management.
>>>>
>>>> I am at your disposal concerning any information you may need to take a
>>>> stand concerning this proposal.
>>> Hi, David
>>>
>>> The GCC Community always is open to considering patches to support new
>>> languages, new targets and new features.
>>>
>>> When you say that the work is based on GCC 4.7.4, does that mean that
>>> the patches are relative to GCC 4.7.4, as opposed to the current
>>> development version of GCC?
>>>
>>> GCC only accepts patches relative to the current development sources.
>>> Patches for bug fixes can be considered for backporting to an actively
>>> maintained branch, but GCC does not accept patches for completely new
>>> features to a release branch.  Also, GCC 4.7 initially was released 5
>>> years ago and no longer accepts patches.
>>>
>>> Does the offer include continued support and maintenance of Ada/VMS to
>>> ensure that it continues to function?  The GCC community requires
>>> someone to assume responsibility for the continued function of the new
>>> feature.
>>>
>>> Can you clarify some of the details of the offer?
>>>
>>> Thanks, David
>> Great thanks for your feedbacks David,
>> we will revert soon
>>
>> Regards
>>
> Dear David,
>
> our 'assignment of copyright' proposal only target a set of patches for
> GCC version 4.7.4. That is, as you clearly stated on your email above,
> not part of GCC current development sources. As a consequence, I
> understand that FSF/GCC is not in position to accept our proposal.
>
> Grateful if you could confirm my understanding, as Gérard in copy of
> this email is not used to the Libre Software world ...

Your understanding is correct.  GCC never accepts patches for a
specific version / release -- even if it is the current release.
Patches for new features or support must be contributed to the current
development version.

>
> This lead us to the last section of my initial email:
> "[...] we would be pleased if you could advise us on the best way to
> make our
> work available to the GNU/FSF community, especially concerning the
> licenses and copyrights management."
>
> Any feedbacks on the above are most welcome.
> Thanks again for your time,

Ideally, you should create a general copyright assignment to GCC -- a
"futures" assignment of all patches for GCC.  you can select which
patches to contribute.

If you insist on limiting it, you can specify files.  But that always
runs into the potential problem of files that were omitted from the
list (such as a configuration file) or changes to additional files
requested by reviewers.  Also, GCC generally likes developers to
continue to maintain contributions.

I don't know the relationship / friendliness between AdaLabs and
AdaCore.  Another possibility is that you make a private arrangement
to assign the copyright to AdaCore and they contribute the actual
patches to the GCC Project.

Thanks, David

  reply	other threads:[~2017-05-15 20:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-27 14:55 David SAUVAGE - AdaLabs Ltd
2017-04-28 14:47 ` David Edelsohn
2017-04-29 14:34   ` David SAUVAGE - AdaLabs Ltd
2017-05-15 19:54     ` David SAUVAGE - AdaLabs Ltd
2017-05-15 20:01       ` David Edelsohn [this message]
2017-05-16  7:27         ` Arnaud Charlet
2017-05-16  7:29           ` Arnaud Charlet
2017-05-16  8:17             ` Ada gcc compiler for ia64-hp-openvms <<< perhaps second, there are been mailing isuse gérard Calliet
2017-05-16  9:08         ` Ada gcc compiler for ia64-hp-openvms Florian Weimer

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='CAGWvny=pPz5tttE29oJwQVEZhDAbgOCS=g1Wt9d-c1zcZtsRYA@mail.gmail.com' \
    --to=dje.gcc@gmail.com \
    --cc=david.sauvage@adalabs.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gerard.calliet@pia-sofer.fr \
    /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).