[PATCH v2] Move brcm80211 to mainline

[Greg KH]

On Wed, Aug 31, 2011 at 10:55:45AM -0700, Luis R. Rodriguez wrote:
> On Tue, Aug 30, 2011 at 11:14 AM, Greg KH <gregkh at suse.de> wrote:
> > On Mon, Aug 29, 2011 at 06:42:57PM -0700, Henry Ptasinski wrote:
> >> The brcmsmac driver has architectural alignment with our drivers for other
> >> operating systems, and we intend to to enhance and maintain this driver in
> >> parallel with drivers for other operating systems.  Maintaining alignment
> >> between our Linux driver and drivers for other operating systems allows us to
> >> leverage feature and chip support across all platforms.
> >
> > Just curious, if you really are going to try to do this, how are you
> > going to handle the issue when others change the in-kernel driver in
> > ways that you are not going to be allowed to make to your "internal"
> > copy of the driver?
> 
> What do you mean by this?

 - Infrastructure changes that do not match up with how other operating
   systems handle things.
 - support for new features
 - support for older devices
 - license incompatibilities (i.e. new files under GPL-only license
 - etc.

> > Also, how are you going to handle any GPL-only changes that happen to
> > the code as well?
> 
> For the broadcom drivers this may be hard if people want to move GPLv2
> b43 code to a permissively licensed driver... but ...
> 
> > Do you have some process in place to ensure that all
> > contributions will have the proper copyright releases on it to allow you
> > to make the same changes to your internal versions?
> 
> To be clear *new* code going in to a permissively licensed driver
> follows the Developer's Certificate of Origin which does state the
> contributor follows the file's license.

For an existing file, yes.

But for new files, or for copying code from another driver (GPL only)
into this one (dual licensed), that's different, right?

You need to be very careful about this, that's all.

> The issues with a large GPLv2 code from b43 and the fact that the
> other driver is permissively licensed makes this a bit more
> complicated though, but that is only a reflection of not addressing
> supporting old hardware. Ouch.

Yes, this is going to be tricky :)

That is what I am worried about, but I know the lawyers and developers
at Broadcom have already considered this, but they haven't told us how
they are going to handle it, which is what I'm curious about.

Then there the issue that some companies want to keep their internal
copies in a non-dual licensed codebase, to handle the license of the
other operating systems they are working with.  Hopefully Broadcom isn't
going to do this, but others have in the past (SGI with xfs, Intel with
the ACPI core, etc.)

thanks,

greg k-h