Newbe -Linux - licensiing & hardware

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.

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.

On 21/11/11 18:14, bbhack wrote:
> 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.