1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Newbe -Linux - licensiing & hardware

Discussion in 'Embedded' started by aregan, Nov 10, 2011.

  1. aregan

    aregan Guest

    Hi,

    I'm looking at the possiblity of developing a product which will use linu
    embedded but have few newbe questions. I'm a software engineer with abou
    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 ne
    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 mak
    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!




    ---------------------------------------
    Posted through http://www.EmbeddedRelated.com
     
    aregan, Nov 10, 2011
    #1
    1. Advertising

  2. 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.
    > Second question
    > Any suggestions on ultra low cost hardware.
    > All advice for a novice welcomed!


    A young guy and young girl came to the rabbi to ask for his advice.

    A girl:

    "Tomorrow is my first night with my fiance. What kind of night dress
    should I put on? Should it be a long dress, or a short dress, or an open
    dress, or a closed dress, or anything?"

    A boy:

    "I got some money. Will you please give me an advice what to do with it:
    maybe, invest into something, or buy some real estate, or gold, or put
    it into a bank?"

    The rabbi:

    "My dear children, I have one answer for both of you: whatever you do,
    you will be fucked"

    VLV
     
    Vladimir Vassilevsky, Nov 10, 2011
    #2
    1. Advertising

  3. aregan

    linnix Guest

    On Nov 10, 12:53 pm, "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?


    I believe the gnu license will force you to release the driver in
    source, to prevent you from making cosmetic changes and then making it
    proprietary. Especially if you adapt it from some existing drivers,
    to work with the OS. However, there is not many reason to write your
    own driver, unless you are making a new chip.

    >
    > 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!
    >


    AVR32, PIC32, PPC32, ARM32, etc.

    > ---------------------------------------
    > Posted throughhttp://www.EmbeddedRelated.com
     
    linnix, Nov 10, 2011
    #3
  4. aregan

    Tim Wescott Guest

    On Thu, 10 Nov 2011 14:53:05 -0600, 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?
    >
    > 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!


    I've never shipped a product with Linux, but I've done some research.
    So, take this with an appropriate-sized grain of salt:

    The GPL is written to cover the code you got, the code you added to it,
    and the code for anything that links in. Don't link it in, and you're
    safe. There are some issues with kernel code if you write drivers, but
    answers will be out there (I think the GPL doesn't cover dynamic linkage,
    just static -- so you can write kernel modules that link at run time.
    But _please_ check for yourself!!!).

    The LGPL is specifically written to _not_ cover the code you link in, so
    you can, for example, use an LGPL library in your code without
    'poisoning' what you've written.

    This is all out there on web pages and in books. I happen to have Doug
    Abbot's "Linux for Embedded and Real-Time Applications", but that's
    because I wanted to buy a book, he was signing books right after (or
    right before) I was at the Elsevier booth at the Embedded Systems
    Conference, and I wanted to be polite (and get a Signed Book, too!). So
    I can say that it seems to be well written and to the point (and it has a
    section on licensing), but that's about all.

    As for the hardware, I'm not sure what's "Ultra low cost" to you. Get a
    copy of (or subscribe to) Circuit Cellar magazine -- the ads are chock
    full of boards that you may want, many of which tout that they ship with
    Linux.

    --
    www.wescottdesign.com
     
    Tim Wescott, Nov 10, 2011
    #4
  5. aregan

    Les Cargill Guest

    linnix wrote:
    > On Nov 10, 12:53 pm, "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?

    >
    > I believe the gnu license will force you to release the driver in
    > source, to prevent you from making cosmetic changes and then making it
    > proprietary.



    No. You can use existing drivers unmodified or patch ( with patch files
    in your build process - like "patch driver.c < /place/patches
    /driver.c.patch" ) existing drivers.

    If you write a new driver from scratch ( or by copying an existing
    driver - same deal ) it's yours to license or not. These drivers
    can be, and are, trade secret.

    > Especially if you adapt it from some existing drivers,
    > to work with the OS. However, there is not many reason to write your
    > own driver, unless you are making a new chip.
    >


    If one exists, sure.

    >>
    >> 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!
    >>

    >
    > AVR32, PIC32, PPC32, ARM32, etc.
    >
    >> ---------------------------------------
    >> Posted throughhttp://www.EmbeddedRelated.com

    >

    --
    Les Cargill
     
    Les Cargill, Nov 11, 2011
    #5
  6. 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?


    IANAL and I would encourage you to check with a qualified IP attorney
    if you have any doubts. That said, I attended a certificate program
    on embedded Linux development last year and this is what was told to
    us.

    - You can use any version of the kernel. Check out www.kernel.org
    to see what's available. Stay away from the latest and greatest
    unless you desperately need some feature only the latest version
    provides.


    - You do not have to provide kernel source unless you modify it
    because the kernel sources are readily available. You can just
    tell your customers where to download it.

    - Similarly, you do not have to provide sources to publicly
    available GPL'd or LGPL'd libraries unless you modify them.


    - Libraries and other code licensed under LGPL are not infectious
    and do not require you to release your sources.


    - Drivers and other kernel mode code that are compiled as separate
    modules and loaded via insmod can remain proprietary unless
    they themselves include GPL'd code.


    - Drivers and other kernel mode code that are statically linked into
    the kernel are a gray legal area. The core kernel is under GPL 2
    which theoretically allows for proprietary drivers, but some
    parts of the 2.x and 3.x distributions now are under GPL 3 which is
    extremely infectious. AFAIK, there has been no definitive legal
    ruling on how (or whether) the presence of statically linked GPL 3
    code affects statically linking to the GPL 2 kernel.

    Bottom line: write your code as a module, don't statically link it
    to the kernel.


    - A user mode application can remain proprietary unless it itself
    includes GPL'd code.

    IANAL

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


    Sorry, can't help you there.


    George
     
    George Neuner, Nov 11, 2011
    #6
  7. aregan

    Dennis Guest

    On 11/11/2011 07:34 PM, Mark Borgerson wrote:
    > In article<>, gneuner2
    > @comcast.net says...
    >>
    >> 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?

    >>
    >> IANAL and I would encourage you to check with a qualified IP attorney
    >> if you have any doubts. That said, I attended a certificate program
    >> on embedded Linux development last year and this is what was told to
    >> us.
    >>
    >> - You can use any version of the kernel. Check out www.kernel.org
    >> to see what's available. Stay away from the latest and greatest
    >> unless you desperately need some feature only the latest version
    >> provides.
    >>
    >>
    >> - You do not have to provide kernel source unless you modify it
    >> because the kernel sources are readily available. You can just
    >> tell your customers where to download it.
    >>
    >> - Similarly, you do not have to provide sources to publicly
    >> available GPL'd or LGPL'd libraries unless you modify them.
    >>
    >>
    >> - Libraries and other code licensed under LGPL are not infectious
    >> and do not require you to release your sources.
    >>
    >>
    >> - Drivers and other kernel mode code that are compiled as separate
    >> modules and loaded via insmod can remain proprietary unless
    >> they themselves include GPL'd code.
    >>
    >>
    >> - Drivers and other kernel mode code that are statically linked into
    >> the kernel are a gray legal area. The core kernel is under GPL 2
    >> which theoretically allows for proprietary drivers, but some
    >> parts of the 2.x and 3.x distributions now are under GPL 3 which is
    >> extremely infectious. AFAIK, there has been no definitive legal
    >> ruling on how (or whether) the presence of statically linked GPL 3
    >> code affects statically linking to the GPL 2 kernel.
    >>
    >> Bottom line: write your code as a module, don't statically link it
    >> to the kernel.
    >>
    >>
    >> - A user mode application can remain proprietary unless it itself
    >> includes GPL'd code.
    >>

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

    >
    > <SNIP hardware stuff>
    >
    >
    > Mark Borgerson
    >
    >
     
    Dennis, Nov 11, 2011
    #7
  8. In article <>, gneuner2
    @comcast.net says...
    >
    > 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?

    >
    > IANAL and I would encourage you to check with a qualified IP attorney
    > if you have any doubts. That said, I attended a certificate program
    > on embedded Linux development last year and this is what was told to
    > us.
    >
    > - You can use any version of the kernel. Check out www.kernel.org
    > to see what's available. Stay away from the latest and greatest
    > unless you desperately need some feature only the latest version
    > provides.
    >
    >
    > - You do not have to provide kernel source unless you modify it
    > because the kernel sources are readily available. You can just
    > tell your customers where to download it.
    >
    > - Similarly, you do not have to provide sources to publicly
    > available GPL'd or LGPL'd libraries unless you modify them.
    >
    >
    > - Libraries and other code licensed under LGPL are not infectious
    > and do not require you to release your sources.
    >
    >
    > - Drivers and other kernel mode code that are compiled as separate
    > modules and loaded via insmod can remain proprietary unless
    > they themselves include GPL'd code.
    >
    >
    > - Drivers and other kernel mode code that are statically linked into
    > the kernel are a gray legal area. The core kernel is under GPL 2
    > which theoretically allows for proprietary drivers, but some
    > parts of the 2.x and 3.x distributions now are under GPL 3 which is
    > extremely infectious. AFAIK, there has been no definitive legal
    > ruling on how (or whether) the presence of statically linked GPL 3
    > code affects statically linking to the GPL 2 kernel.
    >
    > Bottom line: write your code as a module, don't statically link it
    > to the kernel.
    >
    >
    > - A user mode application can remain proprietary unless it itself
    > includes GPL'd code.
    >

    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?

    <SNIP hardware stuff>


    Mark Borgerson
     
    Mark Borgerson, Nov 12, 2011
    #8
  9. On Fri, 11 Nov 2011 17:34:02 -0800, Mark Borgerson
    <> wrote:

    >In article <>, gneuner2
    >@comcast.net says...
    >
    >> - A user mode application can remain proprietary unless it itself
    >> includes GPL'd code.
    >>

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


    The GCC C and C++ standard libraries are under LGPL, so regardless of
    how you link to them the sources for your application can remain
    proprietary.

    If you link dynamically there is no library code in your application.
    You need to supply the library binaries in your installation for
    systems that don't have them already. (Even if the system has them,
    it may not have the specific versions you used.)

    However, if you link *statically* then library code *is* in your
    application. The linker extracts from the library the code for the
    functions used by the application and copies it into the application
    executable. Note that the whole library isn't in your application,
    but only the functions you actually used and any lower level functions
    on which they depend.


    LGPL demands that you make the library available, but so long as you
    use the library "as is" and do not modify it, you can just point
    people to where they can get their own copy of its source.

    George
     
    George Neuner, Nov 12, 2011
    #9
  10. Les Cargill <> writes:

    > linnix wrote:
    >> On Nov 10, 12:53 pm, "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?

    >>
    >> I believe the gnu license will force you to release the driver in
    >> source, to prevent you from making cosmetic changes and then making it
    >> proprietary.

    >
    >
    > No. You can use existing drivers unmodified or patch ( with patch files
    > in your build process - like "patch driver.c < /place/patches
    > /driver.c.patch" ) existing drivers.
    >
    > If you write a new driver from scratch ( or by copying an existing
    > driver - same deal ) it's yours to license or not. These drivers
    > can be, and are, trade secret.


    I don't believe this is correct. If you distribute kernel binaries
    linked with your proprietary driver, the GPL requires you to release the
    source code of both the kernel and your driver.

    If the driver can be put into userspace then it is OK.

    [...]


    --

    John Devereux
     
    John Devereux, Nov 12, 2011
    #10
  11. On 2011-11-12, John Devereux <> wrote:
    > Les Cargill <> writes:
    >>
    >> No. You can use existing drivers unmodified or patch ( with patch files
    >> in your build process - like "patch driver.c < /place/patches
    >> /driver.c.patch" ) existing drivers.
    >>
    >> If you write a new driver from scratch ( or by copying an existing
    >> driver - same deal ) it's yours to license or not. These drivers
    >> can be, and are, trade secret.

    >
    > I don't believe this is correct. If you distribute kernel binaries
    > linked with your proprietary driver, the GPL requires you to release the
    > source code of both the kernel and your driver.
    >


    The last time I checked, NVIDIA seemed to get around this by having a
    open source GPL interface module between the kernel and their binary only
    driver.

    However, it's been several years since I looked at this, so I cannot
    remember the details (and more importantly what restrictions NVIDIA
    imposed on the interface module API to stop their drivers from violating
    the GPL).

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980s technology to a 21st century world
     
    Simon Clubley, Nov 12, 2011
    #11
  12. aregan

    Rich Webb Guest

    On Sat, 12 Nov 2011 01:24:09 -0500, George Neuner <>
    wrote:

    >On Fri, 11 Nov 2011 17:34:02 -0800, Mark Borgerson
    ><> wrote:
    >
    >>In article <>, gneuner2
    >>@comcast.net says...
    >>
    >>> - A user mode application can remain proprietary unless it itself
    >>> includes GPL'd code.
    >>>

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

    >
    >The GCC C and C++ standard libraries are under LGPL, so regardless of
    >how you link to them the sources for your application can remain
    >proprietary.
    >
    >If you link dynamically there is no library code in your application.
    >You need to supply the library binaries in your installation for
    >systems that don't have them already. (Even if the system has them,
    >it may not have the specific versions you used.)
    >
    >However, if you link *statically* then library code *is* in your
    >application.


    Just to expand on this for completeness, under LGPL 2.1 that statically
    linked executable falls under para 6.a (vice 6.b for dynamic linking).
    Under 6.a you must supply either the work's source code or linkable
    object code. This must allow linking with a different version of the
    LGPL library (e.g. one with bug fixes or an improved algorithm) to
    produce a working executable, providing that the API remains consistent.

    If LGPL 3 is called out, then there is effectively no change to the
    dynamic linking case, LGPL 3 para 4.d.1. However, statically linked
    executables no longer have an "out" to provide just an object module;
    para 4.d.0 requires providing at least what it terms the Minimal
    Corresponding Source in addition to the balance of the application as a
    linkable object module.

    --
    Rich Webb Norfolk, VA
     
    Rich Webb, Nov 12, 2011
    #12
  13. In article <zudvq.23753$>,
    says...
    >
    > On 11/11/2011 07:34 PM, Mark Borgerson wrote:
    > > In article<>, gneuner2
    > > @comcast.net says...
    > >>
    > >> 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?
    > >>
    > >> IANAL and I would encourage you to check with a qualified IP attorney
    > >> if you have any doubts. That said, I attended a certificate program
    > >> on embedded Linux development last year and this is what was told to
    > >> us.
    > >>
    > >> - You can use any version of the kernel. Check out www.kernel.org
    > >> to see what's available. Stay away from the latest and greatest
    > >> unless you desperately need some feature only the latest version
    > >> provides.
    > >>
    > >>
    > >> - You do not have to provide kernel source unless you modify it
    > >> because the kernel sources are readily available. You can just
    > >> tell your customers where to download it.
    > >>
    > >> - Similarly, you do not have to provide sources to publicly
    > >> available GPL'd or LGPL'd libraries unless you modify them.
    > >>
    > >>
    > >> - Libraries and other code licensed under LGPL are not infectious
    > >> and do not require you to release your sources.
    > >>
    > >>
    > >> - Drivers and other kernel mode code that are compiled as separate
    > >> modules and loaded via insmod can remain proprietary unless
    > >> they themselves include GPL'd code.
    > >>
    > >>
    > >> - Drivers and other kernel mode code that are statically linked into
    > >> the kernel are a gray legal area. The core kernel is under GPL 2
    > >> which theoretically allows for proprietary drivers, but some
    > >> parts of the 2.x and 3.x distributions now are under GPL 3 which is
    > >> extremely infectious. AFAIK, there has been no definitive legal
    > >> ruling on how (or whether) the presence of statically linked GPL 3
    > >> code affects statically linking to the GPL 2 kernel.
    > >>
    > >> Bottom line: write your code as a module, don't statically link it
    > >> to the kernel.
    > >>
    > >>
    > >> - A user mode application can remain proprietary unless it itself
    > >> includes GPL'd code.
    > >>

    > > 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! ;-)


    Mark Borgerson
     
    Mark Borgerson, Nov 12, 2011
    #13
  14. aregan

    Les Cargill Guest

    John Devereux wrote:
    > Les Cargill<> writes:
    >
    >> linnix wrote:
    >>> On Nov 10, 12:53 pm, "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?
    >>>
    >>> I believe the gnu license will force you to release the driver in
    >>> source, to prevent you from making cosmetic changes and then making it
    >>> proprietary.

    >>
    >>
    >> No. You can use existing drivers unmodified or patch ( with patch files
    >> in your build process - like "patch driver.c< /place/patches
    >> /driver.c.patch" ) existing drivers.
    >>
    >> If you write a new driver from scratch ( or by copying an existing
    >> driver - same deal ) it's yours to license or not. These drivers
    >> can be, and are, trade secret.

    >
    > I don't believe this is correct. If you distribute kernel binaries
    > linked with your proprietary driver, the GPL requires you to release the
    > source code of both the kernel and your driver.
    >


    Right. That is why you don't link ( ld ) your drivers in. You use
    insmod/rmmod/et al to make kernel loadable modules that are
    completely separate.

    > If the driver can be put into userspace then it is OK.
    >


    It's not clear to me what "into userspace" means*, but what I mean is
    using the insmod toolchain.

    *they're in both and bridge the two - that's kind of the definition
    of "driver".

    Here's a rough tutorial of what I mean:
    http://www.freesoftwaremagazine.com/articles/drivers_linux#

    To install them on startup ( it varies from distro to
    distro ) you do something like this:
    http://linuxgazette.net/issue32/tag_startup.html

    I haven't run into cases where you *have* to link
    into the kernel itself yet. IMO, treating the kernel
    as a hostile/opaque object is the better strategy,
    for licensing reasons if no other. Not having your driver
    kill the kernel is a bonus :)

    And I realize that some older distros may not offer
    insmod/rmmod et al.

    Is that clearer? Please let me know if this doesn't make
    sense.

    > [...]
    >
    >


    --
    Les Cargill
     
    Les Cargill, Nov 12, 2011
    #14
  15. aregan

    Arlet Ottens Guest

    On 11/12/2011 06:04 PM, Les Cargill wrote:
    > John Devereux wrote:
    >> Les Cargill<> writes:
    >>
    >>> linnix wrote:
    >>>> On Nov 10, 12:53 pm, "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?
    >>>>
    >>>> I believe the gnu license will force you to release the driver in
    >>>> source, to prevent you from making cosmetic changes and then making it
    >>>> proprietary.
    >>>
    >>>
    >>> No. You can use existing drivers unmodified or patch ( with patch files
    >>> in your build process - like "patch driver.c< /place/patches
    >>> /driver.c.patch" ) existing drivers.
    >>>
    >>> If you write a new driver from scratch ( or by copying an existing
    >>> driver - same deal ) it's yours to license or not. These drivers
    >>> can be, and are, trade secret.

    >>
    >> I don't believe this is correct. If you distribute kernel binaries
    >> linked with your proprietary driver, the GPL requires you to release the
    >> source code of both the kernel and your driver.
    >>

    >
    > Right. That is why you don't link ( ld ) your drivers in. You use
    > insmod/rmmod/et al to make kernel loadable modules that are
    > completely separate.
    >
    >> If the driver can be put into userspace then it is OK.
    >>

    >
    > It's not clear to me what "into userspace" means*, but what I mean is
    > using the insmod toolchain.
    >
    > *they're in both and bridge the two - that's kind of the definition
    > of "driver".
    >
    > Here's a rough tutorial of what I mean:
    > http://www.freesoftwaremagazine.com/articles/drivers_linux#
    >
    > To install them on startup ( it varies from distro to
    > distro ) you do something like this:
    > http://linuxgazette.net/issue32/tag_startup.html
    >
    > I haven't run into cases where you *have* to link
    > into the kernel itself yet. IMO, treating the kernel
    > as a hostile/opaque object is the better strategy,
    > for licensing reasons if no other. Not having your driver
    > kill the kernel is a bonus :)
    >
    > And I realize that some older distros may not offer
    > insmod/rmmod et al.


    insmod is a form of run-time linking into the kernel.
     
    Arlet Ottens, Nov 12, 2011
    #15
  16. aregan

    linnix Guest


    > And I realize that some older distros may not offer
    > insmod/rmmod et al.
    >


    Modules are in 2.2, 2,4 and 2.6. Perhaps not in 2.0. But you can't
    do much with 2.0 anyway. If you want WiFi (like we do), you are stuck
    with 2.6 anyway. A basic WiFi networking kernel is over 10M bytes;
    so, start dealing with DRAM, BGA and muti-layer PCB.
     
    linnix, Nov 12, 2011
    #16
  17. aregan

    Nobody Guest

    On Fri, 11 Nov 2011 00:09:27 -0500, George Neuner wrote:

    > - You do not have to provide kernel source unless you modify it
    > because the kernel sources are readily available. You can just
    > tell your customers where to download it.


    While few people will complain if you do this, it isn't actually permitted
    by GPL-v2 (which is what the Linux kernel uses). You must either provide
    the source code, or provide a written offer (valid for at least three
    years) to provide the source code upon request (for which you may charge
    reasonable expenses).

    The main reason why you can't just refer your customers to whereever you
    got the source from is that the site could simply disappear without
    notice, or it might cease hosting the particular version when a newer
    version becomes available. Ultimately, the responsibility for providing
    the source rests with the person or entity providing the binaries, and
    cannot be involuntarily forced onto a third party.

    Provided that you include a written offer to supply the source code on
    demand (and can actually make good on that offer if necessary), you've
    satisfied the terms of the licence. If the code in question happens to be
    available via a third-party download site, the odds of anyone actually
    requesting the source directly from you are slim.

    With GPL-v3, you have the option of pointing people to a third-party
    server, provided that it is accessible at no charge. However, you need to
    bear in mind that if the server ceases to become available or ceases
    hosting the code in question, you would need to make alternative
    arrangements in order to continue to legally distribute the binaries.
     
    Nobody, Nov 13, 2011
    #17
  18. aregan

    David Brown Guest

    On 10/11/11 21:53, 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.


    Linux itself is cost-free. But there are some vendors that charge for
    additional software or services - it is always obvious from their
    websites whether the charges are for development tools, support,
    additional software, etc., and whether it is fees for development or
    royalties in deployment. Then it's up to you to decide if it's worth
    the money.

    > Must I only make available the OS source code, or must I also make
    > available the source code that drives my device?
    >


    The Linux kernel is covered by the GPLv2, with the express intention (as
    stated by Linux Torvalds and supported by other authors) that the source
    code to the OS must be open, but you can use any license you want for
    independent user-mode programs.


    So your own user-mode applications can be closed-source, unless of
    course they use other open source software or libraries contrary to
    their licence. But you'd have to look at the licence for the libraries
    for that information. You are certainly free to use Linux system
    headers and system calls without it affecting your code license.

    Any changes you make to the kernel code itself, including the drivers
    that come with it, are covered by the GPLv2, and you need to provide the
    source code (someone else posted an explanation of what that means).


    The only area the seems to confuse people is drivers that are not
    compiled as part of the Linux kernel, but as separate installable
    modules. There is a bit of a grey area here.

    If you use the kernel headers and system calls that are necessary for
    writing a full driver, then your code is covered by the GPLv2. This
    applies regardless of whether the linking is done at build time, or at
    run time (i.e., a loadable module). Thus all proper drivers in Linux
    are covered by the GPLv2 - even if you write one from scratch, compile
    it separately, and only install it at run time.


    There is a small loophole, however, as used by Nvidia and ATI for their
    graphics card drivers. These are built in two halves - there is a
    GPL'ed part that is built as a proper module. This communicates with a
    proprietary closed-source part via a limited interface. The
    closed-source part can't use any of the kernel driver specific APIs or
    headers that are covered by pure GPLv2. It is awkward and inconvenient,
    it is much more work to split the code like this, debugging is harder,
    and the Linux developers consider the kernel "tainted" by this approach
    - you will get much less support or help with it. It has never been
    clearly decided if it is a violation of the GPL - but Linus Torvalds has
    taken the pragmatic approach that he doesn't like it, doesn't approve of
    it, but will close his eyes to it in situations like the graphics
    drivers as it lets the graphics developers use the same driver code on
    Linux and Windows.


    If you want your project to succeed, you need help. You need to be part
    of the community, and work with Linux kernel and driver developers.
    They are always happy to help as long as you play by their rules - and
    that means everything in the kernel and kernel space, including all
    drivers, should be GPLv2.

    Anything closed-source should be user-mode application space code.
     
    David Brown, Nov 13, 2011
    #18
  19. Les Cargill <> writes:

    > John Devereux wrote:
    >> Les Cargill<> writes:
    >>
    >>> linnix wrote:
    >>>> On Nov 10, 12:53 pm, "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?
    >>>>
    >>>> I believe the gnu license will force you to release the driver in
    >>>> source, to prevent you from making cosmetic changes and then making it
    >>>> proprietary.
    >>>
    >>>
    >>> No. You can use existing drivers unmodified or patch ( with patch files
    >>> in your build process - like "patch driver.c< /place/patches
    >>> /driver.c.patch" ) existing drivers.
    >>>
    >>> If you write a new driver from scratch ( or by copying an existing
    >>> driver - same deal ) it's yours to license or not. These drivers
    >>> can be, and are, trade secret.

    >>
    >> I don't believe this is correct. If you distribute kernel binaries
    >> linked with your proprietary driver, the GPL requires you to release the
    >> source code of both the kernel and your driver.
    >>

    >
    > Right. That is why you don't link ( ld ) your drivers in. You use
    > insmod/rmmod/et al to make kernel loadable modules that are
    > completely separate.


    I don't think this makes any difference (David Brown provided a more
    complete explanation).

    >> If the driver can be put into userspace then it is OK.
    >>

    >
    > It's not clear to me what "into userspace" means*, but what I mean is
    > using the insmod toolchain.
    > *they're in both and bridge the two - that's kind of the definition
    > of "driver".


    Yes, and I think the GPL2 would apply to them. An exception would be
    something like an instrument driver that communicated via a serial
    port. This could be written to only use filesystem calls and would not
    be subject to the GPL.

    > Here's a rough tutorial of what I mean:
    > http://www.freesoftwaremagazine.com/articles/drivers_linux#
    >
    > To install them on startup ( it varies from distro to
    > distro ) you do something like this:
    > http://linuxgazette.net/issue32/tag_startup.html
    >
    > I haven't run into cases where you *have* to link
    > into the kernel itself yet. IMO, treating the kernel
    > as a hostile/opaque object is the better strategy,
    > for licensing reasons if no other. Not having your driver
    > kill the kernel is a bonus :)
    >
    > And I realize that some older distros may not offer
    > insmod/rmmod et al.
    >
    > Is that clearer? Please let me know if this doesn't make
    > sense.



    --

    John Devereux
     
    John Devereux, Nov 13, 2011
    #19
  20. aregan

    David Brown Guest

    On 13/11/11 16:53, John Devereux wrote:
    > Les Cargill<> writes:
    >
    >> John Devereux wrote:
    >>> Les Cargill<> writes:
    >>>
    >>>> linnix wrote:
    >>>>> On Nov 10, 12:53 pm, "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?
    >>>>>
    >>>>> I believe the gnu license will force you to release the driver in
    >>>>> source, to prevent you from making cosmetic changes and then making it
    >>>>> proprietary.
    >>>>
    >>>>
    >>>> No. You can use existing drivers unmodified or patch ( with patch files
    >>>> in your build process - like "patch driver.c< /place/patches
    >>>> /driver.c.patch" ) existing drivers.
    >>>>
    >>>> If you write a new driver from scratch ( or by copying an existing
    >>>> driver - same deal ) it's yours to license or not. These drivers
    >>>> can be, and are, trade secret.
    >>>
    >>> I don't believe this is correct. If you distribute kernel binaries
    >>> linked with your proprietary driver, the GPL requires you to release the
    >>> source code of both the kernel and your driver.
    >>>

    >>
    >> Right. That is why you don't link ( ld ) your drivers in. You use
    >> insmod/rmmod/et al to make kernel loadable modules that are
    >> completely separate.

    >
    > I don't think this makes any difference (David Brown provided a more
    > complete explanation).
    >


    Correct.

    To use the driver APIs and system calls, you need to use header files
    from the kernel that are under pure GPLv2 (most of the other headers are
    exempt from the GPL, so that you can use them in non-GPL code). The way
    the GPL works, and the way C works, you are using the copyrighted code
    as part of your code - so you have to follow the license, or not use the
    code. Linking the driver code at run time as a loadable module is also
    considered making a "derivative work" in this case (note that linking to
    shared library modules at load time is a different matter). Either
    accept Linux and the GPL's rules for writing your drivers, or use a
    different OS.

    It's not really any different from other software. If you want to use
    Embedded Windows or something else as your OS, you accept the rules of
    that software (such as paying royalties, agreeing not to sue the
    software developers, and whatever other rules they make).

    >>> If the driver can be put into userspace then it is OK.
    >>>

    >>
    >> It's not clear to me what "into userspace" means*, but what I mean is
    >> using the insmod toolchain.
    >> *they're in both and bridge the two - that's kind of the definition
    >> of "driver".

    >
    > Yes, and I think the GPL2 would apply to them. An exception would be
    > something like an instrument driver that communicated via a serial
    > port. This could be written to only use filesystem calls and would not
    > be subject to the GPL.
    >


    Correct - such software is not a "driver" in the sense of a Linux kernel
    driver. It's a user-space application or library, and you can use the
    license you like. The same applies to things like USB "drivers" that
    use libusb access, or filesystems that use FUSE for the interface
    (that's how the ZFS port for Linux works, since the ZFS code is not
    under the GPL and can't be included directly in the kernel).
     
    David Brown, Nov 13, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. .:: Fast Niko ::.
    Replies:
    0
    Views:
    449
    .:: Fast Niko ::.
    May 15, 2005
  2. Lockar
    Replies:
    0
    Views:
    840
    Lockar
    Jan 6, 2006
  3. Hans-Dominik

    Newbe Crosscompile a ModuleDriver for arm

    Hans-Dominik, Mar 6, 2005, in forum: Embedded
    Replies:
    3
    Views:
    258
    Ulf Samuelsson
    Mar 7, 2005
  4. Nick Hogg

    Re: newbe ? overclocking gateway

    Nick Hogg, Aug 22, 2003, in forum: Overclocking
    Replies:
    2
    Views:
    286
  5. Recommend newbe hardware

    , Sep 10, 2007, in forum: Sun Hardware
    Replies:
    8
    Views:
    322
    Josh McKee
    Sep 13, 2007
Loading...

Share This Page