public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Bart Veer <bartv@ecoscentric.com>
To: jifl@eCosCentric.com
Cc: ecos-maintainers@sources.redhat.com
Subject: Re: Copyright resolution
Date: Fri, 21 Mar 2003 22:28:00 -0000	[thread overview]
Message-ID: <20030321222850.E6CC5EC6F1@delenn.bartv.net> (raw)
In-Reply-To: <3E7A9442.8000607@eCosCentric.com> (message from Jonathan Larmour on Fri, 21 Mar 2003 04:25:38 +0000)

>>>>> "Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:

    Jifl> The time has come to bring this to a conclusion. The beta is
    Jifl> now out, and we want this to be resolved for 2.0 final.

    <snip>

My preference is for option (b), dropping copyright assignments
completely. I am neutral on the need for some sort of disclaimer form.
A couple of points:

  1) re. legal flaws in the license, we have a certain amount of
     protection via "(at your option) any later version." Any problem
     with the license text is likely to be with the GPL as a whole
     rather than with the exception, so would be a resolved by a GPL
     V3. This is not a panacea, it does not handle the case where the
     current license proves to be less restrictive than what we
     actually want. We may also have the possibility of adding new
     files to the system with a better license and adjust the rest of
     the system such that those new files become critical to eCos
     generally - e.g. a new HAL macro of some sort.

  2) software patents are a high risk irrespective of whether or not
     we do assignments. We may be infringing any number of existing
     software patents already, patents developed independently of
     eCos, and that may well be a larger risk than anything IP
     related.

The problem with setting up an eCos foundation is the effort involved,
both initially and long term. I believe that the time would be better
spent hacking code. We would also need to worry about the running
costs - without licenses there is no obvious revenue source other than
corporate sponsorship. I don't object strongly to setting up such a
foundation, but I don't think the gains are worth the effort involved.

The FSF route is worth exploring further, they already have all the
bureaucracy in place. I like the idea of eCos becoming the GNU
embedded OS. One possible stumbling block is the exception to the GPL,
we would have to make sure that the FSF is happy to preserve this
exception on code it would own. Another possible problem is policy
decisions, for example the recent discussion about whether vhdl output
files should be treated as data or as object files. Such issues would
have to be passed up the hierarchy and we might not like the results.

Bart

  parent reply	other threads:[~2003-03-21 22:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-21  4:27 Jonathan Larmour
2003-03-21 18:56 ` Gary Thomas
2003-03-21 20:45   ` Jonathan Larmour
2003-03-21 22:28 ` Bart Veer [this message]
2003-03-26 15:15   ` Jonathan Larmour
2003-03-28 18:07     ` Nick Garnett
2003-03-25 16:37 ` John Dallaway
2003-03-25 16:41   ` Gary Thomas

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=20030321222850.E6CC5EC6F1@delenn.bartv.net \
    --to=bartv@ecoscentric.com \
    --cc=ecos-maintainers@sources.redhat.com \
    --cc=jifl@eCosCentric.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).