[U-Boot] [PATCH] drivers/ddr/fsl: Dual-license DDR driver

[York Sun]

On 02/13/2018 11:16 AM, Marek Vasut wrote:
> On 02/13/2018 07:32 PM, York Sun wrote:
>> On 02/13/2018 09:38 AM, Marek Vasut wrote:
>>> On 02/13/2018 05:30 PM, York Sun wrote:
>>>> On 02/13/2018 04:49 AM, Wolfgang Denk wrote:
>>>>> Dear York,
>>>>>
>>>>> In message <VI1PR04MB20785EF7D2578E39C048EE219AF70 at VI1PR04MB2078.eurprd04.prod.outlook.com> you wrote:
>>>>>>
>>>>>> Nobody said anything. Some addresses bounced. And most changes made out
>>>>>> people outside Freescale/NXP are minor changes, except twice the files
>>>>>> were moved during U-Boot structure change. What options do I have?
>>>>>
>>>>> Ask all people who contributed to that code for their explicit
>>>>> permission.  Legally it is a huge difference between actively
>>>>> confirming approval and not reacting at all.
>>>>>
>>>>
>>>>
>>>> All,
>>>>
>>>> If you haven't responded, please give your explicit approval to change
>>>> Freescale DDR driver to dual-license so it can be re-used by other
>>>> project(s) with BSD license. Here is the list I compiled from the git
>>>> history. All commits made by Freescale/NXP employees are removed from
>>>> this list.
>>>
>>> [...]
>>>
>>>> cd84b1f - Marek Vasut, marek.vasut at gmail.com, 6 years ago : GCC4.6:
>>>> Squash warnings in ddr[123]_dimm_params.c
>>>
>>> I do NOT approve.
>>>
>>> My previous experience with dual-licensed code was with wpa-supplicant.
>>> A certain company manufacturing handhelds took it, modified it and was
>>> selling the binary. While we were porting Linux onto the device, we
>>> asked for the modifications to get the WiFi operational in the Linux port.
>>>
>>> What we got from this company was "it's BSD licensed, go away". Were the
>>> code GPL, they would be legally obliged to provide the changes, but it
>>> was BSD, so the company in question could make profit and the community
>>> lost.
>>>
>>> This was a prime example of how BSD license is harmful to software
>>> freedom and how the community lost because of the BSD license. I do not
>>> want to see this happening ever again and I like GPL for that very much.
>>>
>>
>> Marek,
>>
>> Please allow me to try to convince you.
>> Git log shows you have one commit cd84b1f which fixed the compiling
>> warning for GCC 4.6 on three debug messages. I appreciate your fix.
>>
>> This driver is for Freescale/NXP DDR controllers, specifically designed
>> on Freescale/NXP SoCs. We spent tremendous effort to make it robust.
>> This driver is useful to initialize DDR for the platforms. While we are
>> moving the platform initialization to ATF (Arm Trusted Firmware), or
>> other pre-bootloader code (such as NXP's implementation of ATF), this
>> driver can be reused to provide the same level of hardware support. As
>> you may know, ATF uses BSD-3 license (some files have GPL/BSD dual
>> licnese). Your approval will make our life easier without having to
>> rewrite the entire driver from scratch.
> 
> So what is in it for me ?

You may have the flexibility to use ATF or other pre-bootloader software
_if_ we successfully upstream this driver to ATF project.

> 
> If the code remains GPL, I can ask NXP for changes to the driver if I
> have the binary which contains this code.
> 
> If the code gets re-licensed to dual GPL/BSD, I assume in certain cases,
> NXP will choose BSD and will not be obliged to provide the changes.

Guess who makes substantial changes to the hardware driver? The people
with extensive knowledge of the hardware design. It's not our interest
to hide our design from any users.

> 
> I don't see any benefit for me, any way I look at it, I'm either even or
> loose .

If we don't find a way to reuse this driver, I will have to write a new
driver. It's not easy to keep two different drivers in sync. So _this_
driver will probably be left behind. I don't think that's in anyone's
interest.

> 
> Why can't you use the code under the current (GPL) license anyway ?
> 

Do you think the GPL driver can be added to ATF project? I don't think
so. So it is a matter of we either can have it in ATF, or we can't.

York