Freescale HAL licencing + processor selection help
Joel Sherrill
joel.sherrill at oarcorp.com
Wed Jun 17 03:24:08 UTC 2015
On June 16, 2015 10:07:23 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>On 17/06/2015 9:54 am, Joel Sherrill wrote:
>>>
>>> This can be true and tends to reflect internal corporate structures
>in
>>> companies than technical reasons. Bringing about change here takes
>time
>>> and patience. I am always positive chip companies want to make and
>sell
>>> devices and we just need to keep reminding them their actions
>>> negatively
>>> effect us directly and them indirectly.
>>
>> I haven't thought it was good practice to be public about vendor
>licenses but maybe we should consider making a list of vendor licenses
>we might have interest in, review them, and post our conclusions. Not
>legal advice obviously but public commentary on the potential problems
>they cause.
>>
>
>I think we are heading in this direction. It needs to be simple to
>access and explain the status without being critical. We need to
>respect
>the wishes of the chip makers even if we do not agree.
>
>In the case of an SDK with a covering EULA which is more restrictive
>than some of the code it contains a user can agree to the EULA and use
>the code and that may suite their use and project. The problem is each
>user needs to do the same and that is a waste of effort and time. My
>hope is the companies doing this are doing it because the EULA has to
>meet the most restrictive part of package and this makes sense. If the
>BSD licensed code contained in a package is really a BSD license all
>the
>chip maker needs to do is provide it as a tarball on their web site
>without restriction. This does not dilute any EULA issues contained
>else
>where in their package.
Yep. The layers of agreements can be ugly. And contradictory.
>> If we do that, we may be able to enlist some help from the other free
>OS people we have met over the years.
>
>I am happy with this as long as the type of license does not become an
>issue.
I don't want to be hypercritical. Our focus would be would we merge this code under this license into rtems, is it license compatible with other free licenses, could you use it with rtems, and what burdens/obligations does it impose on a user.
The other OS view is simply to get help addressing licenses we collectively view as problematic.
>Chris
--joel
More information about the users
mailing list