Linux Drivers Part of Kernel for GPL?

On 8/5/2015 10:09 AM, Grant Edwards wrote:
> On 2015-08-05, rickman <gnuarm@gmail.com> wrote:
>> When a product is shipped which uses Linux internally, are the various
>> drivers required to control the hardware part of the Kernel as far as
>> GPL goes?
>
> If they are dynamically loaded at run-time and use only "standard"
> kernel APIs, the answer is "no".  If the drivers are statically linked
> into the kernel before it is shipped the answer is "yes".  At least
> that's what Linus and the kernel maintainers intend.  IMO, you should
> respect those intentions regardles of what lawyers say.
>
>> I'm wondering how much of the product has to be opened up and provided
>> to a user on request?
>
> If you link it in with the kernel before you ship it, you should offer
> source code for it.  If it's a module that's dynamically loaded module
> run-time (e.g. with "modprobe"), you probably don't have to.

This is the best answer so far.  So hardware drivers can be loaded at 
run time and do not need to be part of the kernel?  For all practical 
purposes then a device using Linux can be released that can not be 
re-purposed because the drivers are not GPL and there may be no data 
sheet on the hardware.

-- 

Rick

On 05.8.2015 г. 18:39, rickman wrote:
> On 8/5/2015 9:59 AM, Dimiter_Popoff wrote:
>> On 05.8.2015 г. 05:53, rickman wrote:
>>> ...
>>>
>>> I was not clear in my question.  I am not looking to build such a
>>> product, I am considering what parts of products I might buy can be
>>> locked away.
>>>
>>> Specifically, someone said about an embedded product, "Yes, I heard that
>>> it always was on some form of Linux, but AFAIK its some secret
>>> proprietary flavour."  I'm trying to understand what that might mean.
>>
>> Practically they can hide all they want to. Just try to get hold of
>> the data on how to talk to a wifi chipset - most if not all
>> are "supported" under linux but secretly.
>> I have never tried to go into the legal bullshit of it as the
>> practical side is quite clear - you are not allowed access to the
>> data unless you are a politburo member (i.e. Google, MS etc.).
>
> That "secrecy" is what I'm trying to understand.  If it is under the GPL
> there are *no* secrets.  The data sheet for the part may be secret, but
> not the driver unless they somehow make it a separate executable which
> is what I am asking about.
>

I get what you are after, I have spent some time chasing wifi
documentation.
In my experience it is a waste of time trying to obtain data
they want to keep secret. They call the files "binaries" which you
need on your linux machine in order for the peripheral to work
and that's that. If you cannot locate the data you need in a few
hours of search (minute may be even more realistic)  I think investing
more time into it will be just a waste.
But then it's been a while since I learned this lesson the hard
way, may be you will fare better than I did.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On Tue, 04 Aug 2015 21:15:42 -0400, rickman wrote:

> When a product is shipped which uses Linux internally, are the various
> drivers required to control the hardware part of the Kernel as far as
> GPL goes?
> 
> I'm wondering how much of the product has to be opened up and provided
> to a user on request?

Most books on using Linux for embedded development cover this sort of 
licensing issue.  There are scads of proprietary drivers for proprietary 
hardware in the desktop Linux world, so presumably if you want to develop 
a system you can make everything except for the core Linux part of it 
closed.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

rickman <gnuarm@gmail.com> wrote:

(snip on GPL, linux, and what source has to be released)

>> If they are dynamically loaded at run-time and use only "standard"
>> kernel APIs, the answer is "no".  If the drivers are statically linked
>> into the kernel before it is shipped the answer is "yes".  At least
>> that's what Linus and the kernel maintainers intend.  IMO, you should
>> respect those intentions regardles of what lawyers say.

But rickman is asking the opposite question. He wants to know
what they have to release to him.

>>> I'm wondering how much of the product has to be opened up 
>>> and provided to a user on request?

>> If you link it in with the kernel before you ship it, you should offer
>> source code for it.  If it's a module that's dynamically loaded module
>> run-time (e.g. with "modprobe"), you probably don't have to.
 
> This is the best answer so far.  So hardware drivers can be loaded at 
> run time and do not need to be part of the kernel?  For all practical 
> purposes then a device using Linux can be released that can not be 
> re-purposed because the drivers are not GPL and there may be no data 
> sheet on the hardware.

I am not so sure how that matches with the "mere aggregation"
that I remember from GPL. If it is, for example, in the same ROM
(more likely flash), even if it isn't loaded until later, it seems
more than mere aggregation to me.

-- glen

Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Tue, 04 Aug 2015 21:15:42 -0400, rickman wrote:
(snip) 
>> I'm wondering how much of the product has to be opened up and provided
>> to a user on request?
 
> Most books on using Linux for embedded development cover this sort of 
> licensing issue.  There are scads of proprietary drivers for proprietary 
> hardware in the desktop Linux world, so presumably if you want to develop 
> a system you can make everything except for the core Linux part of it 
> closed.

