b) Why do you think what climatologists say isn't falsifiable?
It isn't falsifiable because if they come up with a theory that matches the recorded data, there is no experiment that you can repeat in order to falsify their claims.
The whole point of GNU/Linux is that you have complete control over and significant trust of your system. If you bring closed, proprietary, DRM-infested software onto it, you're just turning it into another Windows; you might as well just go back to it.
No, what we need to get these people to do is to give us the code to their engines (even if under a mostly proprietary license). That way we will be able to continue enjoying what makes GNU/Linux attractive and play games as well.
Did you miss the part of the GP's post where he says pirated versions of software are on sale, cheap, at his local mall? A company, musician, or artist takes a big risk in creating the data you seem to dismiss so lightly. Maybe it takes three months out of their life; maybe it requires years of full-time effort from 20 or more coders, artists and coordinators, but the only way they have to recoup that risk is for someone to give them money. Shareware has taught us that a very small fraction of people who download software will pay for it voluntarily (although certain well-established names clearly have a fan-base that will yield good returns).
Just because someone has invested a lot of time or effort into making a sequence of bits, it does not mean that they are entitled to profit from it.
The new thinking is that the right of people to share comes before the right of distributors to enforce payment for making copies. The old thinking reverses these priorities.
If the new thinking means that distributors (or creators) cannot make a profit, then so be it. They will have to put their sense of entitlement aside and adapt to the new market reality.
The same people who want to share also want new movies, games and music. If that means they have to pay up-front kickstarter/vodo-style, then they will. It's a new idea with lots of issues to work out, but faced with no other choice, the creators and the public will eventually settle into a functioning system.
There is no going back to strict copyright control without monitoring and censoring all private communications. This is why I think that it is only a matter of time before non-commercial copying is legalised and an alternative creator compensation system becomes everyday reality.
Really? You're list of "must haves" starts with "goto"?
I know that there are still some diehards out there who insist that unstructured branches (i.e. "goto") have a place in a modern programming language, but the only example I have ever seen where a "goto" actually provided some value was in a performance critical piece of system code (specifically, it was part of the Linux kernel). Given that Java is an application language, not a system language, I see absolutely zero value in introducing unstructured branches. The structured branch constructs are perfectly sufficient.
Adding unsigned types to the language would add very little value, but it would add at least some value, so I won't argue with that one.
Goto isn't used in Linux for performance reasons. It's used because C does not have exceptions and using goto to jump to clean-up code prevents code duplication. Any sufficiently experienced C programmer will encourage you to do the same.
Of course, Java has exceptions and the finally keyword, so goto is not strictly needed for this purpose.
The GPL3 does indeed state that. But isn't the purpose of section 7 only to allow the copyright holder to work around the fact that the header of the license states that changing it is not allowed? Section 7 explicitly mentions that you have to have permission from the copyright holder to add additional clauses. You may thus add restrictions to the license which are not counter to the spirit of the vanilla GPL3.
But the question is, how does this affect compatibility between "GPL3 with additional restrictions" and just "GPL3"? Since without permission from the copyright holder you cannot add or remove additional restrictions, you may not use the licenses interchangeably. Because the additional restrictions are not present in the vanilla GPL3 (which does not allow additional restrictions unless you are the copyright holder and these restrictions fall under section 7), if you combine GPL3 code and "GPL3 with restrictions" code, it seems to me that there is no possible way to satisfy the terms of both licenses simultaneously.
So the way I see it, although GPL3 allows you to add these terms, by doing so you make your license GPL3-incompatible. If this is the case then it is troubling, and I would welcome any clarification from someone who knows the details behind this.
It seems that the licensing is a mess.
The header in the source files state that the code is GPLv3 or any later version, with additional clauses added.
In addition, the Doom 3 Source Code is also subject to certain additional terms. You should have received a copy of these additional terms immediately following the terms and conditions of the GNU General Public License which accompanied the Doom 3 Source Code. If not, please request a copy in writing from id Software at the address below.
However, it seems that it is only possible to apply these additional terms to GPL version 3 exactly (and not any later version):
2. Replacement of Section 16. Section 16 of the GPL shall be deleted in its entirety and replaced with the following:
These additional terms seem to be just disclaimers of liability and an indemnity clause, but it is entirely possible that they make the source GPL-incompatible, which, if true, would be a huge disappointment.
So not only is the license not self-consistent, it is likely also GPL-incompatible. The additional terms may further make the license non-free, and definitely non-DFSG-compliant. Thanks go to the corporate lawyers who have turned Carmack's good intentions into an abomination. I hope that they can re-release this under saner terms.
I have a very small mind and must live with it. -- E. Dijkstra