Newbe -Linux - licensiing & hardware

x

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.

AVR32, PIC32, PPC32, ARM32, etc.

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

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.

If one exists, sure.

-- Les Cargill

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

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

Sorry, can't help you there.

George

RTFM

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

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?

Mark Borgerson

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

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

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

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

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

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.

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:

To install them on startup ( it varies from distro to distro ) you do something like this:

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

insmod is a form of run-time linking into the kernel.

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.

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.

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.

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.

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

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.

--

John Devereux

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

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

[all correct reasoning snipped]

However, with the availability of services like Wayback Machine isn't this point moot in practice?

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/