On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote: > On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@xxxxxxx> wrote: > > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote: > >> Hi Greg: > >> > >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@xxxxxxx> wrote: > >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote: > >> >> Hi Greg: > >> >> > >> >> We will change to a BSD 3 clause license header. Our legal counsel is > >> >> talking to Synopsis to make this change. > >> > > >> > Why BSD? ??You do realize what that means when combined within the body > >> > of the kernel, right? > >> > > >> > >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the HP > >> ?? ?? ?? ?? ?? ??Hil driver. > > > > What specific driver is this? > > FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others. Ok, thanks. Are you _sure_ that you didn't take any existing GPL code and put it into this driver when making it? Did all contributors to the code release their contributions under both licenses? > > And are you sure that all of the contributors to the code agree with > > this licensing change? ??Are you going to require contributors to > > dual-license their changes? > > > > If so, why keep it BSD, what does that get you? > > FKAN: for one thing, to make it future proof on other submissions. What do you mean by this? What can you do with this code other than use it on a Linux system? You can't put it into any other operating system with a different license, can you? > >> > Are you going to be expecting others to contribute back to the code > >> > under this license, or will you accept the fact that future > >> > contributions from the community will cause the license to change? > > > > > > You didn't answer this question, which is a very important one before I > > can accept this driver. > > FKAN: Yes, all of the above. Our legal is working on that. I thought by default > GPL defines the above statement. The GPL does, but as you are trying to dual-license the code, you have to be careful about how you accept changes, and under what license. It's a lot more work than I think you realize. What process do you have in place to handle this? > >> >> We will resubmit once this is in place. Please let me know if you have > >> >> any additional concerns. > >> > > >> > My main concern is that you, and everyone else involved in the driver, > >> > never considered the license of the code in the first place and expected > >> > the kernel community to accept it as-is, placing the problem on us. > >> > >> FKAN: Please don't think this is the case, we gone through this exercise > >> ?? ?? ?? ?? ?? with Denx. > > > > What is "Denx"? > > FKAN: U-Boot Denx.de Ah, thanks. > >> We had legal looking into the header before submission > >> ?? ?? ?? ?? ?? to them and the kernel. > > > > Then what happened here? ??Just curious as to how the driver was public > > for so long before someone realized this. > > > > FKAN: this was few years back. At the time we had the header changed > so it was BSD like to be accepted by Denx. > > >> > What will be done in the future to prevent this from happening again? > >> > >> FKAN: agreed, once bitten .... :) > > > > That didn't answer the question :) > > FKAN: we have a system of checks for every patch that goes out. I will send > out a guideline to all reviewer to make sure the header > follow kernel precedence. But you took this code from a different vendor, are you able to properly identify the code contributions to this base and what license it is under and where they got it from? > Legal is quite aware of the issue now too. As they should be :) Please reconsider the dual licensing unless you really are ready to handle the implications of it. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
