The incompatibilites between the different XMLHttpRequest implementations are not really that big. The main differences are still in the DOM, e.g. Internet Explorers inability to act correctly to a
Who do you have to bribe for articles like this? And how much?
Or is there any other reason why an article submission for my GPLed webapplication framework gets rejected, but a ridiculously over-priced, closed-source, windows-only offering, whose main feature seems to be buzz-word compliance and marketing-droid BS, gets free PR?
After reading the article I am left with the impression that Marc Andreessen has no real idea what he is talking about. First the article does neither mention JSP nor any of the other relevant technologies ( tapestry, velocity, struts etc. etc.). If Marc Andreessen wants to compare PHP to Java he should do it by comparing it to the different approaches which have many differences in target and complexity. He says Java is "arguably even harder to learn than C++" - again he seems to compare C++ core language to Java plus every library in existence - otherwise I can't understand how he comes to this conclusion.
Let's focus on PHP vs. JSP. I have done websites in both JSP and PHP. I did not really like PHP. The function naming is a complete mess, it's rather hard to get a decent structure into it and I hate languages that use special charactes to prefix variables. For me PHP is only advisable for websites with a really low functional complexity.
JSP is quite nice when used correctly - which would include renouncing scripting expression inside the JSP documents. ( there is no real difference between <?php echo $foo ?>, <?= $foo ?> and <% out.print(foo) %>, <%= foo %> ). Instead just use custom tags and EL expressions, mix it with some MVC features and you have a decent structure, a clean separation of code and layout with a nice declarative interface. You may want to add some autogeneration of descriptor files to ease development. (or just use japano my webapplication framework which coincidentially contains all that features;)
Yes, it is a little more complicated than JSP, but simplicity isn't everything.
The transfer of copyright usually happens to prevent a fragmentation of copyright holders inside a GPLed project. You usually agree to it because of your work being little compared to the whole. The question whether you can continue to use your committed code under a different license or not is irrelevant because you couldn't use the larger part of GPLed code under a different license in any case.
As an author of a web toolkit I must say that it just seems wrong to me. As much as I would be pissed if someone would earn money by slapping a nice GUI around my tool, I don't think it's reasonable for me to expect someone to release the source code to their website just because they use my tool in it. That would be unfair and IMHO seriously reducing the number of people willing to work with/on my tool.
There just is no distribution of code, 99% percent of that web site's users will just don't care about the code, the other ones can just download the toolkit themselves which hopefully also includes the fancy stuff the website owner put into his site.
This is why I will either continue to use GPL v2 or add an permission to run a website without giving away the code to the GPL v3.
The article is surely a good entry to developing java webapplications with "AJAX" (Can't someone invent a better name?).
For me (I am the author of japano, an MVC/JSP engine also containing dynamic javascript integration features), the following additional principles are were important:
Usability first. Don't use AJAX without a decent fallback. Don't use AJAX just because you can. Use semantic, standard-conform HTML/CSS layouts.
Keep it simple. No object brokering or other fancy things. JSON transports data. Javascript requests and browser requests uses the same mechanisms.
Integrate. AJAX has quite some complexity overhead. Try to minimize that complexity by offering framework assistance. Japano offers two different AJAX mechanisms. Javascript views, and Partial updates.
The problem with the local governments reacting to local desasters is that these disasters tend to destroy the infrastructure needed to react to them - so help from the outside is needed.
Congrats - you're propagating a newly created urban legend designed by right-wing groups to pretend that Bush really *was* on top, and it was the evil liberal's fault!
This kind of "urban legends" is better described with another word: propaganda
Is there anything in the GPL, or in the FSF contract where an author signs over rights to his/her work, that prevents the FSF from someday licensing that author's work as a commercial fork?
When you license software you wrote under the GPL you keep the copyright on that software. So it's only you who can release the software under a different license.
FSF/GNU projects require you to sign over the copyright on patches.
Let's ignore that the FSF exists to "promote computer users' rights to use, study, copy, modify, and redistribute computer programs." (from the FSF Homepage) for a while.
Suppose the FSF would some day make up their minds and start releasing FooBar 1.1 under a non-free license.
The FSF owns the copyright on the FooBar1.1 project so nothing prevents them from doing so.
BUT FooBar1.0 is still licensed under the GPL so someone else will step in and maintain the free version. People will use the free FooBar1.0 branch and the FSF is out and earns nothing on FooBar1.1.
(See the XFree86 licensing changes for a similar, real world example of such dynamics)
But their actions have ALWAYS been honorable. Despite all the nonsense about "contamination", has anyone EVER had Sun sue them?
Well.. it was not Sun, but..
From The History of the GPL:
In the early years (1984 to 1988), the GNU Project did not have a single license to cover all its software. What led Stallman to the creation of this copyleft license was his experience with James Gosling, creator of NeWs and the Java programming language, and UniPress, over Emacs. While Stallman created the first Emacs in 1975, Gosling wrote the first C-based Emacs (Gosling Emacs) running on Unix in 1982. Gosling initally allowed free distribution of the Gosling Emacs source code, which Stallman used in early 1985 in the first version (15.34) of GNU Emacs. Gosling later sold rights to Gosling Emacs to UniPress, and Gosling Emacs became UniPress Emacs. UniPress threatened Stallman to stop distributing the Gosling source code, and Stallman was forced to comply.
I think this case history makes the fears of the GNU people understandable if not justified.
Ok. But BSD being "more" free is not really in dispute...
Depends how you look at it:
For example, the BSD license allows a derived program to be distributed without source code while the GPL does not. Arguing that this means the BSD license is generally "more free" ignores one basic principle of freedom: Your freedom ends where it limits the freedom of others. So what is more free for the developer means potentially less freedom for the users and other developers.
Oh I see - so if a commercial software vendor receives no income from sales they are still in a perfectly good financial position as they still have their information. I get it now!
Of course all people should be required to demand a minimum price for their work and not to use open or free software licenses to secure the profit of commercial software vendors. Otherwise they deserve to be disowned so that the poor software companies can take their work without following those pesky licenses.
Slashdot Mirror
yeah.. I don't really see the connection to COBOL either...
Good.. we germans control over all your printed stuff and cars then, the english control your rail-roads, etc etc.
Oh, the WWW was also invented by Tim Berners-Lee (english) while working at CERN, the European Particle Physics Laboratory in Geneva, Switzerland.
Who do you have to bribe for articles like this? And how much?
Or is there any other reason why an article submission for my GPLed webapplication framework gets rejected, but a ridiculously over-priced, closed-source, windows-only offering, whose main feature seems to be buzz-word compliance and marketing-droid BS, gets free PR?
*grrr*
++a : call a.next() and evaluate a
a++ : evaluate a and call a.next() then.
and I think we can agree that sane programs should use the same operator overloading for ++ in both cases.After reading the article I am left with the impression that Marc Andreessen has no real idea what he is talking about. First the article does neither mention JSP nor any of the other relevant technologies ( tapestry, velocity, struts etc. etc.). If Marc Andreessen wants to compare PHP to Java he should do it by comparing it to the different approaches which have many differences in target and complexity. He says Java is "arguably even harder to learn than C++" - again he seems to compare C++ core language to Java plus every library in existence - otherwise I can't understand how he comes to this conclusion.
Let's focus on PHP vs. JSP. I have done websites in both JSP and PHP. I did not really like PHP. The function naming is a complete mess, it's rather hard to get a decent structure into it and I hate languages that use special charactes to prefix variables. For me PHP is only advisable for websites with a really low functional complexity.
JSP is quite nice when used correctly - which would include renouncing scripting expression inside the JSP documents. ( there is no real difference between <?php echo $foo ?>, <?= $foo ?> and <% out.print(foo) %>, <%= foo %> ). Instead just use custom tags and EL expressions, mix it with some MVC features and you have a decent structure, a clean separation of code and layout with a nice declarative interface. You may want to add some autogeneration of descriptor files to ease development. (or just use japano my webapplication framework which coincidentially contains all that features ;)
Yes, it is a little more complicated than JSP, but simplicity isn't everything.
The transfer of copyright usually happens to prevent a fragmentation of copyright holders inside a GPLed project. You usually agree to it because of your work being little compared to the whole. The question whether you can continue to use your committed code under a different license or not is irrelevant because you couldn't use the larger part of GPLed code under a different license in any case.
This is why I will either continue to use GPL v2 or add an permission to run a website without giving away the code to the GPL v3.
For me (I am the author of japano, an MVC/JSP engine also containing dynamic javascript integration features), the following additional principles are were important:
1. Don't
The problem with the local governments reacting to local desasters is that these disasters tend to destroy the infrastructure needed to react to them - so help from the outside is needed.
audiophile, n: Someone who listens to the equipment instead of the music.
Zorn is german for "anger, rage"
FSF/GNU projects require you to sign over the copyright on patches. Let's ignore that the FSF exists to "promote computer users' rights to use, study, copy, modify, and redistribute computer programs." (from the FSF Homepage) for a while.
Suppose the FSF would some day make up their minds and start releasing FooBar 1.1 under a non-free license. The FSF owns the copyright on the FooBar1.1 project so nothing prevents them from doing so. BUT FooBar1.0 is still licensed under the GPL so someone else will step in and maintain the free version. People will use the free FooBar1.0 branch and the FSF is out and earns nothing on FooBar1.1. (See the XFree86 licensing changes for a similar, real world example of such dynamics)
From The History of the GPL:
I think this case history makes the fears of the GNU people understandable if not justified.For example, the BSD license allows a derived program to be distributed without source code while the GPL does not. Arguing that this means the BSD license is generally "more free" ignores one basic principle of freedom: Your freedom ends where it limits the freedom of others. So what is more free for the developer means potentially less freedom for the users and other developers.
The term "AJAX" is just a parasitic attempt to profit from a well-known and long-used technology without a common name.
So 5.04 means something like "April 2005"