public inbox for
 help / color / mirror / Atom feed
From: Jonathan Larmour <>
To: Michael Jones <>
Subject: Re: Copyright and maintainability question for new ARM Cortex A9 HAL
Date: Sat, 07 Sep 2013 03:04:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 05/09/13 04:52, Michael Jones wrote:
> The status is:
> - Project not registered yet

That's not an issue. Projects don't need to be registered.

> - Uses Freescale SDK macros
> - Uses Freescale SDK code for MMU, GIC, etc

Okay, the most important thing we need to know is the license for that
Freescale SDK. Is it Free (with a capital F) - in other words, it can be
distributed and redistributed freely by anyone in a way acceptable to the Free
Software Foundation (FSF)? That means really, is it one of the licenses here:

If it is one of those licenses, that will probably mean it's okay (unless the
GPL exception clause in the eCos license causes some conflict). Furthermore,
we can directly incorporate any files you use directly into the port, avoiding
any problems with users having to build with an SDK which lives elsewhere.

> Before I register, I want to have a strategy in place to deal with
> Freescale code. Do I replace all the Freescale code line by line until
> nothing is left,

Assuming it needs to be replaced...

Replacing it line by line is risky. Copyright is about ideas, not just who
typed it in. If you use the same, or a sufficiently similar, API or design to
theirs, it risks infringing the copyright. Not only must it not be the API, it
must not be able to be considered to have been derived from the API.

In some cases, people have gone to the extent of "clean room" implementations
to avoid this sort of thing, but I don't think that's likely to be needed. But
really what's wanted is to effectively do what you would have done if the
Freescale SDK APIs hadn't been there. For some stuff, it can't really be done
any other way *anyway*, which is fine. For example, an interrupt controller
mask macro - there's probably only one particular way to do it. Although if,
for example, you named the function, and any local variables, exactly the same
way, that might be a problem. Hopefully replacement isn't relevant though.

> or see if Freescale will assign copyright?

That would certainly be easiest, however I don't think they're going to want
to assign copyright for their whole SDK! There can only be one owner of the
code, and it would mean it was no longer Freescale. So that really won't fly.
However, I think in this case we can have confidence that Freescale are the
owners of the code, and have the rights to redistribute; that's something we
have to be more cautious about with other contributors.


eCosCentric Limited     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

  reply	other threads:[~2013-09-07  3:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05  3:52 Michael Jones
2013-09-07  3:04 ` Jonathan Larmour [this message]
2013-09-07 13:40   ` Michael Jones
2013-12-04 12:08     ` "Ilija Kocho [Илија Кочо]"

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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).