public inbox for
 help / color / mirror / Atom feed
From: Jonathan Larmour <>
To: Linda Wang <>
Subject: Re: eCos license questions
Date: Thu, 28 Jul 2005 12:06:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Linda Wang wrote:
> Dear eCos Maintainers,
> We're researching the possibility of using eCos in one of
> our products, but we have some questions regarding the
> license.
> Th eCos License Overview says that "the license does not
> require users to release the source code of any
> applications that are developed with eCos."  What exactly
> defines an eCos application?  Does it include drivers?
>  Does it include any code statically linked into eCos?

The effect is to neuter the so-called "viral" nature of the GPL. So it 
does not include drivers or any other code linked to eCos. *Unless* that 
is, those drivers are in any way derived from existing eCos code, as 
clarified further below.

So if you write completely new code, whatever the nature of that code, it 
is not affected by the eCos license just because it is linked with eCos.

> The overview then goes on to say "if anybody makes changes
> to code covered by the eCos license, or writes new files
> derived in any way from the eCos code," then the source
> code should be made public.  What does it mean to derive
> code from eCos?  Does deriving code include using eCos
> library functions and headers?

It means using the _contents_ of existing eCos source code files, either 
in whole or in part. So if you copy an eCos source file and make some 
changes to it, the file in its entirety (included your additions and 
changes) is still covered by the eCos license. The same principle applies 
to a file written by yourself, and you copy even just a few lines from an 
eCos source file. That entire file is then covered by the eCos license, 
even though only a very small part of it came from eCos.

Deriving code does not include just using library functions/headers, as 
you have not copied them into your source code files. If you copied the 
*contents* of those files into your source code files, that would be a 
different matter.

That covers most of the situations you are likely to be concerned about. 
There are some more esoteric edge cases where people try to step around 
the GPL or eCos license requirements by using various tricks and assuming 
that it is the literal meaning of "derived" that matters, but copyright 
law is a little more flexible when it comes to a "derived work" and does 
account for things like that. In other words, if you think you've got a 
sneaky way to subvert the license, don't bother :-).

Of course a copyright lawyer will be able to give you a proper authorative 
opinion of whether something constitutes a derived work, and I'm not one. 
I am giving you my understanding of the licence (despite being a 
co-author!), not legal advice.

> In the overview's Q&A section, it says "you would not need
> to make available... the code of a wholly separate
> application."  What does "wholly separate" mean?  Does it
> remain wholly separate if the application is statically
> linked into the eCos kernel?  Does it remain separate if it
> calls eCos library functions?

It does remain separate. The application source files are distinct from 
the eCos ones, and only interact with eCos using the various APIs, not by 
copied code.

> Sorry if my questions are somewhat nit-picky.  Since we
> make security products, our products must be certified by
> various government agencies that require that we clearly
> define our legal obligations.

That's absolutely sensible. Let me know if you have any more questions.

eCosCentric    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

      reply	other threads:[~2005-07-28 12:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-25 20:52 Linda Wang
2005-07-28 12:06 ` Jonathan Larmour [this message]

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