If you are distributing a device, along with its drivers, for someone
to use with Linux, that sounds right to me.

If you distribute a device with Linux in ROM, along with the drivers,
it seems to me a different case. Even if the drivers are dynamically
loaded from ROM. 

Then again, IANAL.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> I am not so sure how that matches with the "mere aggregation"
> that I remember from GPL. If it is, for example, in the same ROM
> (more likely flash), even if it isn't loaded until later, it seems
> more than mere aggregation to me.

I think the Linux kernel developers have chosen to be less strict about
mixed use than the GPL potentially requires.  I believe the FSF is
somewhat more strict, regarding things like GCC plug-ins.  Disclaimers:
IANAL, I'm not speaking for anyone else, etc.

Paul Rubin <no.email@nospam.invalid> wrote:

(snip, I wrote)
>> I am not so sure how that matches with the "mere aggregation"
>> that I remember from GPL. If it is, for example, in the same ROM
>> (more likely flash), even if it isn't loaded until later, it seems
>> more than mere aggregation to me.
 
> I think the Linux kernel developers have chosen to be less strict about
> mixed use than the GPL potentially requires.  I believe the FSF is
> somewhat more strict, regarding things like GCC plug-ins.  Disclaimers:
> IANAL, I'm not speaking for anyone else, etc.

I didn't know they had that choice. 

Well, IANAL either, but as far as I know rickman, following GPL,
is allowed to ask the driver developers and distributors
for the source.

He doesn't have to ask the kernel developers. 

But on the other hand, and again IANAL, that leaves it up to
rickman to sue, where he might not be in a position to do that.
The kernel developers might be in a better position to sue,
but choose not to. He might be able sue for his loss only.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> I think the Linux kernel developers have chosen to be less strict
> I didn't know they had that choice. 

They are the copyright holders and as such, they can decide when and
when not to enforce the license.

> But on the other hand, and again IANAL, that leaves it up to
> rickman to sue, where he might not be in a position to do that.
> The kernel developers might be in a better position to sue,
> but choose not to. He might be able sue for his loss only.

Rickman would not have standing either way AFAIK.  Only the copyright
holder can do that.  The Software Freedom Conservancy has done some GPL
enforcement work on behalf of Linux kernel contributors, see:

  http://sfconservancy.org/linux-compliance/

but I don't know who else (if anyone) does it.

Grant Edwards wrote:
> On 2015-08-05, rickman <gnuarm@gmail.com> wrote:
>> When a product is shipped which uses Linux internally, are the various
>> drivers required to control the hardware part of the Kernel as far as
>> GPL goes?
>
> If they are dynamically loaded at run-time and use only "standard"
> kernel APIs, the answer is "no".  If the drivers are statically linked
> into the kernel before it is shipped the answer is "yes".  At least
> that's what Linus and the kernel maintainers intend.  IMO, you should
> respect those intentions regardles of what lawyers say.
>
>> I'm wondering how much of the product has to be opened up and provided
>> to a user on request?
>
> If you link it in with the kernel before you ship it, you should offer
> source code for it.  If it's a module that's dynamically loaded module
> run-time (e.g. with "modprobe"), you probably don't have to.
>


Linus says you still have to. But Linus is mainly interested in
making available the things kernel maintainers need to maintain the kernel.

-- 
Les Cargill

