Because the kernel IN THOSE SYSTEMS is just a "checkoff item". I.e., a "free" QNX, VxWorks, etc. license would suffice equally well. There's nothing inherently special about a Linux kernel that you can't also find elsewhere.
It's not real-time, isn't resource sensitive, has no provisions for fault tolerance, no support for namespaces nor capabilities, no support for distributed processing nor dynamic process migration, centralized configuration management, enhanced security, thorough documentation, etc.
You can *add* that support -- by layering it on with varying degrees of success. And, at a performance and resource cost. If you're not concerned with having gobs of RAM or loads of MIPS "to burn", then that cost is hidden from you -- until a competitor comes out with a product that costs less and performs better. *Then* what do you do? Appeal to the Linux community to give you a smaller, faster, more reliable kernel -- without all this support for devices and features that you may not *use*/need??
If, instead, you have a product that exploits those features and leverages them for a cost/performance/reliability advantage, why would you want to "taint" it by "borrowing" code from a GPL'd kernel? Esp when you can borrow functionally similar code from an "open" kernel!
Do you discount the costs of maintaining a Linux system? How often is the kernel revised? How often do folks have to upgrade an installed package -- or, a dependency on an installed package?
No system has "free" maintenance. Linux users may be more willing to tinker with adding/removing/configuring apps -- especially because they are "free" -- but that doesn't make the cost of doing so go away! They simply choose to value their time as "free".
No, that is not even remotely close to being correct. There are many differences between the Linux kernel and its closest cousins, the BSD kernels - and even more differences from QNX, vxworks, and any other kernel you can think of.
Of the features you mention, Linux has more than any others - it has soft real-time (and hard real-time extensions exist), it has plenty of support for some kinds of fault tolerance (and most fault-tolerance stuff is user-space anyway), it has namespaces and capabilities, you can do distributed processing and process migration (have you really never heard of Linux clusters?), you can manage configuration any way you want, there are many security enhancements you can enable, and there are piles of documentation.
A basic Linux system will take more disk space and more ram than a QNX or VxWorks system - but it will do /far/ more. And a QNX or VxWorks system will take far more space and ram than a FreeRTOS system, and so on. So what?
I will certainly agree that many embedded Linux systems could also have worked using QNX or even VxWorks - but there are also many that could not. I can also imagine that most embedded Linux systems could also have worked with a BSD kernel - assuming it had the right hardware support - but there are still many that could not.
I think you misunderstood everything I wrote about modules. The /only/ cost is in disk space - and if you do not need them, you are free to delete them from your packaging and/or disable the build if you are doing your own kernel configuration and build (it's /your/ choice).
So if you want SELinux or AppArmour for added security, you can use it. If you don't want it, don't use it. If you want capabilities and namespaces, use them. If you want a minimal Linux kernel without these features, you can have that too. Where's the problem?
You don't "taint" anything - just enable or disable them in the kernel build (for features that are too highly integrated to work as modules), or load or ignore the modules.
Oh, there is plenty of time and effort needed for working with any system - whether it is Linux, BSD, Windows, or something else. I did not suggest anything to the contrary. My point is just that administering /licences/ for embedded Windows can cost more than the licenses themselves. The cost for development, updates, maintenance, etc., for a system is another matter, and varies enormously.
Because there are differences doesn't mean that the choice to USE a Linux kernel is related to those differences! There are TECHNICAL differences between Windows and FOSS OS's but that is seldom the reason one is chosen over the other!
No, you are missing the point. It's not a question of whether or not a feature set CAN be supported on Linux. You can implement all of the above on single-threaded DOS!
The difference is whether the features ARE supported on Linux AND whether the kernel itself plays by the same rules! This goes to the nature of my "bolt on" comment (below).
EVERY TASK (process) created in my system is capabilities based, has its own namespace, uses RT scheduling constructs to govern access to the resources that it consumes/supplies, is fault tolerant, can be dynamically migrated to another processor in another location, can seemlessly talk to other processes on other hosts, uses the same security mechanisms, etc.
INCLUDING THE KERNEL ITSELF!
E.g., the network stack implementation uses the same RT scheduler as "userland" tasks. Demands on the network by (any -- including kernel tasks) are satisfied by examining the RT characteristics of the "network consumer".
If the task that handles disk I/O dies (perhaps because the disk interface on this host fails), it is migrated to another host and the connections to it are preserved -- even though it is no longer "local".
The task that handles the network can't in any way, access the hardware OR THE SERVICE that handles the disk drive. And vice versa. They have no concept (name) for each other!
Given the ability to load its own firmware off disk (because it has been provided with an appropriate name in its namespace: e.g., "/firmware"), a motor controller can't MODIFY that disk image -- nor access any other "stuff" on that medium (because the capabilities that the motor driver have been given preclude that operation).
etc.
The kernel doesn't do things one way while userland has to abide by a different set of rules.
The fact that these are loadable modules ("bolt ons") acknowledges the fact that the kernel can't rely on any of them in its operation. I.e., that it only *emulates* those services at userland level but wasn't designed to operate within those same confines.
That's my point (above)! The kernel doesn't embrace those features and present a unified API to ALL of userland AND ITSELF! It doesn't treat "memory" as a resource whose access is governed by RT parameters -- first come, first served! It doesn't schedule packet transmission over the network based on the RT criteria of the individual tasks requesting their delivery. It doesn't protect the disk driver from the network driver by appropriate namespace and capability entities.
It *can't*. Because it can't count on support for any of those "bolt on" features! (and you surely don't mean to claim the kernel rewrites itself based on which userland support features are loaded? So that it suddenly resolves ITS INTERNAL mutex conflicts with a different strategy based on whether RT support is present at userland...)
See above. If the kernel is doing things "different ways" for itself and for userland, then there is duplication of effort and the potential for unintended consequences -- because the same rules don't apply throughout. The kernel decides it doesn't have to behave the same way that it forces others to behave -- like old monolithic kernels that decide they don't need to be bothered with the constructs that applied to userland tasks (htose constructs created to enhance the reliability and ease of programming of those userland tasks!)
So, it's all or nothing. I can't clip some code fragment from the GPL'd kernel and benefit from its use. I have to embrace the entire GPL'd module -- and the GPL'd kernel onto which it bolts -- to benefit from this "code fragment".
So, I've got to "fix" the kernel so that it uses all of these features *internally*... just to be able to use them "externally". And, encumber it with the GPL in the process.
And, this is going to take LESS effort than starting from scratch and borrowing code from "unencumbered" sources? Remember, I don't care if you support 5000 different network adapters. There will be exactly *one* in any product I design. Ditto for video, disk, etc. And, the choice as to "which one" will probably not be made based on "available sources" but, rather, availability of *silicon* at the desired price point and with the necessary hardware capabilities.
I think his point is that most users can tolerate a "generic" kernel -- one that has every possibility accounted for.
In a desktop environment, that may well be the case. OTOH, if you're designing a cost-sensitive "appliance", you probably DON'T want to accommodate every possibility -- because your hardware simply can't take advantage of them!
In that case, why include support for something -- even "loadable modules" -- if it will never be used? In high reliability software, there is a concept called "dead code"; code that is never executed. It's presence in a product is seen as a flaw. It represents added complexity that is not used. And, added potential for flaws.
E.g., *something* in the live CD kernel that I recently booted (elsewhere this thread) is causing the system to crash before it can even go single-user. Likewise, a Linux kernel on another live CD also caused the video to go wacky. Whatever that is, it represents a liability of those particular kernels.
OTOH, when the live CD was built, I'm sure they reasoned that they wanted to include support for everything imaginable *on* that CD (even if some of that stuff tickles hardware that has not yet been imagined -- or, perhaps completely validated).
That's the consequence of using a kernel that was NOT built by THIS user (for this hardware).
Note that this is far less of a problem now (esp in the desktop machine world) than it was years ago. Because modern busses make it much easier to identify/probe particular hardware. OTOH, rolling your own hardware doesn't afford you this same level of protection. E.g., you can locate a particular peripheral wherever *you* deem fit in the address space; you can scramble the address or data lines to that peripheral; you can locate *other* peripherals in places where the probe for some other device can cause that other peripheral to lock up; etc.
Hence the apparent value of building my own live CD with a set of progressively more capable kernels. So, booting the default kernel doesn't even try to go looking for devices and capabilities that aren't needed TO EXAMINE THE MACHINE'S HARDWARE (dmesg output). Just make sure the interface to the CD, text display and keyboard are operational. (alternatively, USB *instead* of -- not in ADDITION to -- the CD. "Minimalism")
I suspect that is the approach folks like MS take. They settle on some basic set of capabilities that they REQUIRE from the hardware in the early stages of installation. So, they can at least communicate with the user to explain problems, etc.
If the part being upgraded is from the distro it basically costs nothing no more than the microsoft updates stuff does for windows users, but with oput the licence key issues.
Now you are talking nonsense. Most people who have Windows on a machine have not /chosen/ at all - it was forced upon them. But are you really saying that when people /chose/ an OS, it is seldom for technical reasons? Do you really think that I chose to run Linux because it saves me a couple of dollars on the license few? Or do you think I chose Linux because it is "cool"?
There are /many/ reasons why people choose particular OS's, for desktops, servers, embedded systems, etc. Some of these are technical, some are non-technical (such as an arbitrary dislike for an OS). You insult everyone who has ever made an informed decision about their OS with your claims here, and you show your ignorance when you suggest that the only major differences between VxWorks, QNX, Linux, BSD and Windows are non-technical.
This is exactly the sort of fight I wanted to avoid - I tried to give you a few /technical/ pointers to why Linux might do a better job for you, and in trying to battle ignorance and myths I have stupidly let myself get drawn in. And for every point I correct, you post another three paragraphs of new imagined issues. I simply don't have the time and energy to spend battling such determined fixed positions - this is why I and a good many others usually avoid many of your threads.
If you are happy with BSD, that's great. I am genuinely pleased that you are content with what you have. And I hope you will forgive my misguided attempts at making new suggestions that I thought might have made things easier for you - it was an attempt to help, not a call for battle.
It depends a lot on what your goals are. I use NetBSD primarily to host "services": my DNS, DHCP, TFTP, font, file, web, database, etc. servers all run on NetBSD boxen. They typically see very long uptimes (weeks, months, years). Performance is never an issue as I'm not a "commercial site" with lots of traffic, etc. Services tend to run headless so I am mainly concerned that the boxes boot reliably (so I don't have to drag out a monitor and keyboard to talk to them!) and stay up "indefinitely" (including recovering from power outages "unattended").
I like the fact that I can stuff a disk in a USB enclosure, plug that into a running system, partition the disk (disklabel), create the file systems (newfs), mount them somewhere convenient, copy the appropriate portions of the "hosting" file system onto that mount point (tar), build a kernel for that new system, unmount/unplug the USB drive and have a drive that is "ready to boot" on some new machine -- all in a matter of a few hours (most of that time spent deciding which files to copy and waiting for them to be copied over the USB -- only a few of my machines support hot-plugging drives).
Once the "new" system boots, I just have to tweek rc.conf(5) (fix hostname, add an entry for it in hosts(5), adjust any services that I may want to enable/disable, etc.) and verify all the desired devices are supported in the kernel that I built (e.g., I probably will NOT want the wireless device in the Atom's enabled *or* supported!)
[I assign static names/IPs to all of my hosts. I rely on the name server box to *resolve* those names -- but not on the DHCP server to *assign* them! That way, if the DHCP server is unavailable, I can still boot a "named" box and talk to it. Like most folks, I choose names that are easy to memorize: printers are Curly, Larry, Moe and Shemp with Curly at x.x.x.111; Sun boxen are George, Jane, Judy and Elroy with George at x.x.x.71 (actually, I think Elroy just got discarded); wireless AP's are Rosey, RUDI and Mack; PC's are Pinky, TheBrain, Tennessee, Chumley, etc. "Mnemonic aids" so I can deduce what the name server would likely report when queried for a particular name!]
I do very little "interactively" under NetBSD: primarily write and debug code. My "desktop" is incredibly unadorned: no fancy wallpaper, no animated icons, etc. Heck, I don't even have a *clock* displayed!
I'm more than happy with a root-weave backdrop -- most of it will be obscured by xterm/xemacs/eclipse/etc. windows, anyway! On some of the "real" X terminals, the root window may just be a solid color (to let me determine which "desktop" I am using)
I run a small app (xanim, IIRC) that turns the cursor into a "twisting" X (so it is easy to find). I use xeyes(1) to provide a quick hint as to where I should go searching for the cursor ("Where are THEY looking?"). And some other (forget name) app that *hides* the cursor when it is motionless for a period of time -- so I can freely type without having the cursor interfere with the text I'm trying to read (as soon as I nudge the mouse, the cursor rematerializes if I need specific knowledge of it's location)
I use Windows-based apps for most of my "real work" -- desktop publishing, schematic capture, PCB layout, analysis/simulation, etc. I run eXceed on the PC to let me bring my NetBSD desktops onto the PC (I had previously used NCDware as I purchased it to be compatible with some of my NCD X terminals. But I have noticed that I tend to invoke the eXceed server more often).
While NetBSD (and all the BSD's, for that matter) provide support for the various desktops, window managers, "OpenOffice", etc. -- the usual litany of FOSS products -- I don't run any of them as I have no real need for them (having similar or better tools running under Windows that all "play together" well).
I don't spend much (any!) time "updating" my Windows machines (nor the *BSD ones, for that matter -- if it ain't broke, don't fix it!) Seeing "products" like OpenOffice or KDE with new releases every few months leads me to wonder if they have that many *problems* or if there are that many MISSING FEATURES to necessitate so many releases! :< I surely don't have that much "disposable time" to invest in downloading, installing and debugging their latest set of features/bugs!
E.g., I went from NetBSD 3.1 to 5.something and will be building these Atom's under whatever -CURRENT/STABLE happens to be (6.1.4?)
If you have an IT department available -- or, like to "play" with your machines -- your preferences might be different.
These little Atom boxes, I am hoping, will allow me to replace larger, power-hungrier boxes with smaller, more energy efficient ones -- without too much of a sacrifice on performance. (I'm on a "downsizing binge"... too much kit hiding here! :< ) And, move some of the external drives that are currently hosted on specific Windows/BSD boxes off to a generic NAS appliance (i.e., boot *that* box instead of some specific Windows or BSD box to gain access to those files! At gigabit network speeds, there's hardly any advantage to "local access" to those drives!)
Unfortunately, most of my machines use PATA, SCSI, SCA, or FC drives. Only a couple of laptops (and one PC) use SATA drives. This leaves only the laptop SATA's in some of my "external" drives as potential "sources" of rotating media for the Atoms.
I'll see what I can come up with next week -- by way of drives *or* something comparable to the Atom's (that, perhaps, uses PATA laptop drives -- as I have many of those).
Meanwhile, I'm taking Andrew's suggestion and looking into (physically) small USB thumb drives to host executables. I can prototype this sort of operation with "regular" thumb drives and just move the images onto physically smaller drives when the idea is "proven".
David, you refuse to understand the basic issue that drives me (and others) away from Linux: we want to avoid the GPL LIKE THE PLAGUE! I have no desire to invest time bettering a product that I can't then use AS I PLEASE. And, that I can't pass on to other "licensees" in the same way!
I don't believe you can get real experience with ANY product if you just throw toy applications at it. E.g., evaluation copies of software are usually useless because you won't willingly undertake a REAL project with them out of fear you will bump into some limitation of the "intentionally crippled" product -- just as you near project completion or a delivery date! Why risk a project on an unknown??
I make heavy use of an RDBMS in my current projects. I could use any generic RDBMS for my work -- even a commercial product like Oracle. But, that means I am stuck with whatever that product provides. And, any bugs that come with it (no chance to peek under the hood to see why its behaving as it is, etc. -- to me, this is the REAL advantage of FOSS! A "live, working reference implementation"!)
I could use MySQL and gain access to the sources. I am then free to make any changes or improvements to it that enhance my product's "performance". But, then I have to assume the encumberances that the GPL puts on MySQL.
[I.e., I move to a FOSS product so I can peek under the hood]
In order to avoid the GPL in a RELEASED product, I would then have to *switch* my product over to an unencumbered RDBMS (e.g., PostgreSQL). And, learn all about *it*, see how my MySQL patches apply to PostgreSQL (i.e., they WON'T!), figure out what other issues PostgreSQL presents -- along with patches for those, etc.
THEN, I can freely drag my patched PostgreSQL implementation into my product without any other "considerations! Here, in essence, is the ENTIRE license:
"Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.
IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS."
Note that it doesn't impose any forward going requirements on me -- to redistribute my updates, to redistribute the sources from which I created "my version", ensure that a server has those files available for a particular amount of time, etc. "Do with it what you wish!" No worry about the "Microsoft (or GPL!) police" coming after me for failing to adhere to the terms of the license!
Contrast that with MySQL's license (or Linux's).
[I.e., I move from a GPL'd FOSS product to an "open" FOSS product so I can avoid the encumberances that the GPL imposes]
The same argument extends to other pieces of FOSS software FROM WHICH I LEARN AND GARNER EXPERIENCE.
Neither the Linux, *BSD nor "kernels" have the features that I want. So, NONE has any appeal to me AS A KERNEL that I can "inherit".
You've claimed I can "bolt on" many of these features to the Linux kernel. All of those features are intended to allow for more robust, secure "applications" that are easier to implement under those environments... but, the kernel itself should NOT benefit from those capabilities???
That's like offering a preemptive multitasking system and then opting to implement it on a single-threaded, nonpreemptive kernel! (i.e., NOT let the kernel's design benefit from the same capabilities that it is trying to extend into "userland") Do you not see the silliness in this argument? One of the most complex pieces of software in a system -- one that MUST be robust -- should be designed with ad hoc methods by some priestly elite??
["Well, that allows the kernel to be used in applications that DON'T need those capabilities! And, we can get some epsilon of additional performance out of it!" Great! And what's your justification for applications that *do* need those capabilities? "We didn't want to have to rewrite it from scratch. (We figured you could tolerate the LOWER performance of a non-native implementation...)"]
Kernel hackers shouldn't be part of some "sacred order". Someone wanting to write a Widget DRIVER should be able to do so in much the same way that he could if writing a Widget APPLICATION! And, the rest of the kernel should be as "unworried" about his efforts as the other APPLICATIONS would be if he was writing an application! I.e., his driver can't muck with hardware or data structures that shouldn't be VISIBLE to him! And, his "components" will inherently "play nice" with the other components in the system because they all use the same API and feature set in their implementation!
You and many Linux users seem to think Linux is The Answer to every problem. It isn't. Nor is Windows, FreeBSD, NetBSD, BeOS, Solaris, etc.
We each have particular criteria that we use for selecting the *tools* that we use. I don't use NetBSD for a "desktop" -- Windows has that covered far and beyond any other OS (in terms of the variety and sophistication of the applications that I can purchase). Where windows stands on a "technological" basis isn't important to me. Nor is the amount of memory that it uses for a particular purpose, how long it takes to boot, etc. I don't care about how many "security updates" it requires -- I just don't let the boxes talk to the outside world! (if you are celibate, you don't have to worry about condoms!)
I want specific features in the APPLICATIONS that I use -- and Windows-based applications have those features (regardless of the fact that I have to pay money for them). And have *had* those features far longer than any FOSS OS! (what was the state of FOSS 3D CAD, schematic capture, PCB layout, DTP, etc. in the mid 80's? Gee, Linux wasn't even a gleam in Linus's eye at the time! Should I have waited until those apps came along "for free"? Then, discarded all of the first-hand experience I had accumulated with their Windows predecessors? Just to save the money that I had already SPENT?? Or, rather, to become a faithful fanboy?)
I'm not interested in clipping code from "applications" -- the applications that I develop are unlikely to be encountered on a desktop -- Windows, Linux,
*BSD or other! There are no apps from which my code can directly "benefit".
Instead, I run NetBSD for the OS mechanisms and fundamental SERVICES that it presents and that I *use* WHILE I am writing code for my own OS's and applications. Note the subject of this thread -- and another, recently -- is concerned with appliances. I'm not trying to build an Atom-based, desktop machine! If I was, then I would be far more concerned with what performance I can get from the video subsystem instead of being EAGER to settle for 80x25!
A few weeks back, I replaced a NetBSD-based box, here, that provided many of the lightweight services: DNS, TFTP image server, BOOTP/DHCP, font server, print server, mail handler, etc. It was "up" for over 1000 days. The "replacement" process consisted of pulling the laptop drive from that box and cramming it into the new box (6"x6" instead of ~12x8"), booting, making note of the "not configured" devices listed in dmesg(8), adding those lines to the configuration file for a new kernel, building that kernel and installing it. I spent more time trying to get the drive to physically fit inside the box than I did "adapting" the software on it for the new hardware (faster, more modern, more memory, etc.)!
BECAUSE I HAD 20 YEARS OF EXPERIENCE DOING THIS WITH *BSD BOXEN! I.e., what I learned from actually USING *BSD's made it easier for me to do what I needed to do. Just like what I learn from USING PostgreSQL makes it easier for me to modify PostgreSQL to do what I want it to do!
Or, from using NetBSD in my DNS service, "file system", etc.
So, it is relatively easy for me to replace all of the various configuration files scattered around the file system and rework the applications and services to use a centralized database to supply these "settings" in a more unified manner. And, to use the security features of that database to ensure certain applications can't "peek" at settings that should have been "private" (which would be enforced using file permissions in a traditional implementation). And, to extend the capabilities and performance of those services by leveraging these features.
Why would I want to rewrite Linux's init(8) if I couldn't then copy ALL of init.c into my product, unencumbered? Why would I want to gain experience using Linux's bootstrap process if I wasn't going to benefit directly from that experience -- other than in troubleshooting how my "development system" works?
Why go *that* route when the same capabilities are available in OTHER codebases that will support the same sort of development activities (i.e., so I can get first-hand experience on a day-to-day basis) with the added benefit of being unencumbered?
When Linux replaces their license with the one cited above, *then* I'll consider investing time in it. Assuming, of course, that it offers anything that I *want* and haven't already acquired by then!
Until then, I really don't care if Linux supports more NICs, video adapters, applications, users, motherboards, file systems, etc. It's simply "not a contender".
I think you totally and completely misunderstand the GPL, totally and completely misunderstand how it applies to an operating system like Linux, and totally and completely misunderstand how open source development works, where it is a good choice, and where it is a bad choice. (And yes, I know you have written and published open source software.) You have convinced yourself of your position so solidly that even Steve "Linux and the GPL is a cancer" Balmer would be shocked. Frankly, I don't think there is anything I can say now that hasn't already been said to you in the past by myself and others.
(And no, I do not think Linux is the "answer to every problem". Like you, I look at each problem individually to see the best solution. I also happen to prefer PostgreSQL over MySQL for technical reasons - the particular flavour of OSS license used makes no difference when using a big database.)
You can fetch a copy of the GPL yourself. I'll just point out particular differences between it and the 3 paragraph license I cited before:
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.
Nothing significant here. I can copy and distribute verbatim copies of "unencumbered" products with similar terms. And, if I *don't* want to distribute the source code -- in its original form -- THIS CLAUSE doesn't require me to do so! It just LETS me redistribute it -- if I so choose!
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
The unencumbered products don't preclude me from charging a fee, either!
You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third
----^^^^^^^^^^^^--------^^^^^^^^^^^^^^^^^^^ parties under the terms of this License.
I.e., the MODIFIED work must fall under the same license terms -- even if only "part" of the GPL'd product is contained therein.
c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)
No worse than publishing the "three paragraph" license in the printed documentation, etc. These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program,
----^^^^^^^^^^^^^^^^^^^^^------------------^^^^^^^^^^^ and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
If I distribute NON-GPL'd portions of that work (e.g., *my* changes) then I don't have to put them under the same license terms. Of course, my changes -- in isolation -- would be pretty useless! If, instead, I distribute my changes IN the modified original, then the license DOES apply!
"I've got a new and improved automobile tire! But, I can't distribute it ON an automobile..."
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
Yay! My work is my own! (duh!) But, if it doesn't make sense or have value out of context, what good is that?
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
---------------------------------------------^^^^
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
I.e., ship a copy of the complete sources with your "product"
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
Or, offer to make available for the next three years AT COPYING COST a copy of that code "in a medium that the *industry* decides is "customarily used for software interchange" (e.g., would PRINTED TEXT qualify?? Hollerith cards?? Magneto optical disks???)
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)
"this alternative ... for noncommercial distribution"
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
I.e., so a recipient can sit down and start modifying the codebase, immediately.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
I.e., a web site. 4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
I.e., there are no other ways you can legally derive a work from this GPL'd product!
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.
As above.
Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.
Tell me where, in ANY of this legalese, it expressly allows me to clip portions of *any* GPL'd work and incorporate them into a work of my own WITHOUT honoring these conditions?
"If the portion is less than 23 source lines of code, then you can use it under fair-use doctrine..."
If there is NO PRACTICAL DIFFERENCE between this license and the 3 paragraph license, then why does it take so much extra verbiage to say the same "simple" thing!
Of course, the GPL almost *requires* a lawyer to determine its applicability in a particular situation. And, can conceivably be *argued* as applying (even if it is ultimately decided that it does not!)
Contrast that with the 3 paragraph license:
"Your honor, here is the documentation provided with the defendant's product. On page 6 you can clearly see the terms of the original license reproduced faithfully... And that's all there is!" (unless you are claiming that his code contains some OTHER source code of yours that is NOT covered by that license).
I can, for example, SELL the code that I create (in binary or source form) and BURN my copies of it without any fear of recrimination -- I've still satisfied all the terms of the license under which I operated. And the "purchaser" need only provide that copyright notice to similarly be "off the hook".
I don't think you realize how many folks AVOID GPL'd sources. Do you think
*all* of their legal staff are "misinformed"? That it takes all this extra language to say, "you have no obligations under this license"??
C'mon, David. Tell me where it says I can freely copy WHATEVER I WANT out of the Linux kernel and do *NOTHING* more than put a notice saying "portions copyright XXXXX" in the documentation. Are you sure *you* don't "misunderstand the GPL"?
I have trimmed this insanely long post down to one simple point so I can ask a question about it and hopefully get a simple reply.
How does using GPL code like Linux prevent you from using it as you please or from passing the code on to others?
My understanding is exactly the opposite. You can use it any way you wish on your own. But if you share your work with others you just have to share the source code as well. I don't see any restriction on who or how you share any of this. :S
Does your employer share *his* codebase with his customers? Competitors??
I want to make changes, improvements to a piece of code. I don't want to
*have to* share it.
*I* may opt to share it; but, someone who embraces my codebase might NOT want to share it or his further improvements. E.g., a commercial entity that wants to exploit the work without sharing his enhancements, being called on to redistribute the original sources that he received or even tipping his hand as to *what* codebase he based his product on! (e.g., if my license terms force him to include a notice that says "Portions copyright Don Y" that doesn't tell anyone *what* sources he used, which version, changes, etc. And, *I* am under no obligation to provide those sources to those "other interested parties", either! I can abandon it or take it in yet another direction, entirely!)
David seems to think I *can* do this under the terms of the GPL. I believe he is wrong. (read the GPL -- any version -- for yourself)
No, that is factually incorrect. You are free to modify GPL code all day long and not share it with anyone at any time. GPL talks about what you must do when you *do* share it.
I am my employer and I don't use GPL code in my work. But that is only because there is very little GPL code available in the work I do. I mostly write my stuff from scratch so far. There are processors cores for FPGAs which I might consider using some day. But not so far.
No, you don't have to share anything. There are any number of vendors who use GPL code and they have never shared any of it with me and they won't even if I ask... because I haven't bought their product, so they aren't obligated to share with me.
A bit long winded and confusing, but this is different. Here you are talking about a product that someone used GPL code in and now wants to profit by. Yes, here the GPL says you must share the original code as well as your modified code.
Your code would be shared though him since he is obligated to share it if he used it in a product.
If you are describing a situation where your code was written with GPL code and distributed that way but you also distribute it as stand alone... I find that a very odd scenario and one that is very unlikely. Certainly I have no horse in this race so I won't even try to figure it out.
If you want to take but not give then GPL is not for you. You are not alone in avoiding the GPL; the conditions stated in the GPL are often not acceptable in a (traditional) commercial setting and are either worked around or avoided altogether by choosing a product which has a licensing scheme that is more compatible with commercial requirements.
True, but you do have to share it with your customers, and if they want to share it with the rest of the world GPL assures they are allowed to do exactly that. So in practical terms your modifications are open to the rest of the world. There is a reason why LGPL was conceived and licenses like BSD are a lot less controversial in commercial settings.
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.