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
next prev 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).