Because it requires you to do things that the GPL does not require, and the GPL doesn't allow this. It does not matter whether something is annoying (or even non-free) or not, the point is that works derived from GPLed software must only be distributed under a license that has no requirements that the GPL doesn't have.
This problem doesn't seem to have impaired proprietary software, where every project/company usually invents its own license as well.
Open source is actually a lot easier, at least if you see an "OSI approved" label, you have some guarantees about what you are allowed to do. And in practice, most projects use one of the GPL, LGPL, BSD/MIT-style or Apache license anyway.
Then use another GPL-like, copyleft license without that is compatible with XFree86, or just add a clause that specifically allows people to link them together. You are the copyright owner, you can do that.
And Debian ships a lot of code under non-GPL-compatible licenses. They even distribute non-free code (which is something very different).
Will this affect the popularity of the GPL?
XFree86 is using a different license, as is Apache...
But XFree86 and Apache (and thousands of other projects, some very important ones among them) have always used non-GNU licenses, and GPL-incompatible licenses are not uncommon either. (OpenSSH, Mozilla,... - Apache is just adopting a new, GPL compatible license) Yet many people still use the GPL as a "default license" without much thinking, and it and the LGPL are by far the most frequently used free licenses.
will this put off others using the GPL, and encourage them to use a license of their own creation that best suits their needs?
Hopefully people will use one of the various existing open source/ free software licenses rather than rolling their own, but other than that - wouldn't it be a good thing if people would use what best suit their needs?
No, IMHO it doesn't. The problem with the old BSD advertising clause was that you had to mention the original author in "all advertising materials". The new XFree license requires you to include the acknowledgement in documentation or "in the same form and location as other such third-party acknowledgments", for example a README or CREDITS file.
This seems to be a big difference in practice - even hundreds of such lines in the docs would be manageable, while it would be pretty much impossible to include them all in, say, a banner ad.
Of course, this doesn't mean that it's not GPL-incompatible, because it still is a requirement the GPL doesn't have. But frankly, who cares?
"All XFree86
contributors are invited to review the changes, and notify us of errors
and omissions so that they can be corrected before the 4.4.0 release."
Um, wouldn't all contributors have to actively agree with a license change which affects their contributions, i.e. code they are the copyright owner of? Or did XFree86 require contributors to hand over their right, like many GNU projects do?
I understand how C++ became what it now is (although I think that some more cooperation between the C and C++ standards bodies would be a good idea to actually keep C++ a mostly-subset of C). I am aware that C-compatibility was, and is, a design goal. I am not, however, convinced that this goal, and the others that shaped C++, were the right ones to choose.
Objective C is C-compatible as well, and while it is far from my dream language, it is a far more consistent language than C++ is. It does not have all the features of C++ however - it is just C combined with OO. It doesn't support generic programming, for example. But is it a worse language because of that? If you want genericity, why build upon a language that bases its broken type system on assumptions fundamentally opposed to it?
Many languages support everything C++ can do, and better. Generic programming is no magic; the C++ way of doing OOP is rather limited; RTTI is a joke even in the context of other 80ies languages; its exception handling features are not only conceptually limited in comparison to its competitors, they don't even work well in practice; and the idea that it is "close to the metal" is only due to its inconvenience (as long as you happen to use a CPU designed after the VAX - in case anyone didn't notice, pointers are an abstraction that doesn't have much to do with how actual computers work; they are just a particularly useless abstraction).
Oh, and when talking about templates or exceptions, I didn't mean the neccesity of defining a manageable subset of C++ for any given project to prevent utter madness, or because you care about executable size (templates) or the C++ runtime environment (everything else) - there are indeed projects who state that they do not use STL, RTTI, exceptions and stuff because they simply do not work portably. IIRC Xerces-C is a rather verbose one of them.
If a language looks ugly, it's generally because it is. It was a cheap upgrade path from plain C, and in some environments that are pretty C++-centric, like Win32, there is no way around it. It is also possible to write working software using C++, of course, even in a large scale if you like fighting your tools, but I don't think that it is the best choice for many projects it is used for.
I completely disagree. C++ syntax is horribly complicated, with many corner cases (one could say the same about its semantics). Creating a correct C++ parser is damn hard, probably only Perl is as hard to parse correctly.
And if its portability would be so great, why did complete, standards-compliant compilers only get available recently? Why do many projects choose not to use exceptions or even templates to avoid portability problems?
Oh, and no, you cannot easily call C++ from other languages, unless you take the time to create 'extern "C"' wrappers for all functions, either manually or with some tool like swig. Otherwise name mangling, which is not standardized across implementations will bite you. You cannot even generally link two libraries compiled with different C++ compilers together.
There Is No Bug. URLs with username/password parts work as they should in IE - but this, technically proper, behaviour is exploitable. It is not a technical problem, more like a way of social engineering - uneducated users or users that don't pay much attention to the URL may interpret it differently that the Browser does. So it is pretty much impossible to "fix it properly".
This "solution" still sucks, there are good reasons to use such URLs, and for many of them, you explicitly do not want a popup. The 1und1 "@-domains" are not one of those however, these idiots deserve to suffer (and the morons who paid for this... well, a fool and his money...)
What used to be the first version number, which was 1,
has been discarded since it does not seem that I need three
levels of version number.
However, a new third version number has been added to represent
changes by user sites. This number will always be zero in
Emacs when I distribute it; it will be incremented each time
Emacs is built at another site.
Making an accessible web app also makes it more usable for people without any disabilities actually, not to mention for non-people like search engines. The WAI guidelines are really a collection of best practices for web development - Even if you don't need to put up a triple-A conformance label on your app, it is always good to keep them in mind.
The W3C WAI resource page has pointers to everything you need to know. A popular tool that helps evaluating web accessibility is Bobby, but unfortunatly it isn't free.
As far as I know, Design By Contract is only easy to do if a) the language has explicit support for it built in, like Eiffel or Sather, b) the language is flexible enough to change important aspects of the object system in plain user code, like Common Lisp, or c) you consider ugly hacks with nonstandard preprocessors easy, like with the packages that turn magic Java comments into checked assertions. I don't much like the c approach, but I don't see another way to do DBC in Java (or C++, or whatever other language). Did I overlook something?
It's a requirement if you want to publish or use software, or anything similar, without getting in legal trouble. For just being a geek it is more of a hindrance, because you loose the fun in mindless, underinformed license flamewars.
The old license included an "obnoxious" advertising clause, similar to the original BSD license, saying that you have to prominently inform users that your derived work includes Apache code (while, on the other hand, you may not use Apache-derivedness for advertising, or even in the product name, so that "Powered by Apache!" or "Reivec's Apache-Based SuperHTTPD" were forbidden)
* 3. The end-user documentation included with the redistribution,
* if any, must include the following acknowledgment:
* "This product includes software developed by the
* Apache Software Foundation (http://www.apache.org/)."
* Alternately, this acknowledgment may appear in the software itself,
* if and wherever such third-party acknowledgments normally appear.
This is pretty annoying, especially if your project includes parts of many projects that require this. It also made it GPL-incompatible.
Another thing was that "Apache" and "Apache Software Foundation" was "hardcoded" in the license text in many places, so that you couldn't just use it unmodified for non-apache projects (not that big a problem in practice).
You can always just use different root servers, either one of the 12 others in root-servers.net or a completely different DNS hierarchy.
Technically, they are not very powerful at all - they can't do anything which you couldn't work around by tweaking a configuration file or two. The only problem is that not many people know that, and that tweaking a configuration file or two on billions of systems is a minor logistical problem, so you fixes are effectively only possible for those who care enough.
Maybe because they think that things changed in their favourite direction? The ad isn't advocating copyright violations, but paid downloads - only that in this case Pepsi pays for a handful of songs, not the end user.
I guess they feel that their way of adaption ("customers don't want to buy overpriced shit any more? sue them!") has worked great.
Re:Sources for Software Patent research?
on
Perens on Patents
·
· Score: 1
Linux will take over the desktop once it gets reinforcement on the data-center front by the Hurd. Of course, the Duke Nukem Forever port will also help.
Given that the HURD will probably be released shortly after when SCO provides proof for its claims, that might be a strategy...
Seriously though, some of SCOs more ridiculous claims would actually affect any kind of vaguely POSIX-compatible operating system. Damn, they claim errno.h! Every OS with a C compiler needs that file, and given how trivial it is, you can expect all "errno.h"s to look a lot like the one SCO claims to be it's intellectual property.
The only safe OSes in that case would be those whose implementors have a license from SCO, like Solaris or Windows. I guess they would find a way to sue Syllable, Eros or OpenBeOS developers/users because they violate some UNIX-related rights, even if they are not unix-like OSes at all.
I still think that some of SCOs original claims against IBM may actually be valid - while it is suspicious that it took then so long to back up their claims, I don't think it is impossible that some bozo at big blue did something really stupid. But this is not what this is all about anymore - the potential validity of any of their early claims has been completely shadowed by the utter ridiculousness of their latter ones. The only case as laughable in theory and as annoying in practice as that I personally have ever heard of were those of the german ex-phone-monopolist Deutsche Telekom, who once claimed the color magenta and all words starting with a capital T as their trademarks.
In that case it depends on whether I can call a class method on an instance of the class or not. I have no idea if this is allowed in Java (but I guess that class and instance methods at least are in the same namespace, so that you cannot have a class and an instance method of the same name/signature), but some languages let you do this.
Or just have explicit namespace operations. For example, to invoke a method on an object in Common Lisp, you would write (do-something-with some-object), to do the same on a class (which, of course, is a first-class object), it would be something like (do-something-with (find-class 'class-name)), or (do-something-with (class-of some-object)). CL classes have their own namespace, but yet there is little trouble.
(On the other hand, Common Lisp should probably be avoided as an example in a discussion about case sensitivity...)
It is a question of all language features, from case sensitivity to namespaces, general syntax and semantics, playing together nicely; it is generally not a good idea to change a single aspect of a programming language and expecting the result to be a consistent, better language.
This is easily solved by having separate namespaces for different things. Scince it is clear what is a class name and what is a variable anyway, you could simply write user user = new user();
I guess the real answer is that, for a user, it simply does not matter much whether a language is case sensitive or not. The differences are neglible. For an implementor case insensitivity probably makes things slightly harder, but not in a way that should require more work than putting a normalizeCase(identifier) here and there, so no big deal either.
Slashdot Mirror
Because it requires you to do things that the GPL does not require, and the GPL doesn't allow this. It does not matter whether something is annoying (or even non-free) or not, the point is that works derived from GPLed software must only be distributed under a license that has no requirements that the GPL doesn't have.
Open source is actually a lot easier, at least if you see an "OSI approved" label, you have some guarantees about what you are allowed to do. And in practice, most projects use one of the GPL, LGPL, BSD/MIT-style or Apache license anyway.
And Debian ships a lot of code under non-GPL-compatible licenses. They even distribute non-free code (which is something very different).
This seems to be a big difference in practice - even hundreds of such lines in the docs would be manageable, while it would be pretty much impossible to include them all in, say, a banner ad.
Of course, this doesn't mean that it's not GPL-incompatible, because it still is a requirement the GPL doesn't have. But frankly, who cares?
And add one more expensive processing step, while losing the ability to debug with a simple protocol-agnostic network sniffer.
Objective C is C-compatible as well, and while it is far from my dream language, it is a far more consistent language than C++ is. It does not have all the features of C++ however - it is just C combined with OO. It doesn't support generic programming, for example. But is it a worse language because of that? If you want genericity, why build upon a language that bases its broken type system on assumptions fundamentally opposed to it?
Many languages support everything C++ can do, and better. Generic programming is no magic; the C++ way of doing OOP is rather limited; RTTI is a joke even in the context of other 80ies languages; its exception handling features are not only conceptually limited in comparison to its competitors, they don't even work well in practice; and the idea that it is "close to the metal" is only due to its inconvenience (as long as you happen to use a CPU designed after the VAX - in case anyone didn't notice, pointers are an abstraction that doesn't have much to do with how actual computers work; they are just a particularly useless abstraction).
Oh, and when talking about templates or exceptions, I didn't mean the neccesity of defining a manageable subset of C++ for any given project to prevent utter madness, or because you care about executable size (templates) or the C++ runtime environment (everything else) - there are indeed projects who state that they do not use STL, RTTI, exceptions and stuff because they simply do not work portably. IIRC Xerces-C is a rather verbose one of them.
If a language looks ugly, it's generally because it is. It was a cheap upgrade path from plain C, and in some environments that are pretty C++-centric, like Win32, there is no way around it. It is also possible to write working software using C++, of course, even in a large scale if you like fighting your tools, but I don't think that it is the best choice for many projects it is used for.
And if its portability would be so great, why did complete, standards-compliant compilers only get available recently? Why do many projects choose not to use exceptions or even templates to avoid portability problems?
Oh, and no, you cannot easily call C++ from other languages, unless you take the time to create 'extern "C"' wrappers for all functions, either manually or with some tool like swig. Otherwise name mangling, which is not standardized across implementations will bite you. You cannot even generally link two libraries compiled with different C++ compilers together.
And it would really suck if you'd use it in some script to update your dynamic DNS entry or some such.
This "solution" still sucks, there are good reasons to use such URLs, and for many of them, you explicitly do not want a popup. The 1und1 "@-domains" are not one of those however, these idiots deserve to suffer (and the morons who paid for this... well, a fool and his money...)
- There is a new version numbering scheme.
[...]What used to be the first version number, which was 1, has been discarded since it does not seem that I need three levels of version number.
However, a new third version number has been added to represent changes by user sites. This number will always be zero in Emacs when I distribute it; it will be incremented each time Emacs is built at another site.
Changes in Emacs 1.12
The W3C WAI resource page has pointers to everything you need to know. A popular tool that helps evaluating web accessibility is Bobby, but unfortunatly it isn't free.
(Of course, Melinda might be a problem - and you better not mess with her, lest she unleash another MS Bob unto the world)
As far as I know, Design By Contract is only easy to do if a) the language has explicit support for it built in, like Eiffel or Sather, b) the language is flexible enough to change important aspects of the object system in plain user code, like Common Lisp, or c) you consider ugly hacks with nonstandard preprocessors easy, like with the packages that turn magic Java comments into checked assertions. I don't much like the c approach, but I don't see another way to do DBC in Java (or C++, or whatever other language). Did I overlook something?
It's a requirement if you want to publish or use software, or anything similar, without getting in legal trouble. For just being a geek it is more of a hindrance, because you loose the fun in mindless, underinformed license flamewars.
Another thing was that "Apache" and "Apache Software Foundation" was "hardcoded" in the license text in many places, so that you couldn't just use it unmodified for non-apache projects (not that big a problem in practice).
Technically, they are not very powerful at all - they can't do anything which you couldn't work around by tweaking a configuration file or two. The only problem is that not many people know that, and that tweaking a configuration file or two on billions of systems is a minor logistical problem, so you fixes are effectively only possible for those who care enough.
I guess they feel that their way of adaption ("customers don't want to buy overpriced shit any more? sue them!") has worked great.
Since Perens talks about the european situation: the software patent site of FFII is quite informative about this.
Linux will take over the desktop once it gets reinforcement on the data-center front by the Hurd. Of course, the Duke Nukem Forever port will also help.
Seriously though, some of SCOs more ridiculous claims would actually affect any kind of vaguely POSIX-compatible operating system. Damn, they claim errno.h! Every OS with a C compiler needs that file, and given how trivial it is, you can expect all "errno.h"s to look a lot like the one SCO claims to be it's intellectual property.
The only safe OSes in that case would be those whose implementors have a license from SCO, like Solaris or Windows. I guess they would find a way to sue Syllable, Eros or OpenBeOS developers/users because they violate some UNIX-related rights, even if they are not unix-like OSes at all.
I still think that some of SCOs original claims against IBM may actually be valid - while it is suspicious that it took then so long to back up their claims, I don't think it is impossible that some bozo at big blue did something really stupid. But this is not what this is all about anymore - the potential validity of any of their early claims has been completely shadowed by the utter ridiculousness of their latter ones. The only case as laughable in theory and as annoying in practice as that I personally have ever heard of were those of the german ex-phone-monopolist Deutsche Telekom, who once claimed the color magenta and all words starting with a capital T as their trademarks.
Or just have explicit namespace operations. For example, to invoke a method on an object in Common Lisp, you would write (do-something-with some-object), to do the same on a class (which, of course, is a first-class object), it would be something like (do-something-with (find-class 'class-name)), or (do-something-with (class-of some-object)). CL classes have their own namespace, but yet there is little trouble.
(On the other hand, Common Lisp should probably be avoided as an example in a discussion about case sensitivity...)
It is a question of all language features, from case sensitivity to namespaces, general syntax and semantics, playing together nicely; it is generally not a good idea to change a single aspect of a programming language and expecting the result to be a consistent, better language.
I guess the real answer is that, for a user, it simply does not matter much whether a language is case sensitive or not. The differences are neglible. For an implementor case insensitivity probably makes things slightly harder, but not in a way that should require more work than putting a normalizeCase(identifier) here and there, so no big deal either.
2nd-hand Purchasing Advice on Buying an Indy. Very informative site.