public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Alex Schuilenburg <alexs@ecoscentric.com>
To: sandeep <shimple0@yahoo.com>
Cc: ecos-devel@ecos.sourceware.org
Subject: Re: A naive question on issues related to code in public repository
Date: Thu, 07 Oct 2004 06:52:00 -0000	[thread overview]
Message-ID: <4164E7BE.1050903@ecoscentric.com> (raw)
In-Reply-To: <41642391.3040406@yahoo.com>

sandeep wrote:
> Alex Schuilenburg wrote:
> 
>> While it would be good to get the cradle port into the public CVS 
>> repository, as per my previous email, this is not possible unless you 
>> either wrote a new port from scratch
> 
> what does writing from scratch mean? there are hal specific isr/dsr, 
> macros/functions to be provided in hal. when you save the context of 
> thread/interrupt, initialise the thread etc. you will be be doing in 
> standard steps needed on the architecture - things you will be changing, 
> will be order of saving the registers, or using some alternate 
> instructions. in case of some architectures you might not even have this 
> flexibility.

It means throwing away the existing port, starting the port again and 
not referring to the old sources.


> even after rewrite it will turn out to be same. ecos lays out certain 
> conventions for naming macros/variables/functions/typedefs etc. so 
> things won't be changing there. you will moreorless write same things.

Yes, the functionality will be the same and indeed much of the code may 
resemble the old code.  However, the new port should still not be based 
on the old code otherwise it could be seen as a derivative and hence we 
get back to the licensing issues.


> 
> if you modify some files beyound certain extent, may be you can call 
> them as almost rewritten (like for modifications beyound certain extent, 
> I have seen mention of copyright assignment issues on the list).

No you cannot call modified code as being rewritten, even if it is 
unrecognisable. You are still basing the new code on the old code, using 
the old code as a template.  This is derived code, and as such will fall 
under the derived code's license.

You need to consider a clean room implementation, and given your 
previous exposure to the old code, you will most likely be tainted. Some 
may argue that because of this, you may not be a suitable for a rewrite.

Unfortunately a lot of this is open to interpretation so I will take the 
cowards way out and leave it to the maintainers to specify what needs to 
be done to create a new port suitable for import to anoncvs that is not 
tainted by the older code and hence license.

The best route, and maybe only route in your case, would be for Cradle 
and Red Hat to re-release the code under the version 2 license.


[...]
>> And as an FYI (since you appeared to have missed Nick's comments :-) 
>> Nick Garnett is the person who did the original port of Cradle to eCos, 
> 
> i know that even before recent thread. as I gather from earlier 
> discussions, possibly this port was not thoroughly tested (unfinished 
> work), that's what would have left certain bugs, little but at crucial 
> places.
> 
> i found nick's work quite fine (improvements here and there are possible 
> in any work over a period of time with usage), something that has got me 
> accoclades of 'being obsessed'.
> 
> can hal/doings-in-hal be looked at in isolation with rest of the eCos?

This I cannot answer and will leave to a maintainer..

-- Alex

  reply	other threads:[~2004-10-07  6:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-05 10:44 sandeep
2004-10-05 16:57 ` Andrew Lunn
2004-10-05 18:18   ` Nick Garnett
2004-10-06 13:00     ` sandeep
2004-10-06 15:42       ` Alex Schuilenburg
2004-10-06 16:44         ` sandeep
2004-10-07  6:52           ` Alex Schuilenburg [this message]
2004-10-07 10:39             ` sandeep
2004-10-11  6:35     ` sandeep
2004-10-11  8:32       ` Nick Garnett
2004-10-05 20:01   ` Alex Schuilenburg

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=4164E7BE.1050903@ecoscentric.com \
    --to=alexs@ecoscentric.com \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=shimple0@yahoo.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).