Linux in a product

As an engineer, yes. A plugin is not simply loaded in the same manner as a document. A document is simply parsed - no subroutine call is made into code in the document. By subroutine call the GPL recognises only machine language calling, not interpreting scripts. Simple loading of an image into does not 'link' into that image. However, when the image them gets 'executed' by the CPU, it must be done somehow by a subroutine call even if it is indirectly by function pointers. The GPL classifies this as linking, in this case dynamic linking. A plugin is simply a library/dll that the programs first checks if it exists before linking. Unlike hardcoded libraries the program still works even if the plugin doesn't exist. The program doesn't even need to know in advance the names of the plugin since it knows where all plugins are located and simply scan through the directory.

This situation is just a bit more complicated if we are talking about intrepreted languages. But that's another story..

Note that if you read GPL carefully there is a workaround for people like me who still want to use GPL'd code in a commercial product without making my own code GPL. Simply write another simple wrapper application which acts as a 'server' of the GPL functions. This simple application can harmlessly be GPL'd since it doesn't contain any business logic. Then connect the two via external means: pipes, TCP/IP, RPC, mailboxes, etc.. On a good operating system with very fast messaging such as QNX, this is almost as good as calling the function directly.

I'm sure the "workaround" is intentional. Unlike Microsoft's loud proclamations, GPL is not a "virus" against intellectual property rights and was never intended to be. As a paying, attending member of the FSF, I can say I'm sure this is a correct statement. Also, it's not that the GPL means to be difficult to deal with, but true problems of misuse do require a certain level of discipline. So, go in peace, and we can all hope, make your serious money using GPL.

--
 Thanks,
    - Win

;-) The company I work for provides mobile-IP solutions accross GSM, GPRS and 3G networks. China Telecom is one of our biggest clients. So we are making serious money using GPL... And I've just sold my IPO for half a year's slalry :-)

Read GPL & it's accompanying FAQ:

Especially the following FAQ s:

Q: If a program released under the GPL uses plug-ins, what are the requirements for the licenses of a plug-in. A: It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed. If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case.

Q: Can I apply the GPL when writing a plug-in for a non-free program? A: If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license for the main program makes no requirements for them. So you can use the GPL for a plug-in, and there are no special requirements. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means that combination of the GPL-covered plug-in with the non-free main program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in's license, giving permission to link it with the non-free main program. See also the question I am writing free software that uses a non-free library.

Q: Can I release a non-free program that's designed to load a GPL-covered plug-in? A: It depends on how the program invokes its plug-ins. If the program uses fork and exec to invoke plug-ins, then the plug-ins are separate programs, so the license of the plug-in makes no requirements about the main program. If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. In order to use the GPL-covered plug-ins, the main program must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when the main program is distributed for use with these plug-ins. If the program dynamically links plug-ins, but the communication between them is limited to invoking the `main' function of the plug-in with some options and waiting for it to return, that is a borderline case. See also the question I am writing free software that uses a non-free library.

Finally, Ian, if you think these conditions are absurd, then the GPL has it covered:

1. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

note the "You are not required to accept this License" part.

So, can you loan me a couple grand until one of my inventions takes off?

Thanks! Rich

