public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: "\"Ilija Kocho [Илија Кочо]\"" <ilijak@siva.com.mk>
To: ecos-maintainers@ecos.sourceware.org
Cc: Michael Jones <mjones@linear.com>,
	 Jonathan Larmour <jifl@eCosCentric.com>
Subject: Re: Copyright and maintainability question for new ARM Cortex A9 HAL
Date: Wed, 04 Dec 2013 12:08:00 -0000	[thread overview]
Message-ID: <529F1B33.1020603@siva.com.mk> (raw)
In-Reply-To: <D2E77CB2-982D-4640-82E6-1952E9F0771B@linear.com>

Maintainers,

The licence below is practically "3 clause BSD". Since we already have
BSD-licenced code in our tree, I propose that we accept Freescale's code
published under this licence.
 
Any remarks?

Ilija


On 07.09.2013 15:39, Michael Jones wrote:
> Jonathan,
>
> The files have the following copyright. They do not refer to any license.
>
> I find the second redistribution clause a nuisance. It means if you make an app or library and distribute, you have to reproduce the copyright notice. Just how do you do that with an end application?
>
> Mike
>
> /*
>  * Copyright (c) 2013, Freescale Semiconductor, Inc.
>  * All rights reserved.
>  *
>  * Redistribution and use in source and binary forms, with or without modification,
>  * are permitted provided that the following conditions are met:
>  *
>  * o Redistributions of source code must retain the above copyright notice, this list
>  *   of conditions and the following disclaimer.
>  *
>  * o Redistributions in binary form must reproduce the above copyright notice, this
>  *   list of conditions and the following disclaimer in the documentation and/or
>  *   other materials provided with the distribution.
>  *
>  * o Neither the name of Freescale Semiconductor, Inc. nor the names of its
>  *   contributors may be used to endorse or promote products derived from this
>  *   software without specific prior written permission.
>  *
>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
>  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>  * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>  * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
>  * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>  * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>  * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
>  * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>  * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>
>
>
> On Sep 6, 2013, at 9:04 PM, Jonathan Larmour <jifl@eCosCentric.com> wrote:
>
>> 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:
>> http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses
>>
>> 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.
>>
>> Jifl
>>
>> -- 
>> eCosCentric Limited      http://www.eCosCentric.com/     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-12-04 12:08 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
2013-09-07 13:40   ` Michael Jones
2013-12-04 12:08     ` "Ilija Kocho [Илија Кочо]" [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:
  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=529F1B33.1020603@siva.com.mk \
    --to=ilijak@siva.com.mk \
    --cc=ecos-maintainers@ecos.sourceware.org \
    --cc=jifl@eCosCentric.com \
    --cc=mjones@linear.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).