Subject: Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.

From: Greg KH <[email-masked]>
Date: Thu, 29 Jul 2010 20:36:32 -0700

On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <[email-masked]> 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 <[email-masked]> 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