> On 11/20/2011 12:02 AM, Nobody wrote:
>> On Sat, 19 Nov 2011 21:36:11 -0600, bbhack wrote:
>>
>>> A proprietary kernel module "taints" the kernel. There is nothing
>>> technically wrong with proprietary modules except for this. RMS and
>>> others would disagree, but whatever. Activist kernel coders can
>>> cause their drivers to not play nice in a tainted kernel. I'm not sure
>>> if this has ever been done.
>>
>> Such a driver wouldn't be accepted into the main kernel tree.
>>
>> The reason behind the taint mechanism is so that kernel developers don't
>> waste their time dealing with bugs which they have no chance of
>> resolving.
>> If you can't reproduce the problem with an untainted kernel, then the
>> problem is related to a proprietary module for which the developers can't
>> get the source code and thus can't realistically debug.
>>
>> The fact that the taint mechanism exists is an acknowledgement of the
>> existence of proprietary kernel modules. The kernel developers aren't
>> generally averse to the existence of such modules, they just don't
>> consider any issues which they may cause to be their responsibility.
>>
>
> Unless the code is widely useful and passes muster with the upper
> eschelon of kernel devs, no one is going to pay it a thought anyway.
> There is virtually no possibility that your code will be debugged in
> a mainline kernel by anyone but you.
>
> Here are some points. Feel free to disagree.
>
> As a small dev with a product, no one is going to care about your
> source. If will never be looked at by anyone but you, unless
> something goes wrong.
>
> There are many reasons to not publish source code, but almost no
> reasons to not publish your linux driver source. No one will ever
> look at it, unless there is a liability issue, and then no lawyer
> will ever look at it. A consultant will look at it maybe, and tell
> the lawyer what he wants to hear. This is a tiny possibility, and
> not worth the difference in outcome vs closed source, which will be
> subpoenaed anyway.
>
> The term "publish" is misleading. You do not have to offer the source
> to anyone except those you do business with. Just because you put
> a GPL on some code does not mean you have to put the source on a
> website. It can be just between you and your customers. _They_ can
> put it on a website if they wish, but they will not. They will never
> even ask for it.
>
> An undocumented driver interface is all the IP protection you need
> generally, if you feel you need it. Most small companies should
> spend more time marketing, and less worrying about IP security,
> unless of course your business is security. Then we all know the
> lessons about obscurity.
>
> If any of this matters, do not start with a GPL OS.
>
Although no one will give your driver much thought if it is for a
specific device that you make, the kernel developers /will/ look at if
you ask them for help - as long as it is under the GPLv2, and follows
kernel coding standards.
Reply by bbhack●November 21, 20112011-11-21
On 11/20/2011 12:06 PM, David Brown wrote:
>> A proprietary kernel module "taints" the kernel. There is nothing
>> technically wrong with proprietary modules except for this. RMS and
>> others would disagree, but whatever.
>
> Yes, there is very much something technically wrong with modules that
> don't use the GPLv2 - it is a breach of license to distribute such modules.
>
> Lots of people /do/ disagree with such modules being used - you don't
> have to be as extreme as RMS.
I should not have said it that way. The kernel umbrella is GPLv2, and
that's pretty much the story.
Reply by bbhack●November 21, 20112011-11-21
On 11/20/2011 12:02 AM, Nobody wrote:
> On Sat, 19 Nov 2011 21:36:11 -0600, bbhack wrote:
>
>> A proprietary kernel module "taints" the kernel. There is nothing
>> technically wrong with proprietary modules except for this. RMS and
>> others would disagree, but whatever. Activist kernel coders can
>> cause their drivers to not play nice in a tainted kernel. I'm not sure
>> if this has ever been done.
>
> Such a driver wouldn't be accepted into the main kernel tree.
>
> The reason behind the taint mechanism is so that kernel developers don't
> waste their time dealing with bugs which they have no chance of resolving.
> If you can't reproduce the problem with an untainted kernel, then the
> problem is related to a proprietary module for which the developers can't
> get the source code and thus can't realistically debug.
>
> The fact that the taint mechanism exists is an acknowledgement of the
> existence of proprietary kernel modules. The kernel developers aren't
> generally averse to the existence of such modules, they just don't
> consider any issues which they may cause to be their responsibility.
>
Unless the code is widely useful and passes muster with the upper
eschelon of kernel devs, no one is going to pay it a thought anyway.
There is virtually no possibility that your code will be debugged in
a mainline kernel by anyone but you.
Here are some points. Feel free to disagree.
As a small dev with a product, no one is going to care about your
source. If will never be looked at by anyone but you, unless
something goes wrong.
There are many reasons to not publish source code, but almost no
reasons to not publish your linux driver source. No one will ever
look at it, unless there is a liability issue, and then no lawyer
will ever look at it. A consultant will look at it maybe, and tell
the lawyer what he wants to hear. This is a tiny possibility, and
not worth the difference in outcome vs closed source, which will be
subpoenaed anyway.
The term "publish" is misleading. You do not have to offer the source
to anyone except those you do business with. Just because you put
a GPL on some code does not mean you have to put the source on a
website. It can be just between you and your customers. _They_ can
put it on a website if they wish, but they will not. They will never
even ask for it.
An undocumented driver interface is all the IP protection you need
generally, if you feel you need it. Most small companies should
spend more time marketing, and less worrying about IP security,
unless of course your business is security. Then we all know the
lessons about obscurity.
If any of this matters, do not start with a GPL OS.
Reply by David Brown●November 21, 20112011-11-21
On 20/11/2011 21:50, Nobody wrote:
> On Sun, 20 Nov 2011 19:06:35 +0100, David Brown wrote:
>
>> Yes, there is very much something technically wrong with modules that
>> don't use the GPLv2 - it is a breach of license to distribute such modules.
>
> That depends upon whether they are derivative works of GPL'd code which is
> subject to copyright. Headers are something of a grey area, as it's
> legally unclear whether manifest constants, function prototypes or
> trivial macros are actually subject to copyright.
>
That's true enough.
It is certainly the case that if you use something that is not covered
by the header files (such as by putting "extern" declarations in your
code to get access to non-exported data or functions), then you are
creating a derivative work and need to put it under the GPL.
In most cases, using a header file without linking to the GPL'ed code
directly is not considered a derivative work. Thus a normal Linux
application can happily #include system headers while using whatever
license it wants.
But Linux kernel modules are a special case - they are their own unique
shade of grey.
In particular, it is a perfectly reasonable interpretation of the GPL to
say that since modules form part of the same address space as the rest
of the kernel, they are combined together (at load time) to form a
single executing program. Therefore modules are a derivative work.
Also, modules are compiled for particular versions of the kernel - they
are not stand-alone programs communicating through a stable and
documented API (as is done for user-mode applications). This again is
interpreted by many as a clear indication that they form a derivative
work. It is this aspect that Nvidia et.al. work around by having a
GPL'ed driver stub that communicates with the "real" driver using only a
specific and limited set of functions.
Ultimately, there are three sets of interpretations of the licensing
that are relevant - those of the kernel code authors, those of the
module authors, and those of the courts if it ever gets challenged
legally. Ethically and morally, the most important is the intention of
the kernel code authors in how they want their code to be used.
Opinions vary between those that only want GPL'ed modules to use their
code, those that /prefer/ GPL'ed modules but accept non-GPL'ed modules,
and those that don't care. Linux therefore has a system in place to
allow all of these opinions (Linus Torvalds is known for his pragmatism,
if not his diplomacy). Kernel code and modules can export symbols as
either normal symbols, or GPLONLY symbols. Any non-GPL'ed module can
only access the normal symbols - it is not allowed to access the GPLONLY
symbols.
Of all the kernel developers' opinions, the most important is Linus
Torvald's:
Quotation from:
<http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html>
Alessandro: What is your position about the availability of Linux
modules in binary-only form?
Linus: I kind of accept them, but I never support them and I don't like
them.
The reason I accept binary-only modules at all is that, in many cases,
you have, for example, a device driver that is not written for Linux at
all, but, for example, works on SCO Unix or other operating systems, and
the manufacturer suddenly wakes up and notices that Linux has a larger
audience than the other groups. And as a result he wants to port that
driver to Linux.
But because that driver was obviously not derived from Linux (it had a
life of its own regardless of any Linux development), I didn't feel that
I had the moral right to require that it be put under the GPL, so the
binary-only module interface allows those kinds of modules to exist and
work with Linux.
That doesn't mean that I would accept just any kind of binary-only
module: there are cases where something would be so obviously
Linux-specific that it simply wouldn't make sense without the Linux
kernel. In those cases, it would also obviously be a derived work, and
as such the above excuses don't really apply any more, and it falls
under the GPL license.
Reply by Nobody●November 20, 20112011-11-20
On Sun, 20 Nov 2011 19:06:35 +0100, David Brown wrote:
> Yes, there is very much something technically wrong with modules that
> don't use the GPLv2 - it is a breach of license to distribute such modules.
That depends upon whether they are derivative works of GPL'd code which is
subject to copyright. Headers are something of a grey area, as it's
legally unclear whether manifest constants, function prototypes or
trivial macros are actually subject to copyright.
Reply by David Brown●November 20, 20112011-11-20
On 20/11/11 04:36, bbhack wrote:
> On 11/10/2011 02:53 PM, aregan wrote:
>> Hi,
>>
>> I'm looking at the possiblity of developing a product which will use
>> linux
>> embedded but have few newbe questions. I'm a software engineer with about
>> 15 years expierence, but its been a while since I've developed for linux.
>>
>> First question is about licensing.
>> Lets say I'm building a new device that uses linux, for example its a new
>> router. What versions of linux are free for me to use as my device OS.
>> Must I only make available the OS source code, or must I also make
>> available the source code that drives my device?
>
> I did not see this info in a quick scan of the responses, so I may have
> missed it.
>
I mentioned it briefly in one of my replies - but it would be easy to
miss in a quick scan.
> A proprietary kernel module "taints" the kernel. There is nothing
> technically wrong with proprietary modules except for this. RMS and
> others would disagree, but whatever.
Yes, there is very much something technically wrong with modules that
don't use the GPLv2 - it is a breach of license to distribute such modules.
Lots of people /do/ disagree with such modules being used - you don't
have to be as extreme as RMS.
But there is a grey area - modules that stick to a restricted set of API
functions, and admit to "tainting" the kernel, and that have good reason
for being non-GPLv2 (such as in the case of the proprietary graphics
card drivers) are grudgingly tolerated by most kernel developers (lead
by Torvalds) as not breaking the licences. They consider it technically
wrong - but understand that it is often better for users to have a
proprietary driver than no driver.
> Activist kernel coders can
> cause their drivers to not play nice in a tainted kernel. I'm not sure
> if this has ever been done.
>
Reply by Nobody●November 20, 20112011-11-20
On Sat, 19 Nov 2011 21:36:11 -0600, bbhack wrote:
> A proprietary kernel module "taints" the kernel. There is nothing
> technically wrong with proprietary modules except for this. RMS and
> others would disagree, but whatever. Activist kernel coders can
> cause their drivers to not play nice in a tainted kernel. I'm not sure
> if this has ever been done.
Such a driver wouldn't be accepted into the main kernel tree.
The reason behind the taint mechanism is so that kernel developers don't
waste their time dealing with bugs which they have no chance of resolving.
If you can't reproduce the problem with an untainted kernel, then the
problem is related to a proprietary module for which the developers can't
get the source code and thus can't realistically debug.
The fact that the taint mechanism exists is an acknowledgement of the
existence of proprietary kernel modules. The kernel developers aren't
generally averse to the existence of such modules, they just don't
consider any issues which they may cause to be their responsibility.
Reply by bbhack●November 19, 20112011-11-19
On 11/10/2011 02:53 PM, aregan wrote:
> Hi,
>
> I'm looking at the possiblity of developing a product which will use linux
> embedded but have few newbe questions. I'm a software engineer with about
> 15 years expierence, but its been a while since I've developed for linux.
>
> First question is about licensing.
> Lets say I'm building a new device that uses linux, for example its a new
> router. What versions of linux are free for me to use as my device OS.
> Must I only make available the OS source code, or must I also make
> available the source code that drives my device?
I did not see this info in a quick scan of the responses, so I may have
missed it.
A proprietary kernel module "taints" the kernel. There is nothing
technically wrong with proprietary modules except for this. RMS and
others would disagree, but whatever. Activist kernel coders can
cause their drivers to not play nice in a tainted kernel. I'm not sure
if this has ever been done.
>
> Second question
> Any suggestions on ultra low cost hardware.
> Requirements:
> 1 Lan interface port
> 1 input gpio, 1 output gpio
> Processor, ram (any. Slow / Low is fine)
> 1 audio input port, 1 audio output port
> fanless
> No vga port required other than for testing / debug.
> Must support linux. Preferably ship with linux.
>
> All advice for a novice welcomed!
>
>
>
>
> ---------------------------------------
> Posted through http://www.EmbeddedRelated.com
Reply by Anton Erasmus●November 15, 20112011-11-15
On Thu, 10 Nov 2011 14:53:05 -0600, "aregan"
<alan.regan@n_o_s_p_a_m.redkey.ie> wrote:
>Hi,
>
>I'm looking at the possiblity of developing a product which will use linux
>embedded but have few newbe questions. I'm a software engineer with about
>15 years expierence, but its been a while since I've developed for linux.
>
>First question is about licensing.
>Lets say I'm building a new device that uses linux, for example its a new
>router. What versions of linux are free for me to use as my device OS.
>Must I only make available the OS source code, or must I also make
>available the source code that drives my device?
>
>Second question
>Any suggestions on ultra low cost hardware.
>Requirements:
> 1 Lan interface port
> 1 input gpio, 1 output gpio
> Processor, ram (any. Slow / Low is fine)
> 1 audio input port, 1 audio output port
> fanless
> No vga port required other than for testing / debug.
> Must support linux. Preferably ship with linux.
>
>All advice for a novice welcomed!
>
If you get a board that has driver code for all the peripherals you
use, then your own program can be a normal user program. You can
then use whatever license you want as long as you do not use libraries
which forces you to use a specific license.
It is a fairly steep learning curve to get into embedded linux. If you
use something like Embedded Linux Development Kit from denx you
can purchase support which will help bring you up to speed MUCH
quicker.
Regards
Anton Erasmus
Reply by David Brown●November 13, 20112011-11-13
On 13/11/11 22:44, D Yuniskis wrote:
> Hi Mark,
>
> On 11/12/2011 5:22 AM, Mark Borgerson wrote:
>
>>>> This bit confuses me. Does using the standard C libraries mean that
>>>> my user mode application includes GPL's code? Or does that apply
>>>> only if I used the library sources, not the compiled libraries?
>>>
>>> RTFM http://www.gnu.org/s/hello/manual/libc/Copying.html#Copying
>>>
>>> If you use LGPL libraries and dynamic linking, then you are under
>>> section 6b and should be OK. If you modify the libraries then you must
>>> supply the changes, either as full source or as a patch file to a
>>> readily available source (usually a standard distribution).
>>
>> That's all very good if there is only one manual and there are clear
>> pointers to that manual. That hasn't been obvious until now. Perhaps
>> the real answer is "Start at gnu.org and read EVERYTHING!". By the
>> time I get from section 1a through NX to 6b, perhaps I will truly
>> comprehend the complexities of the GPL license---but don't hold
>> your breath! ;-)
>
> As a 0-th order approximation, recall the "goal" that a third party
> should be able to "replace" the portions that are thus covered.
It's not the only goal - but it is definitely one of the goals, so it's
a useful point to think about.
>
> I.e., static linking libraries means the only effective way to replace
> them is with the sources available. Dynamic linking preserves (exports)
> the entry points so the library itself can be replaced as a whole. If
> you modify the libraries, then you need some means by which that third
> party can reconstruct your modified libraries (source, diffs, etc.).
For LGPL'ed libraries, it is easiest to think that dynamic linking is
allowed to code of any license, while static linking is allowed to code
whose source is available (i.e., you can get the source, and are able
and allowed to rebuild it - thus "view only" licensed source is not good
enough). There is also the possibility of providing linkable object
code files rather than source code, or obfuscated source code (which is
allowed in a case like this, but not normally considered as "source
code" for license purposes).
>
> Not an ideal analogy but helpful when it comes to getting a feel for
> what the license (probably) wants to say (in any hypothetical situation)