public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@eCosCentric.com>
To: "Frank Ch. Eigler" <fche@toohappy.toronto.redhat.com>
Cc: Bart Veer <bartv@eCosCentric.com>, ecos-maintainers@sources.redhat.com
Subject: Re: Future code ownership
Date: Thu, 02 Jan 2003 14:55:00 -0000	[thread overview]
Message-ID: <3E1452C7.1030907@eCosCentric.com> (raw)
In-Reply-To: <200212231553.gBNFrPG09385@toohappy.toronto.redhat.com>

Frank Ch. Eigler wrote:
> bartv wrote:
> 
> 
>>[...]                 if we are going to bother with copyright
>>assignments at all then we might as well do it properly. 
> 
> 
> I'm still being misunderstood.  My point is that you might find a way
> to go *without* formal copyright assignments to a central organization,
> and still be relatively safe from corporate copyrights.

"relatively"? It's the "relatively" that's the problem. I agree that 99% 
of the time there's no problem. It's the magnitude of the problems that 
the 1% cause that give us reason to hesitate.

>>The FSF has
>>defined certain procedures which it considers necessary, and it has
>>some very good legal advisors. 
> 
> 
> Yes, whatever they have makes sense to them for their assignment-based
> scheme, and there has been little "competition" to discourage excessive
> barriers to contribution.

But it's their legal advisors that say it's not excessive to use an 
assignment-based scheme! It's the only way to be legally sure about ownership.

Remember it's not just ass covering for the project as a whole. *We* can 
revert a patch if need be. It's ass covering for *all* users out there, 
because if they download something that shouldn't have had some bits 
included, they could be up shit creek. We have a responsibility to protect 
them. *Our* life would be easy because there is indeed little more we can 
do than put out an announcement to tell people they shouldn't use such and 
such versions of eCos, and CVS between such and such dates.

But it could create dire problems for people out there who just don't find 
out, and maybe ship a hardware product running eCos, and due to the GPL it 
will be easy to find out if it contained a "bad" patch, after which the 
copyright owner could see it and sue.

It would be easier if eCos was only shipped by itself as software, like 
GCC, GDB, SourceNav, SID etc. Recalling hardware on the other hand...

And the whole fact that this _can_ arise will scare off many companies. 
They just won't take the risk, and we've lost potential eCos users. I've 
definitely heard that said about the Linux kernel. Our commercial 
competitors could certainly use it as FUD ammunition.

Maybe despite all this we should drop the assignment requirements anyway. 
But I want to make sure everyone has their eyes opened to what it could mean.

Jifl - with a nasty cold so apologies if anything above is gibberish
-- 
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

  reply	other threads:[~2003-01-02 14:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-19 11:52 Frank Ch. Eigler
2002-12-19 14:39 ` Bart Veer
2002-12-20 14:21   ` Frank Ch. Eigler
2002-12-22 15:21     ` Bart Veer
2002-12-23  7:53       ` Frank Ch. Eigler
2003-01-02 14:55         ` Jonathan Larmour [this message]
2003-01-12  2:42           ` Jonathan Larmour
2003-01-22  2:22             ` Jonathan Larmour
     [not found] <3E145A86.5050601@eCosCentric.com>
2003-01-02 16:21 ` Frank Ch. Eigler
  -- strict thread matches above, loose matches on Subject: below --
2002-12-16  7:52 Jonathan Larmour
2002-12-17  0:44 ` Andrew Lunn
2002-12-17 19:57   ` Jonathan Larmour
2002-12-17  1:09 ` Andrew Lunn
2002-12-17 15:24   ` Bart Veer
2002-12-18  0:40     ` Andrew Lunn
2002-12-19  5:09     ` Jonathan Larmour
2002-12-17 19:54   ` Jonathan Larmour
2002-12-17 20:00     ` Gary Thomas
2002-12-17  1:27 ` Andrew Lunn
2002-12-17  5:47   ` Gary Thomas
2002-12-17  9:16     ` Andrew Lunn
2002-12-17  8:52       ` Gary Thomas
2002-12-17 12:29     ` Jonathan Larmour
2002-12-17  8:29 ` Andrew Lunn
2002-12-17 12:23   ` Jonathan Larmour
2002-12-17  8:38 ` Andrew Lunn
2002-12-17 12:18   ` Jonathan Larmour
2002-12-17  8:42 ` Andrew Lunn
2002-12-17  8:56   ` Gary Thomas
2002-12-17 12:00     ` Jonathan Larmour

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=3E1452C7.1030907@eCosCentric.com \
    --to=jifl@ecoscentric.com \
    --cc=bartv@eCosCentric.com \
    --cc=ecos-maintainers@sources.redhat.com \
    --cc=fche@toohappy.toronto.redhat.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).