The Wayback Machine was not around when the GPLv2 was written - you can't change the license because of newer technology. If you do, you get the GPLv3 - while Linux is explicitly licensed under the GPLv2.
As Nobody said, it is highly unlikely that someone will complain if you make the source available on a website rather than including the legally required written offer of the source code, but you do need to make sure you do it properly (make it easy to find the code, and provide it old versions as well as current versions).
As a 0-th order approximation, recall the "goal" that a third party should be able to "replace" the portions that are thus covered.
I.e., static linking libraries means the only effective way to replace them is with the sources available. Dynamic linking preserves (exports) the entry points so the library itself can be replaced as a whole. If you modify the libraries, then you need some means by which that third party can reconstruct your modified libraries (source, diffs, etc.).
Not an ideal analogy but helpful when it comes to getting a feel for what the license (probably) wants to say (in any hypothetical situation)
It's not the only goal - but it is definitely one of the goals, so it's a useful point to think about.
For LGPL'ed libraries, it is easiest to think that dynamic linking is allowed to code of any license, while static linking is allowed to code whose source is available (i.e., you can get the source, and are able and allowed to rebuild it - thus "view only" licensed source is not good enough). There is also the possibility of providing linkable object code files rather than source code, or obfuscated source code (which is allowed in a case like this, but not normally considered as "source code" for license purposes).
If you get a board that has driver code for all the peripherals you use, then your own program can be a normal user program. You can then use whatever license you want as long as you do not use libraries which forces you to use a specific license. It is a fairly steep learning curve to get into embedded linux. If you use something like Embedded Linux Development Kit from denx you can purchase support which will help bring you up to speed MUCH quicker.
I did not see this info in a quick scan of the responses, so I may have missed it.
A proprietary kernel module "taints" the kernel. There is nothing technically wrong with proprietary modules except for this. RMS and others would disagree, but whatever. Activist kernel coders can cause their drivers to not play nice in a tainted kernel. I'm not sure if this has ever been done.
Such a driver wouldn't be accepted into the main kernel tree.
The reason behind the taint mechanism is so that kernel developers don't waste their time dealing with bugs which they have no chance of resolving. If you can't reproduce the problem with an untainted kernel, then the problem is related to a proprietary module for which the developers can't get the source code and thus can't realistically debug.
The fact that the taint mechanism exists is an acknowledgement of the existence of proprietary kernel modules. The kernel developers aren't generally averse to the existence of such modules, they just don't consider any issues which they may cause to be their responsibility.
I mentioned it briefly in one of my replies - but it would be easy to miss in a quick scan.
Yes, there is very much something technically wrong with modules that don't use the GPLv2 - it is a breach of license to distribute such modules.
Lots of people /do/ disagree with such modules being used - you don't have to be as extreme as RMS.
But there is a grey area - modules that stick to a restricted set of API functions, and admit to "tainting" the kernel, and that have good reason for being non-GPLv2 (such as in the case of the proprietary graphics card drivers) are grudgingly tolerated by most kernel developers (lead by Torvalds) as not breaking the licences. They consider it technically wrong - but understand that it is often better for users to have a proprietary driver than no driver.
That depends upon whether they are derivative works of GPL'd code which is subject to copyright. Headers are something of a grey area, as it's legally unclear whether manifest constants, function prototypes or trivial macros are actually subject to copyright.
It is certainly the case that if you use something that is not covered by the header files (such as by putting "extern" declarations in your code to get access to non-exported data or functions), then you are creating a derivative work and need to put it under the GPL.
In most cases, using a header file without linking to the GPL'ed code directly is not considered a derivative work. Thus a normal Linux application can happily #include system headers while using whatever license it wants.
But Linux kernel modules are a special case - they are their own unique shade of grey.
In particular, it is a perfectly reasonable interpretation of the GPL to say that since modules form part of the same address space as the rest of the kernel, they are combined together (at load time) to form a single executing program. Therefore modules are a derivative work.
Also, modules are compiled for particular versions of the kernel - they are not stand-alone programs communicating through a stable and documented API (as is done for user-mode applications). This again is interpreted by many as a clear indication that they form a derivative work. It is this aspect that Nvidia et.al. work around by having a GPL'ed driver stub that communicates with the "real" driver using only a specific and limited set of functions.
Ultimately, there are three sets of interpretations of the licensing that are relevant - those of the kernel code authors, those of the module authors, and those of the courts if it ever gets challenged legally. Ethically and morally, the most important is the intention of the kernel code authors in how they want their code to be used. Opinions vary between those that only want GPL'ed modules to use their code, those that /prefer/ GPL'ed modules but accept non-GPL'ed modules, and those that don't care. Linux therefore has a system in place to allow all of these opinions (Linus Torvalds is known for his pragmatism, if not his diplomacy). Kernel code and modules can export symbols as either normal symbols, or GPLONLY symbols. Any non-GPL'ed module can only access the normal symbols - it is not allowed to access the GPLONLY symbols.
Of all the kernel developers' opinions, the most important is Linus Torvald's:
Quotation from:
Alessandro: What is your position about the availability of Linux modules in binary-only form?
Linus: I kind of accept them, but I never support them and I don't like them.
The reason I accept binary-only modules at all is that, in many cases, you have, for example, a device driver that is not written for Linux at all, but, for example, works on SCO Unix or other operating systems, and the manufacturer suddenly wakes up and notices that Linux has a larger audience than the other groups. And as a result he wants to port that driver to Linux.
But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn't feel that I had the moral right to require that it be put under the GPL, so the binary-only module interface allows those kinds of modules to exist and work with Linux.
That doesn't mean that I would accept just any kind of binary-only module: there are cases where something would be so obviously Linux-specific that it simply wouldn't make sense without the Linux kernel. In those cases, it would also obviously be a derived work, and as such the above excuses don't really apply any more, and it falls under the GPL license.
Unless the code is widely useful and passes muster with the upper eschelon of kernel devs, no one is going to pay it a thought anyway. There is virtually no possibility that your code will be debugged in a mainline kernel by anyone but you.
Here are some points. Feel free to disagree.
As a small dev with a product, no one is going to care about your source. If will never be looked at by anyone but you, unless something goes wrong.
There are many reasons to not publish source code, but almost no reasons to not publish your linux driver source. No one will ever look at it, unless there is a liability issue, and then no lawyer will ever look at it. A consultant will look at it maybe, and tell the lawyer what he wants to hear. This is a tiny possibility, and not worth the difference in outcome vs closed source, which will be subpoenaed anyway.
The term "publish" is misleading. You do not have to offer the source to anyone except those you do business with. Just because you put a GPL on some code does not mean you have to put the source on a website. It can be just between you and your customers. _They_ can put it on a website if they wish, but they will not. They will never even ask for it.
An undocumented driver interface is all the IP protection you need generally, if you feel you need it. Most small companies should spend more time marketing, and less worrying about IP security, unless of course your business is security. Then we all know the lessons about obscurity.
If any of this matters, do not start with a GPL OS.
Although no one will give your driver much thought if it is for a specific device that you make, the kernel developers /will/ look at if you ask them for help - as long as it is under the GPLv2, and follows kernel coding standards.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.