[ale] pigs do fly

Michael B. Trausch mbt at zest.trausch.us
Mon Jul 20 22:59:30 EDT 2009


On Mon, 20 Jul 2009, Richard Bronosky wrote:

> "developed Linux drivers to the Linux community for possible inclusion
> in the Linux source tree"
>
> I'm not sure what "inclusion in the source tree" entails, but I will
> compile my own kernel to stand my ground against this menace.

Unless you are running a Linux kernel under HyperV, you aren't going to be 
running that code. It is quite likely to also not be enabled by default, just 
as Xen support is not---you would have to compile it in.

That said, the code is GPL, and it can be openly audited.  As with anything, 
it should be looked at on its own merit, not the author's merit.  It does not 
matter if a contributor is well-known or well-liked, when it comes to 
favorably-license code; it only matters whether or not the code stands up on 
its own merits.

At least, that's the way it used to be in our world. Are we about to change 
the rules just because we don't like one of the people or companies that have 
contributed code?  I should think not.  But then again, I also don't think 
that code should fly into the kernel without inspection just because the 
person that wrote it is well-known on the LKML and usually submits bug-free 
code.  I remember a few root exploits that were dropped in without 
review---accidentally, mind---just because the contributor was liked and 
known.

It is that way, when we want it to be.  If it weren't, people would never rise 
up into projects, become committers, etc.; we'd never have any new 
programmers, because they wouldn't have a chance.

The best thing to do with a GPL contribution frm Microsoft is to do as we 
should do with any other GPL code that is proposed for integration into a 
project such as Linux or GNU---it should be carefully reviewed for quality 
and feedback should be given if the contribution is improper, incorrect, or 
insecure.

Not everyone who works for Microsoft is inherently bad, and companies 
themselves cannot be inherently good or bad.  All that leaves is that we must 
treat the contribution as we would treat a contribution from anyone else who 
would be new to the kernel---carefully review it and test it and ensure that 
it does what it claims to do; nothing more, nothing less.  Now, I know that I 
don't run any Windows systems here, so I would not be in a position to 
competently review the code---I know nothing of the APIs that are used in 
Windows systems, much less their virtualization technology.  Consequently, as 
I will never choose to run Windows systems, I would never run that code as it 
is written, anyway.

 	--- Mike


More information about the Ale mailing list