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 >>>>>>>> <vi1pr04mb20785ef7d2578e39c048ee219a...@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.va...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
