Freescale HAL licencing + processor selection help

[Isaac Gutekunst]

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
>

--