Ari Jaaksi of Nokia Wants to Educate the Linux Community

Wed Jun 11 17:33:38 -0700 2008
(in reply to Ari Jaaksi of Nokia Wants to Educate the Linux Community )

In your opinion, is there anything special about these two cases:

System calls in kernel X that are non-standard and that, by their nature, are particular to the kernel? If not, how does this differ from the case of the readline library?

GPL'ed dynamically loadable modules that externalize non-standard interfaces to user-space, where those non-standard interfaces are highly specific to a non-free program?

(These refer to real-world cases I've seen and I'm not interested in arguing about them -- only in hearing how you advise about such things. I (a ways back) wasn't asked to advise in the serious way you do but was asked for an opinion about them and tried to indicate that basically I didn't know but it sounded a bit sketchy.)

-t

 
Ari Jaaksi of Nokia Wants to Educate the Linux Community
Wed Jun 11 18:17:50 -0700 2008

I tell my customers to stay away from both, they are legally ambiguous and I don't want my customers to be the test case.

I advise them that if it has to mess with the kernel, to put the BSD or GPL license on it, and keep it publicly available, and try to get the kernel team to accept it.

Sometimes there is friction. Some causes are:

  • Vendor-owned software or trade-secret hardware interface in an embedded product. You must design especially carefully to protect this third party's rights, and your liability to both the third party and the Free Software folks.
  • Lazy over-estimate of the differentiating value of your kernel driver and the information it reveals.
  • Poor engineering resulting in too much proprietary information at the driver level.
  • Legal isn't funded sufficiently to meet engineering's needs, or isn't cooperative.
  • Engineering didn't get "Intellectual Property 101" training. Call me and get it for them.
 
Ari Jaaksi of Nokia Wants to Educate the Linux Community
Sun Jun 15 08:24:22 -0700 2008

I work on 'simi-open' linux drivers which have been chosen because they are non-GPL.  Specifically, a set of well known network drivers under a BSD license.  As a company we choose these drivers as a starting point because of the BSD-ness.  We do release patches that fix bugs in the original driver, but do not release any in-line extensions we have made.

My personal opinions on the 'right' path aside, the model of having BSD licensed kernel modules in a GPL kernel in support of proprietary development seems to be in contradiction to your position.  In 16+ years working on linux drivers at a number of companies this is both common and an expected way to retain some market advantage.  I have no problem being wrong, but there are an awful lot of BSD licensed drivers for linux that have life becuase they are both BSD licensed and Linux.

So, does a BSD licensed driver in a Linux kernel lead to a GPL license behavior of that driver?

 It was stated that linux kernel modules are undefined territory but you wouldn't want your customers to be the test case.  Then, you say to release under BSD or GPL license.  How can a BSD license which does allow for propietary extension be an acceptable license option if the kernel GPL leaves that driver in an ambigious position?