Em 12/11/2011 23:06, Nobody escreveu:> 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). >[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/
Newbe -Linux - licensiing & hardware
Started by ●November 10, 2011
Reply by ●November 13, 20112011-11-13
Reply by ●November 13, 20112011-11-13
On 13/11/11 19:28, Cesar Rabak wrote:> Em 12/11/2011 23:06, Nobody escreveu: >> 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). >> > [all correct reasoning snipped] > > However, with the availability of services like Wayback Machine isn't > this point moot in practice? >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).
Reply by ●November 13, 20112011-11-13
Hi Mark, On 11/12/2011 5:22 AM, Mark Borgerson wrote:>>> 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! ;-)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)
Reply by ●November 13, 20112011-11-13
On 13/11/11 22:44, D Yuniskis wrote:> Hi Mark, > > On 11/12/2011 5:22 AM, Mark Borgerson wrote: > >>>> 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! ;-) > > As a 0-th order approximation, recall the "goal" that a third party > should be able to "replace" the portions that are thus covered.It's not the only goal - but it is definitely one of the goals, so it's a useful point to think about.> > 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.).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).> > 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)
Reply by ●November 15, 20112011-11-15
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? > >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! >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. Regards Anton Erasmus
Reply by ●November 19, 20112011-11-19
On 11/10/2011 02:53 PM, 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?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.> > 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
Reply by ●November 20, 20112011-11-20
On Sat, 19 Nov 2011 21:36:11 -0600, bbhack wrote:> 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.
Reply by ●November 20, 20112011-11-20
On 20/11/11 04:36, bbhack wrote:> On 11/10/2011 02:53 PM, 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? > > I did not see this info in a quick scan of the responses, so I may have > missed it. >I mentioned it briefly in one of my replies - but it would be easy to miss in a quick scan.> 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.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.> 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. >
Reply by ●November 20, 20112011-11-20
On Sun, 20 Nov 2011 19:06:35 +0100, David Brown wrote:> 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.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.
Reply by ●November 21, 20112011-11-21
On 20/11/2011 21:50, Nobody wrote:> On Sun, 20 Nov 2011 19:06:35 +0100, David Brown wrote: > >> 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. > > 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. >That's true enough. 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: <http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html> 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.
