I think the first "death of Usenet" panic I was around for was when the 100th newsgroup was created. The Great Renaming also spawned one. alt.* traffic volume surpassing all the other hierarchies was another. There have been zillions since then. But here we are, 40 years later. One way or another, it'll live on.

What amazes me was that enough people actually archived enough early traffic that I can find stuff I posted in the very early 80's. It was hard enough justifying the cost of carrying net.flame over expensive phone lines[1], using up expensive disk space and expensive CPU cycles, let alone buying a truckload of expensive mag tapes to store it all.

[1] If you weren't AT&T

And its meta-newsgroup, alt.adjective.noun.verb.verb.verb

This also indirectly enforces slightly more sensible metrics. In one place I worked, any change, even whitespace, counted as a source code change, so wrapping 1000 lines of code in an if...then counted as 1002 changed lines (which, of course, was coupled with a maximum 250 SLOC/hour inspection rate). The only way around this was to leave the original indentation in place, which made the code as messy as it sounds.

Compiler-enforced indentation would have solved this (but then again, so would development managers growing spines).

Should I even ask how much time and grief that took?

My several-year-old HP all-in-one has been working fine, even though it whines about the third-party ink I've been using (at a quarter the cost of HP-branded ink). The other day, it prompted me for a firmware update. Right there on the printer's little touch screen, it told me flat out that the main reason for the update was to prevent more third-party cartridges from working.

The original Unix philosophy was that each program should "do one thing and do it well," and that has carried over into GNU. The reason Emacs doesn't follow this dictum is that it was not originally written on or for Unix. Its first release was in 1976 on an internally-developed OS at MIT. Steele and Stallman's Emacs wouldn't even be ported to Unix until 1984, and even then, it was enough of a resource hog that using it earned you an angry call from the sysadmins. Gosling's Emacs, which was much more lightweight, came out in 1981 (see also: MINCE and JOVE).

By the time of the Unix port (and Stallman's inauguration of the GNU project), it would not have been useful to try to reshape Emacs to fit Unix's long-pipes-of-simple-things model.

Even legitimate clones of products have to be bug-compatible, because in any sufficiently large installed base, there's going to be some use that (usually inadvertently) depends on a bug being there.

Related: When I worked at HP, every now and then a customer would get tripped up by upgrading to a new CPU that had a bugfix that broke their code. All we could do was tell them to pay more attention to the release notes. The same thing happened with software upgrades, but it was much easier for customers to find code that depended on a software bug than, say, a microcode bug.

Haven't seen a true slashdotting in years! Also a good refutation of all the people here who think this is stupid and nobody would want it.

Solidworks and other CPU-hungry modeling and simulation software.

I would add the macro zoom cameras. When I need to get the serial number of a piece of racked gear, and I can't see it directly, I can usually get my phone up in there and take a picture.

"Transreflective".

THANK YOU. I knew there was a word for that but I couldn't remember it. I had the same Blackberry back in the day, my Garmin iQue GPS had it, and today, it's the thing I like best about my Garmin watch compared to its competitors.

I'm not being paid by anyone to disseminate anything anywhere, especially here. Go make up a better conspiracy theory.

What am I on about? I'll say it again, slowly.

1. Stipulated: Unaltered Linux itself does not have license problems (Red Hat notwithstanding).
2. Sometimes a company develops an application that runs on Linux.
3. That application may be intended for sale as a proprietary, closed-source commercial product.
4. That application may be based on other proprietary code, maybe under a source license.
5. That application may use other FOSS libraries built from source.
6. It is not always clear that no part of those FOSS libraries, and the code they depend on, are licensed under the GPL.
7. For that matter, the same may hold true for the proprietary code being modified.
8. It is the application developer's responsibility to see that their product is GPL-compliant.
9. That means verifying that nothing being built into the product is, directly or indirectly, copylefted under the GPL.

This is not unique to Linux. The same holds true regardless of the platform the product runs on.

I don't know why you're so certain that it is as simple as "Just don't put in any GPL code." Somebody's library may include somebody else's library that may include somebody else's library, and so on. Those inclusions and dependencies may be undocumented. The author of the library may be an expert in what the library does, and not an expert in FOSS licensing. They may have unintentionally copylefted their code, but the end user has to know for certain before including it in their product.

Maybe you can't be arsed to check all that. Maybe nobody will, or even think to, and maybe nobody will notice, and your product will be fat and happy and out of compliance for its entire lifetime. My current and previous employers have both decided it's both unethical and bad business to be that careless, which is why they pay me to ensure their products are compliant. (Once again, I'm speaking only as myself here, and I do not speak for my employer.)

I'm done now. Please enjoy having the last word.

That's not FUD. It's a simple fact. I gave multiple examples of what kinds of things can happen when you get serious about license compliance.

It was certainly not meant to be a deterrent to developing a product that runs on Linux, nor was it meant to imply that other platforms don't also have licensing complexity. My original point still stands: If you're making a proprietary, non-free (speech or beer) product, you have to be very careful that no part of it violates the GPL, and that's not always easy to determine.

This is part of my job. The problem is not what to do. We know about zillion of different licenses and how to comply with them. The problem is that once your project gets to nontrivial size, using a combination of COTS products, other FOSS you've included by building from source (which may in turn include other things), and a lot of code you've written yourself, knowing which licenses apply to which parts of your product gets very complicated, which is why companies like Black Duck get paid to figure that out.

I'll give you another case we ran into: One thing we use was shown to be covered by the GPL as well as a more permissive license. Digging further, we found that the part we used (luckily) was under the more permissive license. The package included some demo examples, which were under the GPL. We don't include those with our deliverable product, so we were OK.

Now, do this for hundreds of software components in each of several products, and it becomes obvious that the licensing is anything but obvious.

You're right, it'd be just as hard, but the GP's point is still false: Your code can get accidentally GPL'd without everyone on the project being morons.