[if you want to contact me by email, it's richgrise at yahoo * com, if you know what I mean. :-) ]

Actually, the GPL is truly meant to be a viral license that adds redistribution encumberances to derived binaries of the actual GPLed codebase. Some people might get confused that distributing a GPLed work (e.g. Linux kernel binaries) doesn't usually enucumber binaries (user programs) that haven't been LINKED (statically or dynamically) with GPLed libraries that aren't normally distributed with an OS (e.g. GPLed libraries.) The GPL is definitely somewhat viral WRT intellectual property, but that is one of the goals (so that source code of derived works must be made available to those who are given (or receive) binaries.) Theoretically, this allows those who receive the binaries to support the application themselves.

So, for the GPLed work itself (e.g. Linux kernel -- even though it uses a special modification of GPL) it does potentially encumber works that are linked directly in with the kernel (or other GPLed work.) It is important for those who work with GPLed codebases to decide A-PRIORI that they will be offering to distribute source code to those who will receive binaries. On the other hand, FREE software (in the common-sense way) doesn't encumber new, add-on intellectual property with pre-ordained license terms. Public domain and BSD licenses do NOT encumber the distribution of binaries by requiring a bona fide offer of source code (like the true GPL.) The biggest encumberance of 'free' software is the provenance so that the license terms can be discerned (the author/owner of the free software asserts copyright and describest the free license terms.)

In all cases of binary encumbered open source (e.g. GPL), free open source (BSD license) or public domain, NONE of these schemes guarantee the future availability of source code. Just because someone is a distributor of a GPLed codebase that they offer to distribute for a price (often by an outrageous support fee), they don't necessarily have to give a copy of that GPLed work to anyone on the street who ask for it.

Generally, those people who have a RIGHT to a GPL source code distribution are those who have been given the binaries. The distributor of the binaries must provide a bona fide offer of the exact sources or perhaps give a pointer to a mainstream distribution site that has exactly the correct version of the code.

Using the GPL does require understanding the license terms and the effects of the encumberance of the binaries. It is important to truly understand the GPL, and it is definitely more complicated than a simple license of free software (with no/few distribution encumberances.)

One can make money using a GPLed codebase very similarly to making money using software with a commercial license. There is very little difference between USING the GNU C compiler and using the Microsoft C complier WRT the distribution terms of the generated code. If one uses GPLed works directly in an embedded product (instead of just as a development tool), then the intellectual property that is directly linked in with the GPLed works might (depending upon the kind of GPL -- the pure one or the Linux one) require a bona fide offer to give away the source code of the intellectual property to those who receive binaries. The Linux kernel GPL is a little different than true GPL, and has a higher probability of being able to keep hard earned intellectual property private. (But the IP at risk is that which is added DIRECTLY into the kernel, and not normal application code.)

The Linux kernel DOES NOT generally encumber a program that runs as an application, but GPLed libraries that might be linked wtih the application MIGHT encumber that application. There are specific kinds of relief of certain aspects of GPL encumberance for certain libraries (e.g. those that normally reside with the specific distribution that you are using.)

On the other hand, free software (e.g. BSDLed software) tends not to create binary encumberances -- but generally BSDLed OSes tend to depend upon GPLed tools for DEVELOPMENT. The advantage for embedded applications is that the OS kernel (and libraries) are also generally BSDLed, and don't risk the GPL encumberances for the RUNTIME -- either in the kernel or in userland.

In a way, the simplification caused by the BSDL is not as good as one might initially believe, because most BSDLed systems do tend to continue to have *some* dependency on GPLed codebases. There is often a possibility to totally eliminate GPLed code in the runtime version of a codebase, and then any intellectual property that might have to be merged directly into the OS (or otherwise be linked with a GPLed codebase) will not be put at risk of distribution requirements.

As long as the Linux kernel is used as a black box, the GNU compilers are used similarly to commercial compilers, and no significant mods are máde to the portions of the GPLed codebase that might be distributed in product, then the GPL doesn't really risk much intellectual property.

John

The Linux kernel uses a vanilla-unmodified GPL version 2. No modifications necessary apart from the note clarifying the status of syscalls by Torvalds.

That's how most people use OSes in their product. Don't tell me you can modify WindowsCE or QNX codebase. OSes are usually black boxes to developers.

The Linux kernel uses a vanilla-unmodified GPL version 2. No modifications necessary apart from the note clarifying the status of syscalls by Torvalds.

That's how most people use OSes in their product. Don't tell me you can modify WindowsCE or QNX codebase. OSes are usually black boxes to developers. The initial question of this thread concerns using Linux in a commercially shipping product - nothing more.

Ah, that is the advantage of open source. You can never do this kind of thing on most commercial OSes. Even Microsoft's shared source license does not mean you can compile a version of Windows on your own, you can only see how it works. But in your case I suspect BSD is more appropriate since the 'price' is simply acknowledging the author's copyright. Of course, if you are not familiar with BSD source code then that's a big learning curve which you have spent getting familiar with Linux source code.

BTW, there are some commercial OSes which allow you free access to their kernel without restrictive GPL or BSD licenses. OnTime's RTKernel is one. The 'price' is simply money, on a per-developer-seat, per-product/project basis. I've used it once but the pain of porting Linux-ready apps like Apache, webmin, mysql etc drove me back to Linux. GPL is a small price to pay for faster time-to-market.

There is special leave for modules and interfaces (at least, the last time that I checked.) Note that Linus added some comments about the GPL in the middle of the last decade or so. GPL diehards might believe that Linus's special leave is invalid, but that kind of thing is a reason for lawyers.

Simple OSes (e.g. RTOSes) tend to be low level enough to be black boxes. Current use of Linux at work is starting to require more intimate modifications (cannot talk more about it.) We are definitely resisting modifications, but will likely be needed. (The special leave for drivers by Linus will protect some IP.)

John

Well, I happen to be MUCH more familiar with the BSD source code (in particular.) I wrote much of the FreeBSD kernel :-). We did previously use the Microsoft CE thing, and access to much of the source code (as you suggested) was of little value to us for product mods. Linux (GPL) does indeed have generally nicer license terms than Microsoft (and many others.) BSDL can be marginally better in some cases, but the advantage(s) and disadvantages of BSDL vs. GPL haven't really been fatal to us yet :-).

Actually, the quality issues that we have seen about the OS/libraries, etc really haven't been related to license but code/implementation quality. If we were using a BSDLed kernel instead of GPLed, it really woudln't have made any difference to us so far.

John