rickman wrote:
> On 8/5/2015 8:56 AM, Les Cargill wrote:
>> rickman wrote:
>>> On 8/5/2015 12:15 AM, Les Cargill wrote:
>>>> rickman wrote:
>>>>> On 8/4/2015 10:25 PM, Les Cargill wrote:
>>>>>> rickman wrote:
>>>>>>> When a product is shipped which uses Linux internally, are the
>>>>>>> various
>>>>>>> drivers required to control the hardware part of the Kernel as
>>>>>>> far as
>>>>>>> GPL goes?
>>>>>>>
>>>>>>
>>>>>> This post is not legal advice and is only intended as a guide
>>>>>> and may be radically in error. Caveat reador.
>>>>>>
>>>>>> Here is what Linus has to say on the subject:
>>>>>>
>>>>>> http://yarchive.net/comp/linux/gpl_modules.html
>>>>>>
>>>>>> You may be able to minimize the kernel loadable modules
>>>>>> to have no proprietary information and use a middle layer
>>>>>> for that, which is in user space.
>>>>>>
>>>>>> For example, Total Phase makes a USB CAN interface - the Komodo -
>>>>>> that uses a binary-only .so for the interface - the only drivers
>>>>>> needed are the stock USB drivers.
>>>>>>
>>>>>> Chances are you can do the same - you can leverage existing SPI and
>>>>>> I2C drivers, USB, what have you. There are others; drives for Linux
>>>>>> are numerous.
>>>>>>
>>>>>> Chances are you can do same unless you have some bizarre
>>>>>> hardware interface. And in that case, simply implement it with some
>>>>>> other "operating system" first, then port to Linux.
>>>>>
>>>>> I was not clear in my question.
>>>>
>>>> Sorry - I *ASS*umed you were posting from the role as a developer. :)
>>>>
>>>>    I am not looking to build such a
>>>>> product, I am considering what parts of products I might buy can be
>>>>> locked away.
>>>>>
>>>>> Specifically, someone said about an embedded product, "Yes, I heard
>>>>> that
>>>>> it always was on some form of Linux, but AFAIK its some secret
>>>>> proprietary flavour."  I'm trying to understand what that might mean.
>>>>>
>>>>
>>>> It's hard to say what that means. If you're a customer, you'd then need
>>>> to make sure there's an escrow plan to make sure you're not stuck. That
>>>> might be as simple as a .iso of a FLASH image.
>>>>
>>>> There's not a compelling reason not to use a stock distro ( the one
>>>> that
>>>> comes with your eval board is an excellent choice ) for
>>>> embedded and then add custom startup and kernel loadable modules.
>>>
>>> I'm talking about products that have Linux in them, not hardware for
>>> engineering.  The actual example is the many sat navs running Linux or
>>> in my case the Internet TV box which I found contains a GPL notice after
>>> I dug around in the menus.  I think the other guy I was talking to was
>>> suggesting they made a special version of Linux and kept parts "secret"
>>> to prevent cloning or something.
>>>
>>
>> I dunno then. These are what they are. Settop boxes are leased items;
>> the satnav is what it is.
>
> Yes, I believe that most things "are what they are".
>

So are you talking about a cable box, or an Internet TV adapter like
  a ROKU or what ?

For those things, hacking* them is not likely interesting. I presume you 
can reflash them  with binaries from the vendor.

*people do, but not for maintenance reasons.


>
>> These things are adapters for A Service, and are not products in and of
>> themselves.
>
> Ok, but I don't see how that is relevant.

It's relevant if your demark is the HDMI or Ethernet interface.

> I bought an item that has
> embedded software.  Some of that software is proprietary and I have to
> agree to a EULA.  Other software in that product is FOSS and they give
> me a copy of the GPL.  I'm asking how much of the software required to
> run the Linux OS is GPL and how much can be proprietary.
>

1) User space can always be proprietary. No GPL needed.
2) The kernel is not proprietary and yes GPL.
3) Drivers may or may not need to be GPL. It depends
on who you ask. Linus says anything that runs in kernel
space is GPL.

On 3) -  I know, right?

> Someone has pointed out that some of the drivers can be proprietary if
> they jump through the right hoops.
>
>

Right.

>>>>>>> I'm wondering how much of the product has to be opened up and
>>>>>>> provided
>>>>>>> to a user on request?
>>>>>>>
>>>>>>
>>>>>> None of it, SFAIK. It's not between you and them, it's between you
>>>>>> and
>>>>>> the Linux kernel community. They're not party to that relationship.
>>>>>>
>>>>>> If nothing else, declare it trade secret.
>>>>>
>>>>> I don't think you can make it a trade secret if it is covered by the
>>>>> GPL.
>>>>
>>>> Yeah, it's weird. You can have trade secret in opaque blobs. It's a bit
>>>> rude, but it's doable.
>>>
>>> Even then it is hard to make practical.  A trade secret is only useful
>>> as long as you can keep it secret.  You can reverse engineer to get
>>> around a trade secret.  In the US the right to reverse engineer can be
>>> licensed away.  In the EU it is protected by law.
>>>
>>>
>>
>> It's expensive.
>>
>>>>> Doesn't that require that anyone in possession of the code be able
>>>>> to share it freely?
>>>>
>>>> I am no expert on the details of GPL compliance.
>>>>
>>>>>  Or am I mistaken about this and it only requires
>>>>> that source be available with the executable?
>>>>>
>>>>
>>>> https://softwarefreedom.org/resources/2008/compliance-guide.html
>>>
>>> Good link.  Relatively easy to read.
>>>
>>> "Second, note that the last line makes the offer valid to anyone who
>>> requests the source. This is because v2 � 3(b) requires that offers be
>>> �to give any third party� a copy of the Corresponding Source."
>>>
>>> So I am free to distribute the GPL source without the authors having a
>>> grievance.
>>>
>>
>> That, I am completely unsure of. There's a formal-trust issue in that
>> case. What is your provenance for the thing being delivered?
>
> Not sure what you are asking.  Are you asking if I bought the product or
> if I am selling it or what?  I believe according to the GPL it is
> irrelevant.
>

So how does somebody who gets a copy of the GPL-ed code from you know 
it's the same? You'd need MDA signatures and such.

-- 
Les Cargill