public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* Copyright and maintainability question for new ARM Cortex A9 HAL
@ 2013-09-05  3:52 Michael Jones
  2013-09-07  3:04 ` Jonathan Larmour
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Jones @ 2013-09-05  3:52 UTC (permalink / raw)
  To: ecos-maintainers; +Cc: john@dallaway.org.uk Dallaway

Hi,

John Dallaway suggested I post a question I asked him to this list for comment, so here it goes...


I wanted to talk about copyright assignment issues with my Freescale iMX6X work early in the process.

The status is:

- Project not registered yet
- Uses Freescale SDK macros
- Uses Freescale SDK code for MMU, GIC, etc
- UART working
- Runs on a single core of an iMX6Q Sabre SD board
- Debuggable with JLink
- Runs a ported SDK primes app as a two thread eCos program

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, or see if Freescale will assign copyright? I need advice on options before I spend a bunch of time rewriting the Freescale code I am using.

I have to make a trip to Freescale in Austin TX Sept 24th, so I have an opportunity to discuss with them if you know the appropriate people to discuss with.

Things on my road map not related to copyright:

- Getting SMP running
- Multicore debugging with JLink
- Getting Mentor Probe Working with a true multicore debugger (not separate GDB sessions in Eclipse)
- Building bin files for SD or flash
- Peripherals like Ethernet
- Registering the project
- Building a releasable toolchain (works for me, but nothing like works for everyone)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Copyright and maintainability question for new ARM Cortex A9 HAL
  2013-09-05  3:52 Copyright and maintainability question for new ARM Cortex A9 HAL Michael Jones
@ 2013-09-07  3:04 ` Jonathan Larmour
  2013-09-07 13:40   ` Michael Jones
  0 siblings, 1 reply; 4+ messages in thread
From: Jonathan Larmour @ 2013-09-07  3:04 UTC (permalink / raw)
  To: Michael Jones; +Cc: ecos-maintainers

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Copyright and maintainability question for new ARM Cortex A9 HAL
  2013-09-07  3:04 ` Jonathan Larmour
@ 2013-09-07 13:40   ` Michael Jones
  2013-12-04 12:08     ` "Ilija Kocho [Илија Кочо]"
  0 siblings, 1 reply; 4+ messages in thread
From: Michael Jones @ 2013-09-07 13:40 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: ecos-maintainers

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Copyright and maintainability question for new ARM Cortex A9 HAL
  2013-09-07 13:40   ` Michael Jones
@ 2013-12-04 12:08     ` "Ilija Kocho [Илија Кочо]"
  0 siblings, 0 replies; 4+ messages in thread
From: "Ilija Kocho [Илија Кочо]" @ 2013-12-04 12:08 UTC (permalink / raw)
  To: ecos-maintainers; +Cc: Michael Jones, Jonathan Larmour

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-12-04 12:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-05  3:52 Copyright and maintainability question for new ARM Cortex A9 HAL Michael Jones
2013-09-07  3:04 ` Jonathan Larmour
2013-09-07 13:40   ` Michael Jones
2013-12-04 12:08     ` "Ilija Kocho [Илија Кочо]"

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