CSS, HTML and Javascript should be optional components you *can* use to build web apps, not "the one way" because they're horrifically shitty for anything but simple use cases.
We have that. Its called "the internet", you can use many different protocols, content formats, and languages there. We call it "the web" when we use certain tecnologies, mainly HTTP, HTML, CSS, and JavaScript, but we don't need any magical change to allow us to use other technical choices.
The display property is in the CSS standard, not the HTML standard. You don't need the HTML standard to use it.
You need the HTML standard to understand that that the CSS standard should be applied to interpret the block of content contained by style tags in the HTML document, or referenced from the HTML document via a LINK tag with rel="stylesheet". The semantics of HTML, including the bits that link to or incorporate CSS stylesheets, are defined in the HTML standard.
Some of the inconsistencies between browsers stem from the fact that they assume different default properties (like margins) for specific elements.
Why would you "stop standardizing HTML" to fix this problem? I mean, the obvious fix for this problem is to explicitly specify the default style properties of standard elements. Which HTML5 does.
CSS3 allows to do some animation effects that are currently done in Javascript, but that's probably the best you will ever get. I don't think we will ever get completely get rid of Javascript, it has just become to integral to what people do on the web these days.
We may not get rid of JavaScript as a delivery vehicle for executable code, but there's no reason we couldn't isolate application developers from it, in a couple of ways: 1. Application languages that compile to JavaScript for delivery, or 2. Application languages that are either interpreted by JavaScript, or compiled to it after delivery, or 3. (And this is, in a sense, a subset of #2, but worth calling out on its own) an HTML profile for executable content that can be interpreted and/or compiled to JS by a JS script.
#1 and #2 are common now, and I think I've seen examples of #3.
You just need to provide some good pragmatics to the language (as in, it this piece of your code runs longer than half a second at a time, it will get killed mercilessly). Good pragmatics is what many of the sandboxed solutions miss.
I won't agree that that's all that is required, but there is no such thing as universally good pragmatics; pragmatics like this that would be good are intensely use-specific (and the web is general purpose), so there's no such thing as "good pragmatics" for a general-purpose web language. You could have dozens of narrow-focus, special purpose ones, but then you'd also need to have a common way of delivering them that would be useful if you wanted to use them on the web. Like tons of other things these days, this calls more for something that compiles to Javascript than something that replaces Javascript.
HTML5 is the response by a bunch of whiners that normal xhtml is "too hard."
No, its not. The issue wasn't that XHTML was too hard, it was that it wasn't backwards-compatible with most existing HTML on the web. (There might have been a concern with verbosity of the serialization, as well, though I don't know that it was a motivation.) WHATWG HTML Living Standard/W3C HTML5 makes HTML well-defined in a way which is consistent with most of the existing HTML in the wild and the way most browsers were handling HTML.
XML serialization of HTML sucks. It's verbose, and it's ugly. But it's effective because it's well defined and it leaves very little room for interpretation.
WHATWG HTML provides an unambiguous parsing of HTML that leaves no room for interpretation, without the verbose ugliness of XML. Of cousre, if you have an irrational attachment to XML, WHATWG HTML also provides an XML serialization as opposed to the HTML form. Feel free to use it.
Wikipedia was using a non-Oracle fork of MySQL (a Facebook maintained fork of MySQL 5.1) and moved to a different non-Oracle fork (MariaDB). The comment about Oracle not being a friend of OSS seems to be a non-sequitur.
Unless your WinXP-reliant software is also needs access to the internet.
Considering this particular summary is in regards to medical software, I certainly hope that's not the case.
There is certainly medical software that needs to communicate over the internet; its very commonly important for electronic health record (EHR) software and medical billing software (and, quite often, almost anything else is going to tie into one or both of those systems.)
What will be news is when someone builds something that goes beyond "concept" to "flyable aircraft that demonstrates in-flight transition between rotary- and fixed-wing flight.) But a stopped rotor concept is not much in the way of news.
Did you not later state that the asteroid was a straw man?
No, I have consistently stated that the asteroid wasn't a straw man. Because it wasn't.
Did you not also point at scarcity not crashing the market with an example?
If I had, it wouldn't be relevant to the asteroid example (which was about unexpected surplus, which is the opposite of scarcity, crashing the market; OTOH, unexpected scarcity would also produce a problematic market disruption, and there are plenty of examples of that, but not by dropping the price of the used-as-currency commodity.)
And if you are referring to the example of Spain and its New World colonies, I was pointing to an example of unexpected surplus causing exactly the kind of market disruption the asteroid example was offered to illustrate.
My original post was not unjustified at all.
Yes, it was.
After you defended the person's asteroid argument, you agreed with my original points.
Now you're just imagining things.
Maybe we were both confused about whom was posting what?
GPL2 is fairly short, GPL3 works a bit harder to avoid loop holes that nobody though of in the 1980s.
GPL3 would be shorter if it actually viewed tivoization as a loophole and tried to close it, rather than viewing it as an essential feature that must be protected for business devices and a threat to software freedom which must be prohibited in consumer devices, thus necessitating dictating two separate sets of treatments for those markets, and verbiage defining the separate markets to which those treatments apply.
Right now the trend is to focus on the viral, strict portions of the GPL, which prevent people from using code if they don't want to share back. This trend probably started around the time of GPL3.0
Focus on the copyleft/viral nature of GPL started a long time before GPLv3.
Focus on market-specific restrictions on hardware devices incorporating code licensed under GPLv3 started around the time of GPLv3 (because GPLv3 was the first version to incoporate those restrictions.)
The GPLv3 requires that you be able to modify the running code as well. It could well be a security concern for, say, an ATM, if it has to have a user accessible way to modify the code it's running.
Because the FSF, in its wisdom, has apparently decided businesses might actually need to have tamper-proof devices, the "anti-tivoization" provisions of the GPLv3 exclude business devices and apply only to consumer devices ("consumer devices" are defined, however, rather broadly.)
Of course, one might question whether you really want your "free" software license to be directing allowable feature sets of hardware devices incorporating the software, and different allowable feature sets based on the target market.
It uses another GPL library, so it's already implied that it will be GPL code when it matures past being a bunch of functions sewn together just enough to test them. Why would I put a license on that?
Well, because you are, in fact, distributing the code now via the internet to the public, and therefore, by the same reason that it is "implied that it will be GPL code", probably required to include the GPL as its license now, or be in technical violation of the GPL.
Features like closed-source crap, hardware & platform lock-in? They can keep 'em.
Either: 1) The features prohibited to consumer (but not business) devices incorporating GPLv3 software are contrary to Software Freedom, and GPLv3 deliberately created a huge exception contrary to software freedom in one domain, or 2) The features prohibited to consumer (but not business) devices incorporating GPLv3 software are not contrary to Software Freedom, and the GPLv3 limits the free choice of users and suppliers for a reason unrelated to software freedom.
That you aren't interested in the features is irrelevant to software freedom.
Then he had to pick a license. The BSD license was already a well established license.
No, it wasn't. The 4-clause BSD license (which is substantially more restrictive than the more recent versions that people usually mean when they refer to the BSD license today) was first used in 1990; it hadn't existed for two years when Linus first released Linux, and it certainly wasn't a "well established" license. The 3-clause version seems to date from 1999. The 2-clause versions are, I believe, newer yet.
But he went with the GPL instead. Why?
Presumably because it was the single widely-known well-established free/open license at the time.
You can take BSD code and integrate them into a closed source product. But how does BSD promote open source software?
It promotes open source software by demonstrating that it works, even when it is released under a license where someone could take the whole thing, add some features, and close it up.
Successful permissive-licensed projects like PostgreSQL, Apache, etc., show that open source works, rather than just being something you go along with because you have to use some code that some upstream developer released under a license that forces their ideology onto anyone making derivatives of their code base.
The GPL, OTOH, is the license you use when you don't believe open source works, and think people need a gun to their head to adopt the model.
Until you find your own piece of software closed so you can't use it
How does that work again? I mean, I write software, I own the copyright, I release it under a permissive open-source license. Now, how does it ever become closed so that I can't use the software that I wrote and own the copyright to?
and a majority of users switch to that enhanced version by FooCorp.
Certainly, FooCorp (as well as BarCorp and BazCorp) can take my permissively licensed open-source work and make a derivative that is closed sourced (like, say, thousands of projects do with, say, SQLite, which goes beyond permissively licenseed open-source to being under a public domain declaration). And, maybe, more people use one of those (or at least, all of them collectively) than the the open source version. So what?
If there is a community of developers who value open source and the project it will remain a viable open source project (see PD and permissive open source projects like the xBSD operating systems, PostgreSQL, SQLite, etc.) And if you don't have that, a GPL-style copyleft license won't make it any more viable as an open source project.
A bunch of closed-source derivatives doesn't hurt that (indeed, a number of the makers of closed source derivatives may end up supporting the open-source project -- certainly that's definitely the case with SQLite.)
who defended your position and said that the asteroid was a straw man.
Correct.
You distinctly defended that person several times claiming that the asteroid was not a straw man.
Well, yes, as the particular criticism you made of their position was invalid.
(I've also, separately, in a direct response to the asteroid commenter, acknowledged that the point they made was valid and highlighted a real issue that exists with gold, as demonstrated more concretely by the Spanish colonial experience.)
As mentioned, I have no idea why you are defending someone that said you were wrong.
Because sometimes people who disagree with me make good and valid points, and sometimes people who attack people who are disagreeing with me do so in a manner which is unjustified.
No, I'm not wrong. Developers cannot sell Glass Apps, true. But I didn't say they could. What I did say is that they can sell online web applications for which the corresponding Glass App is free. The Glass App still can drive revenue, by making the paid app it supports more valuable to users.
"Does not have a file in the project root directory that a computer program can identify as a license" is not equivalent to "is not made available under an open source license".
Slashdot Mirror
We have that. Its called "the internet", you can use many different protocols, content formats, and languages there. We call it "the web" when we use certain tecnologies, mainly HTTP, HTML, CSS, and JavaScript, but we don't need any magical change to allow us to use other technical choices.
You need the HTML standard to understand that that the CSS standard should be applied to interpret the block of content contained by style tags in the HTML document, or referenced from the HTML document via a LINK tag with rel="stylesheet". The semantics of HTML, including the bits that link to or incorporate CSS stylesheets, are defined in the HTML standard.
Why would you "stop standardizing HTML" to fix this problem? I mean, the obvious fix for this problem is to explicitly specify the default style properties of standard elements. Which HTML5 does.
We may not get rid of JavaScript as a delivery vehicle for executable code, but there's no reason we couldn't isolate application developers from it, in a couple of ways:
1. Application languages that compile to JavaScript for delivery, or
2. Application languages that are either interpreted by JavaScript, or compiled to it after delivery, or
3. (And this is, in a sense, a subset of #2, but worth calling out on its own) an HTML profile for executable content that can be interpreted and/or compiled to JS by a JS script.
#1 and #2 are common now, and I think I've seen examples of #3.
Its a W3C Candidate Recommendation that is scheduled to reach Recommendation status next year.
You are likely confusing the WHATWG HTML Living Standard (which has no number) with W3C HTML5. They are two different things.
There may or may not be an HTML 6, but there is already an HTML 5.1 in development.
I won't agree that that's all that is required, but there is no such thing as universally good pragmatics; pragmatics like this that would be good are intensely use-specific (and the web is general purpose), so there's no such thing as "good pragmatics" for a general-purpose web language. You could have dozens of narrow-focus, special purpose ones, but then you'd also need to have a common way of delivering them that would be useful if you wanted to use them on the web. Like tons of other things these days, this calls more for something that compiles to Javascript than something that replaces Javascript.
No, its not. The issue wasn't that XHTML was too hard, it was that it wasn't backwards-compatible with most existing HTML on the web. (There might have been a concern with verbosity of the serialization, as well, though I don't know that it was a motivation.) WHATWG HTML Living Standard/W3C HTML5 makes HTML well-defined in a way which is consistent with most of the existing HTML in the wild and the way most browsers were handling HTML.
WHATWG HTML provides an unambiguous parsing of HTML that leaves no room for interpretation, without the verbose ugliness of XML. Of cousre, if you have an irrational attachment to XML, WHATWG HTML also provides an XML serialization as opposed to the HTML form. Feel free to use it.
There is no language in which amateurs should be writing code that runs on client's machines.
Wikipedia was using a non-Oracle fork of MySQL (a Facebook maintained fork of MySQL 5.1) and moved to a different non-Oracle fork (MariaDB). The comment about Oracle not being a friend of OSS seems to be a non-sequitur.
There is certainly medical software that needs to communicate over the internet; its very commonly important for electronic health record (EHR) software and medical billing software (and, quite often, almost anything else is going to tie into one or both of those systems.)
Unless your WinXP-reliant software is also needs access to the internet.
See the Sikorsky "X-Wing" modification of the S-72 RSRA.
What will be news is when someone builds something that goes beyond "concept" to "flyable aircraft that demonstrates in-flight transition between rotary- and fixed-wing flight.) But a stopped rotor concept is not much in the way of news.
Right, because the content of the GPL changed at exactly the time of GPLv3.
But the copyleft part of it wasn't what changed, and wasn't the focus of the new negativity.
No, I have consistently stated that the asteroid wasn't a straw man. Because it wasn't.
If I had, it wouldn't be relevant to the asteroid example (which was about unexpected surplus, which is the opposite of scarcity, crashing the market; OTOH, unexpected scarcity would also produce a problematic market disruption, and there are plenty of examples of that, but not by dropping the price of the used-as-currency commodity.)
And if you are referring to the example of Spain and its New World colonies, I was pointing to an example of unexpected surplus causing exactly the kind of market disruption the asteroid example was offered to illustrate.
Yes, it was.
Now you're just imagining things.
No, it was just you.
GPL3 would be shorter if it actually viewed tivoization as a loophole and tried to close it, rather than viewing it as an essential feature that must be protected for business devices and a threat to software freedom which must be prohibited in consumer devices, thus necessitating dictating two separate sets of treatments for those markets, and verbiage defining the separate markets to which those treatments apply.
Focus on the copyleft/viral nature of GPL started a long time before GPLv3.
Focus on market-specific restrictions on hardware devices incorporating code licensed under GPLv3 started around the time of GPLv3 (because GPLv3 was the first version to incoporate those restrictions.)
Because the FSF, in its wisdom, has apparently decided businesses might actually need to have tamper-proof devices, the "anti-tivoization" provisions of the GPLv3 exclude business devices and apply only to consumer devices ("consumer devices" are defined, however, rather broadly.)
Of course, one might question whether you really want your "free" software license to be directing allowable feature sets of hardware devices incorporating the software, and different allowable feature sets based on the target market.
Well, because you are, in fact, distributing the code now via the internet to the public, and therefore, by the same reason that it is "implied that it will be GPL code", probably required to include the GPL as its license now, or be in technical violation of the GPL.
Either:
1) The features prohibited to consumer (but not business) devices incorporating GPLv3 software are contrary to Software Freedom, and GPLv3 deliberately created a huge exception contrary to software freedom in one domain, or
2) The features prohibited to consumer (but not business) devices incorporating GPLv3 software are not contrary to Software Freedom, and the GPLv3 limits the free choice of users and suppliers for a reason unrelated to software freedom.
That you aren't interested in the features is irrelevant to software freedom.
No, it wasn't. The 4-clause BSD license (which is substantially more restrictive than the more recent versions that people usually mean when they refer to the BSD license today) was first used in 1990; it hadn't existed for two years when Linus first released Linux, and it certainly wasn't a "well established" license. The 3-clause version seems to date from 1999. The 2-clause versions are, I believe, newer yet.
Presumably because it was the single widely-known well-established free/open license at the time.
It promotes open source software by demonstrating that it works, even when it is released under a license where someone could take the whole thing, add some features, and close it up.
Successful permissive-licensed projects like PostgreSQL, Apache, etc., show that open source works, rather than just being something you go along with because you have to use some code that some upstream developer released under a license that forces their ideology onto anyone making derivatives of their code base.
The GPL, OTOH, is the license you use when you don't believe open source works, and think people need a gun to their head to adopt the model.
How does that work again? I mean, I write software, I own the copyright, I release it under a permissive open-source license. Now, how does it ever become closed so that I can't use the software that I wrote and own the copyright to?
Certainly, FooCorp (as well as BarCorp and BazCorp) can take my permissively licensed open-source work and make a derivative that is closed sourced (like, say, thousands of projects do with, say, SQLite, which goes beyond permissively licenseed open-source to being under a public domain declaration). And, maybe, more people use one of those (or at least, all of them collectively) than the the open source version. So what?
If there is a community of developers who value open source and the project it will remain a viable open source project (see PD and permissive open source projects like the xBSD operating systems, PostgreSQL, SQLite, etc.) And if you don't have that, a GPL-style copyleft license won't make it any more viable as an open source project.
A bunch of closed-source derivatives doesn't hurt that (indeed, a number of the makers of closed source derivatives may end up supporting the open-source project -- certainly that's definitely the case with SQLite.)
Correct.
Correct.
Well, yes, as the particular criticism you made of their position was invalid.
(I've also, separately, in a direct response to the asteroid commenter, acknowledged that the point they made was valid and highlighted a real issue that exists with gold, as demonstrated more concretely by the Spanish colonial experience.)
Because sometimes people who disagree with me make good and valid points, and sometimes people who attack people who are disagreeing with me do so in a manner which is unjustified.
No, I'm not wrong. Developers cannot sell Glass Apps, true. But I didn't say they could. What I did say is that they can sell online web applications for which the corresponding Glass App is free. The Glass App still can drive revenue, by making the paid app it supports more valuable to users.
"Does not have a file in the project root directory that a computer program can identify as a license" is not equivalent to "is not made available under an open source license".