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

[Marek Vasut]

On 02/13/2018 09:14 PM, York Sun wrote:
> On 02/13/2018 12:09 PM, Marek Vasut wrote:
>> On 02/13/2018 08:33 PM, York Sun wrote:
>>> 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.
>>
>> It also allows you to just distribute binaries of the ATF without
>> releasing the source.
>>
>>>> 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.
>>
>> Well, it seems this patch was applied to U-Boot master anyway [1], even
>> though there are concerns and ongoing discussion ... so I lost anyway.
>>
>> I am _extremely_ disappointed !
> 
> I take the responsibility for requesting the pull without getting your
> approval in time. I am still trying to convince you it is right to use
> dual license on this driver. Do you want to continue the discussion?

No, do whatever you want with this file.

I am not looking forward to the day when this salami-method progresses
enough so that everything that used to be GPL will be nicely GPL/BSD
dual-licensed, everything will be technically open-source on paper, but
noone will be able to get sources for anything anymore. That is exactly
what the BSD license allows.

-- 
Best regards,
Marek Vasut