No, it doesn't effectively change the license on the existing code

I didn't say it changed the license on anything. I said it has the effect (the practical effect) of subjecting the whole file to the more restrictive license. The reason why this is the case is (as you note) it can quickly become impossible to determine which lines are subject to which license.

Of course it doesn't subject the original code to the more restrictive license, you just don't know what is the original code. If you want to create something based on the original code with modifications under a different license, you should start with a clean copy. The further encumbered version is almost useless for that.

I agree, however, that there is no point in encumbering a BSD licensed source file with another license if all you are going to do is make minor changes. If you are going to make major changes, on the other hand, you may have a very good reason to do just that.

I agree, you certainly cannot remove the copyright notice, nor can you remove the license. However, you can indicate that a given file contains "portions" copyright so and so that are subject to a BSD license, and portions copyright someone else that are subject to a more restrictive license.

That has the effect of subjecting the whole file (assuming substantial modifications have been made) to the restrictions contained in both licenses, because the copyrights of both the original copyright holder and later contributors are applicable. In the case of code that was originally BSD licensed that has substantial contributions released under a more restrictive license, the file is (for most practical purposes) governed by the the conditions of the the more restrictive license, because the requirements of the BSD licensed portions are trivial to satisfy.

No care need be taken to avoid mixing the code subject to the different licenses within the file either, as long as the copyright notice and conditions that apply to portions derived from the original distribution are included. The whole point of a derived work is that the copyrights (and hence the conditions) of both contributors apply. If a function or code fragment subject to the terms of both licenses is not a legal nullity, no problem.

GPL-compatible does not mean that you can simply copy and paste code willy-nilly into a GPL project.

Most BSD style licenses are unencumbered enough that you can relicense direct derivatives (not just composite works) under practically any terms you want. Commercial companies do this all the time, and it is in fact what makes BSD style licensing for open source software projects so controversial - anyone can create a proprietary fork at will, with components that quickly lose their BSD character as modifications are added.

GPL licensed derivatives of BSD licensed components can be created in the same manner. It is the copyright of the authors of the modifications that makes the relicensing have teeth, it is the lack of a prohibition on additional license terms in BSD style licenses that makes it possible.

The MS-PL, on the other hand, specifically prohibits this practice, much like the Mozilla Public License (MPL). Both are moderate copyleft licenses, designed to make sure that derivatives of covered source files are always available under the terms of the original license.

There is no question that a system like Bedrock allows the ultimate in flexibility in terms of running programs from different distributions and the like. However, a multiple-distribution system like that adds a considerable amount of administrative complexity, making it relatively unlikely to be adopted by non-specialists.

There is an intermediate step that would solve much of the problem here - change the way that Linux packages are packaged and accessed so that multiple versions of library packages can be installed without conflicts, name changes, or repackaging.

The easiest way to do this would be to change the package manager to support a two level namespace instead of a flat one. So instead of simply installing the latest version of the package from your distribution, you could install a (largely) compatible version with the same name from a different source, and the package manager would pull in the necessary libraries from that source (or other ABI compatible sources) and track them as such. As long as the libraries themselves were appropriately versioned, the library packages would install without conflicts.

That wouldn't come close to letting you install any package from any distribution (in some cases the dependencies would be too complicated, or the ABI too different in subtle ways), but it would allow you to install more recent versions of most packages from the newer versions of the same distribution (including beta, rawhide, testing, versions etc) without problems in most cases, and many ABI compatible packages from other distributions as well.

In the 1990s, when Internet access from homes was mostly by dial-up, those lucrative âoetermination fees,â as theyâ(TM)re called, led to a proliferation of Internet service providers

This claim is dubious, to put it mildly. The termination fees were paid to the terminating telephone company. The ISP had nothing to do with it. In some cases this may have allowed CLECs (competitive local exchange carriers) to provide slightly lower rates to independent ISPs, but that is hardly the sort of thing that would lead to a proliferation of ISPs by itself.

