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? -- Rick
Linux Drivers Part of Kernel for GPL?
Started by ●August 4, 2015
Reply by ●August 4, 20152015-08-04
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'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. You should get whoever your corporate counsel is to help you design a written policy because you shouldn't take legal advice from Usenet. -- Les Cargill
Reply by ●August 4, 20152015-08-04
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. 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.>> 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. Doesn't that require that anyone in possession of the code be able to share it freely? Or am I mistaken about this and it only requires that source be available with the executable? -- Rick
Reply by ●August 5, 20152015-08-05
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 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.> 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 -- Les Cargill
Reply by ●August 5, 20152015-08-05
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'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.>> 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.htmlGood 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. -- Rick
Reply by ●August 5, 20152015-08-05
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. These things are adapters for A Service, and are not products in and of themselves.> >>>>> 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? -- Les Cargill
Reply by ●August 5, 20152015-08-05
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.). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●August 5, 20152015-08-05
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. -- Grant Edwards grant.b.edwards Yow! I want my nose in at lights! gmail.com
Reply by ●August 5, 20152015-08-05
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".> 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. 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. Someone has pointed out that some of the drivers can be proprietary if they jump through the right hoops.>>>>>> 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. -- Rick
Reply by ●August 5, 20152015-08-05
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. -- Rick
