[PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
gregkh at suse.de
Fri Jul 30 13:36:32 EST 2010
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 at suse.de> 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 at suse.de> 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.
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
> >> 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.
More information about the Linuxppc-dev