Freescale HAL licencing + processor selection help

[Joel Sherrill]

On June 16, 2015 6:37:32 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>On 17/06/2015 3:01 am, Gedare Bloom wrote:
>> On Tue, Jun 16, 2015 at 12:51 PM, Isaac Gutekunst
>> <isaac.gutekunst at vecna.com> wrote:
>>> Do you have any advise when talking to ST? I will ask if it is
>possible to
>>> release the HAL code separately, or to clarify the licencing.
>>>
>> Chris Johns has had some direct interactions with vendors about this
>> problem before and might have advice.
>> 
>
>Isaac, please feel free to include me on any discussions on the topic.
>If you talk to your FAE and get a suitable contact name at ST and you
>do
>not wish to take this on please send me the details and I will look
>into it.

Please also include me. 

Did one of the links you posted earlier have the license text?


>My experience is these things take time and it is about informing and
>highlighting the issues their licenses create.

Agreed. And often lots of time.

>> One way to get started is to see if they already provide some
>> suitably-licensed code for Linux. A lot of vendors do so already
>> because of market reasons, but don't realize how this problem affects
>> smaller market segments like RTOSs.
>
>Yes this is a strange situation. Xilinx is a good example of how they
>support the development of open GPL code for Linux for their chips and
>then they use a restrictive license on the SDK/BSP code that is
>functionally equivalent and better suited to us. Same company, same
>funding source, same devices but very difficult outcomes.
>
>> While I haven't been in any of these talks, from what I have heard
>the
>> main sticking point seems to be that vendors are hesitant to release
>> code that might possibly be useful on competitors' products. For HALs
>> and drivers, this hesitancy makes little sense, so being convincing
>> about how the code can possibly be used (i.e. it really is only
>useful
>> to drive their boards) may help. And, again, it can help if you can
>> point to other drivers the vendors may have released for Linux or
>> other mainstream OS.
>
>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.

If we do that, we may be able to enlist some help from the other free OS people we have met over the years.

>Chris
>_______________________________________________
>users mailing list
>users at rtems.org
>http://lists.rtems.org/mailman/listinfo/users

--joel