Freescale HAL licencing + processor selection help

Isaac Gutekunst isaac.gutekunst at vecna.com
Wed Jun 17 13:10:27 UTC 2015


One more point to both clarify and confuse the matter:

http://www.st.com/web/en/catalog/tools/PF259243#

Note the sentence:

"The HAL is available in open-source BSD license for user convenience."

It looks like it shouldn't be too hard to get them to release it as a 
separate download.


Isaac

On 06/17/2015 09:08 AM, Isaac Gutekunst wrote:
> It looks like there are two main issues to tackle:
>
> 1) What licences are acceptable to include in the RTEMS distribution
> with compromising the modified GPL licence?
>
> I think the 3-clause BSD licence is acceptable for inclusion within a
> GPL (and probably most modified GPL licences). I can probably work with
> our legal team to answer this specific questions, though we can't make
> the decision for RTEMS and we aren't prepared to offer formal legal advice.
>
> In the more general case, it could be useful to browse the Linux kernel
> tree and see which licences are present.
>
>
> 2) How to we communicate and work with chip vendors to reach a mutually
> beneficial licencing situation?
>
> I think that if the right people hear our argument, it is very clearly
> in their best interest to release some portion of the code with a
> permissive licence. From the point of view, the low level HAL code is
> unlikely to ever be useful outside of using their chips, and releasing
> it simply encourages usage of their chips. It can probably even be
> turned into a competitive advantage even in the marketing department.
>
> The problem will be getting these arguments in front of the right
> people. I'll keep you in the loop following our Friday meeting.
>
>
> Another questions to consider: Does it even make sense to merge this (or
> other) code? Often the style and semantics make it necessary to add
> translation layer on top of the HAL(1) just to make a peripheral fit
> into the RTEMS (or other project) architecture.
>
> Gedare Bloom brought this up earlier:
>
>  > Writing from scratch, or even stripping code out of
>  > appropriately-licensed vendor sources, probably gives you the best
>  > chance at having a modest code size and insight into maintenance. It
>  > can also let you leverage the (evolving) frameworks in RTEMS for
>  > drivers, such as in cpukit/dev/i2c for I2C, and in cpukit/libdrvmgr
>  > [experimental stuff there]. This may lead to long-term benefits in
>  > terms of code size and reuse, and less reliance on the upstream vendor
>  > to provide patches etc. But the up front cost is obviously higher.
>
> This is where we will need assistance in making sure our dev time is
> well spent and useful to the community. Of course we have time to market
> considerations, but I hope we can give back some value.
>
> Isaac
>
>
> (1) HAL: I'm thinking of very barebones, low level, non-thread-safe code
>
> On 06/16/2015 11:24 PM, Joel Sherrill wrote:
>>
>>
>> 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
>>
>

-- 
Isaac Gutekunst
Embedded Systems Software Engineer
isaac.gutekunst at vecna.com
www.vecna.com

Cambridge Research Laboratory
Vecna Technologies, Inc.
36 Cambridge Park Drive
Cambridge, MA 02140
Office: (617) 864-0636 x3069
Fax: (617) 864-0638
http://vecna.com

Better Technology, Better World (TM)

The contents of this message may be privileged and confidential. 
Therefore, if this message has been received in error,
please delete it without reading it. Your receipt of this message is not 
intended to waive any applicable privilege.
Please do not disseminate this message without the permission of the 
author.



More information about the users mailing list