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.)
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.
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?
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