What I meant was: "you can't take the source-code that was developed, derive something from it, slam the proprietary door shut on that piece, and start selling it for-profit as you might do with something that you had singularly developed from scratch." Any so-called derivative work must be available under the same terms, with reasonable allowance for covering the actual costs (if any) of doing so, and you can't impose further limitations on what someone else does with whatever it is that you did. This is not just camaraderie saying these things: it's international law. It is "free and open" sharing, under explcitly defined terms and conditions, and with teeth (which it needs to have).

Obviously, everyone is in this business to make money, and open-source GPL'd code is critical to everything that we do these days. But the money is made from layers of software that are built on top of, and to a lesser extent using, the open-source common code that is shared by one and all. The enforceable terms by which this sharing must occur are set forth in the legally-binding GPL license.

Apple runs their system on Darwin (publicly licensed as open source), uses GPL'd image manipulation libraries and file handlers, but sells iTunes®. The same's true of your phone, your tablet, every little electronic gee-gaw that you own, all of which you bought. But, none of those manufacturers had to start from "nothing," as they once were obliged to do.

We literally would not be in the favorable positions that we all are in today, all around the world, without legally defined open source licenses. From a purely engineering standpoint, it could not otherwise be done in a financially viable way.

Yes and no. You are correct in thinking that this defeats the traditional model of selling software, because anyone who buys it has the freedom to share it with others for free. Nevertheless, retaining the freedom to sell the software allows money to be made in a few other ways. For example:

Distribution services. You could, in theory, run a repository where all the free software is conveniently collected, categorized, indexed, maintained, and tested, and charge people for the privilege of connecting to it.

Hard media and documentation. You could sell hard media versions of your software (CD-ROMs, etc.) which people might want to buy so that don't have to waste their bandwidth downloading. Likewise you could sell printed versions of documentation covered under the license. Richard Stallman used to make a living back in the day selling boxes of GNU software.

Priority updates. You can have a special repository where you put important security or other software updates, and charge customers to access it. Customers who pay for these updates get them faster than everybody else, and get the confidence of knowing the you tested all the updates first. This is the foundation of the Red Hat business model.

Custom software. If some big company needs a FOSS program to be modified to do something special, or get some new functionality, they might pay you big bucks to code in the functionality. Sure, other people will get the new code for free... but who cares, so long as the company gets the functionality they need, and you get a big paycheck. I think Google does a lot of projects like this.

Yes, and I also believe that we need to keep in mind what "the real business purpose of" all this open-source stuff is!

You may or may not remember the days when there were no less than four different, incompatible, and vendor-specific "ways" to connect the handful of PCs in your office together. It could have been Microsoft, Banyan Vines, AppleTalk, Novell, or, most-likely, "some weird combination of" the foregoing.

The now-obvious problem with that situation, which was "necessarily aken for granted" at the time, was that they were all different, and ... as no one really considered at the time, all utterly pointless. No one was talking to one another. No one was even looking for "common ground!" Although no one stopped to consider it at the time, all of us were starving in isolation, when none of us could plausibly ever hope to make money on our own. Everyone was literally trying, each in their own "proprietary" way, to get to the first step from which any hope of actually making "real money" could even be considered. We were all spending so much time trying to keep any of our "competitors" from getting out of the pool, that everyone in that pool was drowning and none of our mutual customers' business needs were being served. (They merely wanted to know "why-the-hell this computer can't send a document to that printer!" Damn good question.)

So ... the (necessarily "legally-defined") notion of open-source sprung from that. "Let's first help each other get out of the pool, so that we can persuade our mutually-disbelieving customers that we can actually solve their problems. Then, we can beat each other up from there."

A very similar problem actually happened to railroads. For many years there was no agreement about how wide apart the rails should be! Railroads even thought it was "to their advantage" for that distance to be different from their competitors. They thought it was "splendid" to build separate parallel rail lines, all to different(!) gauges, to the same place. It actually took quite some time for them to realize that, even though they competed with one another, they were all in the same transportation business, and that there were many technological points (such as rail gauge...) upon which it was essential that they must work together.

Open-source moves many common technologies into a legally-defined(!) status of "we shall not compete on this." This gets everyone out of the pool. This allows there to be a single-gauge rail line serving the customer instead of five. This allows competition to become focused upon the "distinct differences between them" that are actually important to the customer. (Who, quite rightly, has no intention of actually paying anyone to schlep his freight from one freight-car to another apparently-identical freight car!)