The real reason for the proliferation of ISPs is that the phone companies themselves dragged their feet as long as possible on providing anything other than ordinary dialup service. ISP startup costs were relatively low, demand was very high, and at the time ISP service came with all sorts of value added features to allow ISPs to distinguish themselves from their competition.

In addition, if the FCC didn't wildly misread the Communications Act of 1934 at the prompting of the phone companies, there would still be a large number of independent ISPs. Internet access is not an information service, it is a telecommunications service.

UTOPIA is great, if you can get it. The problem is that your city needs to sign on, and you and preferably several of your neighbors need to each agree to pay ~$30 a month to lease a fiber connection (or purchase the the right to use one indefinitely for ~$3000). Then you pay your ISP / IPTV / telco provider to deliver service to you over the shared Ethernet network. Build out has been relatively slow, in part because they originally projected that most customers would sign up for Internet, television, and phone service over the network, where in reality most want just plain Internet service.

Utah is a heavily Republican dominated state, and UTOPIA is certainly not on the Republican hit list. It is mostly on the hit list of lobbyists for CenturyLink (Qwest) and Comcast. They tried to have the state prohibit such networks several years ago and failed. UTOPIA is now a fait accompli and the chances of it being shut down by legislative action are non-existent. They need those revenues to pay the bonds back. The only question is can UTOPIA succeed enough with its new revenue model to make new cities want to sign on. I sure hope so.

I don't know who was the money to buy expensive toys that the manufacturer leaves behind two and a half years later. I guess it is good that someone out there is willing to take the hit.

The problem is that on Windows RT devices, users will not be allowed to disable Secure Boot or provide their own keys. Such devices will be Windows RT only bricks.

You are off by a factor of ten. Process sizes are currently in the 22 - 32 nm range. 0.45 micron (450 nm) would have been close to the state of the art almost twenty years ago.
http://en.wikipedia.org/wiki/22_nanometer

"Some of the commercial airports with asphalt runways include Baltimore-Washington International, Lindbergh Field in San Diego, McCarren International (Las Vegas), Memphis International, Newark International, Oakland International, O'Hare International (Chicago), and San Francisco International."
http://www.moasphalt.org/facts/asphalt/airport_qa.pdf

On the second point, if they were to release all of their hardware specs, then, it's theoretically possible for someone with a bigger budget (Intel comes to mind) to come in, build these exact same chipsets in higher quantities and undercut AMD at sales.

That is ridiculous. The specifications needed to interface with a hardware device are roughly comparable to a complete definition of a software API. The implementation details are typically thousands of times more complicated.

For example, if you had the complete interface specification for a modern desktop microprocessor (freely available, easily a couple of thousand pages), just add several hundred million dollar research and development budget, and you too can produce a compatible device with comparable performance, if you are lucky.

no attempt is offered at explaining why SPDY should be slower than plain ol' HTTP, only why it might not be faster

The author was testing SPDY over TLS, which has a significant connection startup overhead. That probably explains all the performance degradation relative to regular HTTP.

In fact, if SPDY support was ubiquitous tommorrow, I would be surprised to see SPDY+TLS used for third party ad serving for this very reason. SPDY+TLS isn't likely to be used for that without _major_ standards modifications to allow third party content to be transparently proxied through first party sites cookies and all.

Let's see if I've got this straight: "You gave me A, B, and C for free yesterday, and now you're only giving me an improved A and B for free?

What would really happen if Microsoft crippled future versions of Visual Studio Express is that a market would be created for low or no cost alternatives. That would probably be a good thing but it would be annoying for many people to convert. It probably wouldn't be too hard to port KDevelop to Windows, for example.

Have you considered that the economics of the support business change dramatically depending on how many million customers you have?

The question was not about support, but bug fixing.

For most mid-range and custom business software, fixes to anything but the most serious bugs (and often not even then) only come with a support contract. A support contract is typically both how you get bug fix releases and reasonable attention to the bugs that you would like to have fixed.