> it defines functions or methods and either loads an external script (from html) or is loaded as one,
Under this particular term, I can't think of a single web site that I have written which would be considered to be "trivial".
That said, I appreciate the underlying concern - that without significant changes to the browser, you have little to no fine-grained control over what is run by that browser. While there are add-ons which block scripts from running entirely, there are no add-ons that I know of [0] which would allow you to run a user-provided alternative to a script specified by the web page.
[0] I can, actually, think of way to potentially work around this with a combination of greasemonkey and NoScript - block certain scripts and provide your own functions which mirror those provided by the blocked scripts. Would make for an interesting project.
I would upvote your comment, but I think the javascript HN uses for that might qualify as nontrivial, and I don't want to taint my computer with nonfree software.
> While there are add-ons which block scripts from running entirely, there are no add-ons that I know of which would allow you to run a user-provided alternative to a script specified by the web page.
It's a decidedly non-trivial problem problem — how are we identifying a script? Some sites (FB used to, at least) often serve the same scripts from different hostnames (based on what CDN you're connected to, I believe). What happens if the same script (say, jQuery!) is downloaded from two entirely different sites? What if I change some comment, is that still the same script? What if I minify it and variable names change? What if we allow some small semantically equivalent changes? What if the script is non-cacheable and changes on every load (some are!), how do we replace that?
Presto-based desktop releases of Opera would allow you to modify code (and HTML and CSS) on a page identifying it by URL, but I don't know of anything else comparable.
I don't really understand this article. JavaScript is less of a trap than regular software: the code is running in a much less capable sandbox. This means that unlike unfree software which behaves against the users' rights, or against the users' will, a browser app asks you permissions for many obtrusive things (webcam/mic access, location, etc).
But the software is still proprietary. It's not just about the software doing nefarious things, but about giving the user freedom to modify and share the software.
JavaScript code is more of a trap because it runs without the user having to do anything! Just by visiting a website, an application is transparently downloaded and run on your computer. Most people don't even think of what is going on when they visit a web page in a modern web browser. System software needs to be explicitly installed by the user.
Try disabling JavaScript or using the Mozilla browser extension LibreJS and notice how much of the web breaks. That's the state of free software on the web. It's terrible.
I'd rather use a proprietary software running within an open sandbox I know and trust which asks me permissions for anything it does, rather than an open source software which can do whatever it wants anytime it wants.
For Stallman and the FSF, it's not (just) about the practical dangers of unknown software running about your machine; it's about the moral right to modify and reuse that software.
Even taking that pursuit as a given, I still don't follow the point of this. 99% of the JavaScript I use is intimately bound up with server-side software that I don't have access to. What's the practical value in having half a free app running in my browser when it's useless without the proprietary half on the server?
They is why they also criticize the trend for closed and unaccountable server-side applications (in other publications / articles). The evolution of the GPL is supposed to go in the direction of fighting this trend (although it's very difficult, for a number of reasons).
Stallman and the FSF are not everyone's cup of tea, but they are extremely coherent about their philosophy. They (over)think about how we interact with technology, lay it bare for everyone else to see, and then propose alternative ways. Not everything Stallman says or does can be practiced in everyday life (among others, he runs a Chinese-made laptop that only contains hardware that is fully documented, and spends quite a lot of time sleeping on other people's sofas as he travels around the world to spread his FSF gospel), but it's usually impossible to attack his position on purely-rational grounds.
Stallman's commitment to..."open source"? Sir you better hide fast. He is coming for you!
On a serious note Stallman continuously points out that he does not support the open source movement and that free/libre software and open source software are two different concepts.
> On a serious note Stallman continuously points out that he does not support the open source movement and that free/libre software and open source software are two different concepts.
He does frequently do this, but I don't think its actually substantively true -- Free Software and Open Source software are basically identical concepts, however, the FSF has a strong commitment to combating non-Free software while the open source movement is more about promoting open source software. The big difference in the movements isn't really "Free" vs. "Open Source", its opposing things that don't meet our ideal (with promoting certain things that do meet the ideal as sometimes an instrumental means to that) vs. promoting things that do meet our ideal (with opposing certain things that don't as sometimes an instrumental means to that).
No, it's not just about "opposing non-Free software in addition", at least how they (GNU) see it.
E.g.:
In practice, open source stands for criteria a little weaker than those of free software. As far as we know, all existing free software would qualify as open source. Nearly all open source software is free software, but there are exceptions. First, some open source licenses are too restrictive, so they do not qualify as free licenses. Fortunately, few programs use those licenses.
Second, and more important, many products containing computers (including many Android devices) come with executable programs that correspond to free software source code, but the devices do not allow the user to install modified versions of those executables; only one special company has the power to modify them. We call these devices “tyrants”, and the practice is called “tivoization” after the product where we first saw it. These executables are not free software even though their source code is free software. The criteria for open source do not recognize this issue; they are concerned solely with the licensing of the source code.
"Open Source" terminology emphasizes its technical superiority as a development method.
"Free Software" terminology emphasizes its ethical necessity to maintain a free society.
One is technical, one is political/ideological. Open source advocates don't care about politics, Free software advocates think technical superiority is unimportant in a non-free society.
I happen to believe that open source is mixed up with social or political issues, because open source inherently increases a user's personal freedom (physically and meaningfully), whereas closed source is inherently wrapped up with issues of legal protection of intellectual work.
Whether or not a user even knows of this tension, or of the open/closed source status of the code they run, does not exclude whether they may experience benefits. I think this because open-sourcing code does not only increase one's own personal freedom (which is unlikely to be exercised alone due to the magnitude of the task), but more realistically it allows the opportunity for an outside skilled individual or group to be looking over the code, and the benefits can be transferred to all users of the software.
It is akin to a person's relationship to the law, where legal writing is not designed for common consumption, but professionals or organizations may digest and disseminate the data to interested groups. While much of legal code may be away from the searchlights of society or its groups, at the very least, when the situation calls upon it, we may look when we want to. It is not requested on a need-to-know basis where we have burden of proof.
"Free Software and Open Source software are basically identical concepts"
No, they're not. Software released under the BSD and GPL licenses would both be considered "open source", but only the latter is Free (per RMS' and FSF's definitions of "Free"), for many significant reasons.
> No, they're not. Software released under the BSD and GPL licenses would both be considered "open source", but only the latter is Free (per RMS' and FSF's definitions of "Free"), for many significant reasons.
Well, no. All three versions of the BSD license are recognized by the FSF as "free software licenses"; only two of them are OSI-approved "Open Source" licenses,
1. The original four-clause license, which is neither an OSI approved Open Source license (apparently its never been submitted for review -- OSI, unlike FSF, does its reviews based on submissions, rather than on its own initiative) [0] but is an FSF-recognized Free Software license. [1]
2. The three-clause BSD license, which is both an OSI approved Open Source license [2] and recognized by the FSF as "a lax, permissive non-copyleft free software license, compatible with the GNU GPL." [3]
3. The two-clause BSD license, which is both an OSI approved Open Source license [4] and recognized by the FSF as "a lax, permissive non-copyleft free software license, compatible with the GNU GPL." [5]
> Google Docs downloads into your machine a JavaScript program which measures half a megabyte, in a compacted form that we could call Obfuscript because it has no comments and hardly any whitespace, and the method names are one letter long. The source code of a program is the preferred form for modifying it; the compacted code is not source code, and the real source code of this program is not available to the user.
I love Stallman and what he stands for, but this is a bit misleading. Shipping obfuscated source code is NOT the same thing as shipping some prepackaged binary. I can still dig through the Google Docs source and pull out anything I find valuable. No one is going to stop me. Furthermore, obfuscation of JavaScript is intended to reduce network load for Google. I mean, yes, obfuscation has a side-effect of "limiting interested parties," but to reiterate my point: it's not like Google is sending me PageRank as obfuscate C code each time I load their homepage.
>Shipping obfuscated source code is NOT the same thing as shipping some prepackaged binary.
Yes, it is. Obfuscated source code, like a binary, is not the corresponding source code.
"The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities."
Absolutely not! Just because it doesn't jive with GPL doesn't mean JS obfuscation is no longer source. It's not like compiling a C program without debugger symbols. It's the same high-level JS language, it's just "harder to read." The point of saying it's "not source code" is just wrong.
> Absolutely not! Just because it doesn't jive with GPL doesn't mean JS obfuscation is no longer source.
It's not the source code, because its not the first code produced before any automated transformation. Its an intermediate form that happens to still remain text, and remain legal code in the same language as the source code.
You can use a disassembler to get source code out of your binary. If I distribute my binaries with corresponding assembly source (which I obtained from a disassembler), am I distributing my source code?
> Shipping obfuscated source code is NOT the same thing as shipping some prepackaged binary. I can still dig through the Google Docs source and pull out anything I find valuable.
If thats the case then you can make the case that any software is open source. After all you can run your favorite program through a debugger and get all the machine calls. And someone can dig through them and convert it to C. From a human pov, minification isn't all that different from compilation.
Richard Stallman had a frustrating experience thirty years ago when he couldn't debug a software issue for lack of access to the source code. Since then he has used "evil" to mean anything that impedes programmers' ability to read source code with the original debugging symbols, regardless of whether those programmers are working on evil products.
Stallman's critiques of proprietary software are much more well-reasoned than "once I had trouble debugging an issue in a closed-source software project".
You two seem to be talking about different things. Motivating experiences are different than the reasons we use to persuade other people to really to our cause.
Heh, a lot of it is a generational thing. Back in the 90's, many if not most programmers would have passionately agreed with every word of this. Today, for younger programmers who take open-source for granted... it just seems like the incoherent ramblings of that old uncle who rants about Obama at every family gathering.
At any rate, where this is coming from would make a lot more sense if you'd come up in the 80's and 90's, and remembered what it was like before open-source gained a serious foothold.
> Heh, a lot of it is a generational thing. Back in the 90's, many if not most programmers would have passionately agreed with every word of this. Today, for younger programmers who take open-source for granted... it just seems like the incoherent ramblings of that old uncle who rants about Obama at every family gathering.
I think that drastically overstates the support programmers as a class have ever had for the Stallman/FSF view that tools to combat the use of non-Free software are a moral imperative, though I do think that that extremist position of actively combating non-Free software did seem, if not a moral imperative, at least to be important instrumentally to the promotion of Free/open source software before the pragmatic case for open source was broadly accepted by much of the industry.
No, they aren't. Both the pragmatic benefits and the perceived (by some) moral imperative stem from the same source, but neither the perceived moral imperative nor the pragmatic benefits that motivate self-interested actors to participate in open source are dependent on the other.
> that old uncle who rants about Obama at every family gathering
I'm still trying to explain to him that Obamacare was originally proposed by the Heritage Foundation as an alternative to "Hillarycare." Sigh.
The software world has changed a lot in the last 30 years. There are almost as many users directly using a Linux kernel-based operating system every day (Android) as there are Windows users worldwide, and Android will almost certainly take the lead from Windows by the end of 2015. I think this would've been unfathomable to the handful of people who knew what Free Software (in the rms sense) back in the 1980s and 1990s.
>I think this would've been unfathomable to the handful of people who knew what Free Software (in the rms sense) back in the 1980s and 1990s.
Err, back in the mid-to-end nineties far from being unfathomable, a widespread belief was that each year (or 'soon') would be the year of "Linux on the Desktop" and Linux overthrowing Windows.
I am just trying to understand the difference. But why not consider Javascript extension of server side code. I don't think, anybody is stopping use of websites just because their back-end is not open source.
Is it because we own our desktop and we don't allow non-free code to execute on our machines? If not then it is just issue of proximity, your laptop vs distant data center. If it is more philosophical point that we should not use non-free software then using website running on closed source back-end is as much a problem as obfuscated Javascript.
There are plenty of people choosing not to use certain services because of the politics of their companies, business models, and yes software.
The calculus changes when you go from client to server software, but licensing is intimately tied to data ownership and portability.
I often don't subscribe to FSF's philosophy, but the issues they're generally concerned with do enter into my decisions about what services I use and/or trust.
I actually asked Stallman about this once at a talk. It is precisely because we own our desktop. The analog he used was a food truck. It's fine to eat something from a food truck that somebody else prepares, even if there's a secret sauce you don't know about. The issue is being given the food truck and then being told that you must still use the sauce whose contents are opaque to you.
That being said, I don't really care much about using non-GPL programs. But that's the rationale.
Your recitation of his response does not address the OP's point, and my smarmy comment was downvoted.
So, let's see if we can work up this wishy-washy analogy a bit.
I like to eat food. (I like to use software.)
Much of the food I eat is prepared by vendors who employ 100% documented citizens or immigrants with valid visas. (Much of the software I use is 100% Free.)
Some of the vendors employ undocumented immigrants. (Some of the software I use contains nonFree components.)
My ability to get this food from these vendors depends on a number of other vendors - even a simple sandwich needs bread, meat, vegetables and condiments all sourced from and delivered by companies that may or may not employ undocumented immigrants.
I may purchase a completely prepared meal and eat it at home. (I may install and run boxed software locally on my machine.) I may purchase ingredients and prepare a meal from scratch. (I may obtain source code and locally build software to run on my machine.) I may purchase both raw ingredients and some pre-cooked food to take on a picnic. (Modern software distribution is complex, and "using a website" is a vague reference umbrella.)
In each of these scenarios, to eat my desired meal, I may need to source an ingredient produced by a complex system chain which may or may not have involved undocumented immigrants. Tracking this information down for every ingredient is tedious, but I agree should absolutely be possible.
I could prepare all of my meals myself, in my own kitchen, and source all of the raw ingredients from a small number of vendors whom I trust. I would probably have a limited number of basic ingredients to work with at the beginning. I would probably be able to produce reasonably healthy, functional meals. I would not be able to produce a rich menu that appealed to a variety of tastes, however. (A basic GNU system is pretty functional but you've got to wire up most things yourself.) I would have to work with these vendors frequently and would spend much more time managing the ingredients in my kitchen and preparing meals. I would also likely be limited in what I could produce by my locality and kitchen equipment. (Data must be created locally and hardware must be self-managed.)
I might trust these same vendors to prefabricate side dishes (system libraries) or larger heat-at-home dishes (application source bundles) that I integrate into my day-to-day meals. I may gain some variety because they can prepare dishes that I do not have the skill or kitchen equipment to prepare myself. (The trust that I confer on these vendors for not using undocumented immigrant labor does not prevent me from contracting a case of salmonella. [Heartbleed.])
I can get food in many forms from many varieties of vendors - delivered meals, take-out meals from a restaurant eaten at home, sit-down meals at a restaurant, meals from a food truck eaten on a nearby patio, meals from a food truck eaten at home... (Apps, desktop, websites, servers. Simply browsing the modern web means code runs in response to your every input on hundreds of machines around the globe.)
Sometimes my act of eating employs undocumented immigrants. Crap.
The code that generated the resource you're viewing, regardless of script content, may not be Free. The code running the server may not be Free, and that might not be part of the details of the transmission. There is probably plenty of nonFree code in the hardware that got your packets there and back.
Of all the things in the world to be concerned about, running non-GPL'd JavaScript in my browser is far enough down my list that writing this comment bumps me well over my lifetime quota for the issue.
This makes me wonder what is the "default" license that applies to all that minified, not labelled anyhow JS code fetched from random CDNs (this especially applies to ADs)... If JS is software, is it even legal to browse the web without JS blocking?
No idea why you're downvoted, because your point is pretty much valid. There are no software licenses for many sites, yet they are full-fledged pieces of software. I guess, this is legally grey area, that nearly no one bothers about.
Unlicensed JS has the same legal status as unlicensed pictures. That is, there is an temporary implied permission if the content (website) is intended to be accessed by the public, and that permission is normally extended to intermediate caches under specific circumstances.
How that work more precisely depend on where you live and what legal framework is in place.
Open source/free/libre software is a great idea, but a lot of JS code out there is nontrivial, useful and incredibly narrow in scope. Compare it to a build script: it may be relatively complex, yet so specific to its particular use case that it is not really useful to anyone to open source it. I think this is much the case with Javascript on the web. Some websites may have genuinely useful nontrivial code full of their own domains and site-specific classes and IDs, and it's not worth anything to anyone else, but it qualifies as nontrivial nonfree and now deserves to be blocked!
Defining "nontrivial" is probably impossible, and the attempt looks a bit clumsy: making a network request apparently instantly qualifies you as non-trivial, even though your browser probably made a bunch of network requests for static content just to load the page. Want to load a sound to play with the Web Audio API? You now need to open source your Javascript code and provide a correct license to avoid blocking. The given description also means use of obj[prop] (often used to mimic a hashmap, thereby arbitrarily disqualifying certain data structures) or loading an external script via <script src="..."></script> (thereby disqualifying certain kinds of optimisation or organisation) count you as "nontrivial".
How can this ever be objectively determined? And if the punishment is blocking then how is it ever going to be fair?
In addition to the "too-tailored" issue, another problem with code reuse is that Javascript doesn't have any (good && standard) ways to handle packages, dependencies, or (partly the browsers' fault) load order.
JavaScript is really easily "openable." It's actually really easy to run most of it through a beautifier. Take even something as insane as the contents of http://jsbin.com/OhisIQAW/1/source (uses nothing but symbols to run `alert("I love you.")`) and the magic becomes a lot more visible.
Running the first statement will give you an object filled with numbers 0-9 and letters a-f. The second statement, when run, outputs the string "constructor" by messing with references to the first object.
With a little bit of dedicated work, you can easily learn how anything is done in JS (well, besides Asm.js but that's beside the point) because it is, at its highest level, a language made to bridge between APIs. The only good thing about it is its widespread support and debuggability.
Oh, and the reasoning behind the "one character method names" mentioned: It's for minification of code, because we don't live in a world with infinite resources. If the FSF donated to me to keep my code "open" then I'd gladly keep it un-minified. Even when "obfuscated", though, it's pretty trivial to undo. [1]
Even asm.js is openable, it's pretty much just C with weird syntax - despite the name. Although almost all your type info's gone, which makes interpreting it a wee bit hard.
Although asm.js code is probably more C-like than LLVM IR is, given you have to decompile gotos back into ifs and loops, operations back into expressions, etc. (See page 23 onwards)
Almost all JavaScript is easily changeable and replaceable and oftentimes being able to figure out what it's doing is a matter of intuition and a little imagination. Even the code of Google Docs isn't really that hard to understand if you tilt your head and squint a little.
Obfuscation of C or otherwise native code can prevent people from modifying it or learning from it, and that is a problem to some people. However, that doesn't seem to exist in my view of JavaScript. It has never been a real problem as far as I have seen. I am open to seeing examples that I truly could not understand.
Some of the websites you access also run on non-free closed source code, too! This means the HTML they send to you is made by the smut that is closed-source software. The horror!
I'm all for open source as much as possible and whenever it's practical, but this blog post is akin to saying you shouldn't use C code on your system because there's non-free software written in C.
This isn't advocating that users avoid using javascript (although it suggests that users who avoid non-free software avoid non-free javascript as well, which should go without saying). It's just advocating that client-side javascript code be released as free software and gives guidelines for doing so.
This is the most ridiculous thing I've read today. If you are this adamant about it you might as well not use the internet at all. The vast, vast majority of the content of the web is not under a free license - javascript or otherwise.
And how is it any different than the server doing the exact same thing server side?
RMS's line of thinking here is an example of coming up with a rule (i.e. use Free/Libre software on your computer) that approximates the right thing to do to achieve a certain outcome (maintain control of your computing and avoid anti-features / being exploited by other people), and then applying that rule beyond where the original approximation was valid, to the extent that you are actually doing worse in terms of your original outcome.
I think the rational ordering will normally be:
FLOSS code, your server > Non-free code, your server > Unknown code, someone else's server
RMS seems to prefer:
FLOSS code, your server > Unknown code, someone else's server > Non-free code, your server
But unknown code on someone else's server can generally do far more in terms of anti-features than non-free code on your server. You can at least see how much data is being exfiltrated; they still have to worry about people reverse engineering the code and ruining their reputation if they do something too bad; you at least have the option to reverse engineer the data format or network protocol and replace their code with something you completely understand and control. If the data is on their server, you give up a tremendous amount of control.
I think some of the stuff RMS writes can serve as a cautionary tale about not letting rational heuristics that start with good intentions become dogma (as can the development of many religions which also probably started with good intentions) - hyperbolic thinking and using words like evil and wrong to describe something you think should be avoided always seems to lead to things getting taken too far.
Unless you'Ve written, or at least read the code yourself, and know there are no vulnerabilities, you can never really prevent "anti-features" or being exploited by other people. FLOSS doesn't magically prevent that from happening. It is less likely, but not impossible.
I think the case of JavaScript makes the ideology of the FSF very clear.
To me, closed source source software running in a sandbox is not a problem. The problem arises when (a) binary blobs that might do literally anything with your machine, are the only way to get certain things done, or (b) all hardware/software is so locked down that it is infeasible for anyone to do any hardware/software work without the blessing of the people in control of the hardware/software.
But to the FSF, the ability to modify and see the source code for software is fundamental, even when (a) and (b) don't apply. Perhaps they see opposing all non-free software as a kind of prophylactic measure. But I'm inclined to take them at their word that they care about "freedom" for its own sake. I wish they would drop the word, because what they are really arguing is that their notion of freedom is important. I get sick of their debating tactics which end up with saying "oh you don't have to use free software. But you wont' be free [by our definition]".
I've never seen a convincing argument for why sandboxed closed source software is a bad thing.
How familiar are you with Content Security Policy in browsers? It is designed precisely to protect user privacy.
I don't know what you mean by 2. Do you mean that sandboxes can break? If so that seems like a very weak point. The browser sandbox is very secure. Furthermore, similar critiques can be made of free software. Someone could sneak in malicious code into free software.
I fail to understand the conflation of "nonfree" with "nontrival."
If they are implying that the complexity of a snippet of code has some bearing on whether copyright protection applies, that is simply untrue. Forgive me for that strawman, but if they had told us we wouldn't have to guess.
I also sense a bit of fear mongering here. Half a megabyte of Javascript for a web page? Goodness, what could they be putting in there? And just a reminder, eval is evil. But why does that automatically qualify code as nontrivial? And how does that have anything to do with free software in the first place?
It's a legal distinction. Code which is 'trivial' or 'functional' cannot be copyrighted, so therefore the GPL doesn't apply.[1] The example given there is a Hello World dialog, but certainly I have written tons of DOM manipulation JS which is purely 'functional'. The contents of underlying HTML elements might have more copyright protection than the code.
(As to what it actually means, the case law is complex and the FSF would probably tell you to go ask a lawyer if you really want to know. Otherwise they will just offer you some arbitrary guideline, somewhat like their prohibition on linking to GPL C programs.)
No, its not. The article lays out precisely what the FSF's policy on triviality is, and it has no relation to any criteria in copyright law; that's not to say that "triviality" might be a good common-language term for a real consideration in copyright law that relates to whether something is an original work of authorship subject to copyright law, but to the extent it is it has nothing to do with the "triviality" at issue in the article here.
Actually, the article makes no explanation of why GNU is specially identifying "trivial" programs, nor how they came up with their guidelines. And neither do you.
So I will maintain that my copyright explanation is the best explanation, simply because (sofar) it's the only explanation.
> Actually, the article makes no explanation of why GNU is specially identifying "trivial" programs, nor how they came up with their guidelines.
I didn't say they did. I said that they say what their policy is, and I said that the policy they describe has no relation to any distinction in copyright law. A counterargument would be to show such a relationship, not to point out the absence of something that I never claimed was present.
This is an unproductive discussion, you're telling me that "you're wrong, but I don't know why".
In any case, "trivial" has a meaning under copyright law and therefore is very relevant to the GPL and whatever argument they're putting forth. That is all.
Yes. Largely because you keep inventing things I'm not saying to respond to. Such as:
> you're telling me that "you're wrong, but I don't know why".
No, I never said anything like that, and I stated quite directly how you were wrong.
> In any case, "trivial" has a meaning under copyright law
I don't think that's accurate, and the article you offered upthread to support that position does not -- in fact, the only uses of trivial in that article are to make the point that the legal concerns it discusses (idea vs. expression, and functional vs. creative works) are relevant in the same way to trivial (which it doesn't discuss as a term with legal significance) and non-trivial programs. And, in any case, the use of "trivial" in Stallman's post isn't connected to anything related to copyright law -- even if "trivial" was a term that had legal significance, that wouldn't make every use of "trivial" in regard to the GPL automatically related to that significance, especially when the sense of "trivial" being used is explicitly defined in the work in which it is used and isn't tied to the definition of any legally-significant distinction.
The fallacy here is the assumption that there is value in JavaScript in any form. As a long time web programmer, I can tell you I could care less about the freeness of your Javascript. I don't want to see it, read it, or spend one second trying to understand your smelly bowl of web code.
Considering that just about all JS code running out there is likely non-free (except pure library demos usually), one could just run NoScript if they really wanted to block such code without losing out on much. It also seems like replacing non-free applications with free counterparts is quite a bit more complex in such an environment because it'd still have to interact with the (typically) non-free server infrastructure. Not to mention that doing so might actually be (sadly) illegal.
> a JavaScript program nontrivial if:
> ...
> - calling methods with the square bracket notation
-something[key](x);
+var f = something[key];
+f.call(something, x);
RMS has said he doesn't mind using ATMs that use non-free software because he can't be responsible for what other people run on their devices. If we consider the website a service, where the javascript runtime is isolated to the web, then it is a similar situation - while it is evaluated on your device, the code itself is not installed on your computer, and it is sandboxed to have very limited access.
This only really applies to JS served from the website. Offline apps are a little more iffy, and browser extensions certainly qualify as installed software that you are running. Possibly less so in Chrome, where the extension API has some pretty hard limits on what extension code can access, but in Firefox you have the ability to do almost anything on the user's machine, which is why Mozilla reviews add-ons before approving them and has stricter guidelines for how they should behave.
The problem of comparing ATM's with web services is that banks are liable for the machine to work correctly. For software, users are commonly the one liable if something goes wrong and thus in need of liberty to balance responsibility with freedom.
If a bank websites JS software goes wrong and causes damages, whose fault is it? Is it the customer fault, maybe because his machine had broken hardware? Is it the bank, because its their service and they are responsible that all transactions are done correctly? Is it the JS developers who maybe introduced a bug?
When we can define whose responsibility it is, we can define if the user of the software/service need access to change, modify and distribute the code.
114 comments
[ 3.0 ms ] story [ 158 ms ] threadBut you still have to include those two paragraphs in all minified files...
Under this particular term, I can't think of a single web site that I have written which would be considered to be "trivial".
That said, I appreciate the underlying concern - that without significant changes to the browser, you have little to no fine-grained control over what is run by that browser. While there are add-ons which block scripts from running entirely, there are no add-ons that I know of [0] which would allow you to run a user-provided alternative to a script specified by the web page.
[0] I can, actually, think of way to potentially work around this with a combination of greasemonkey and NoScript - block certain scripts and provide your own functions which mirror those provided by the blocked scripts. Would make for an interesting project.
I don't want to run any Javascript in my browser at all, and I am grateful to HN for giving us that option.
I wish more websites would follow suit.
It's a decidedly non-trivial problem problem — how are we identifying a script? Some sites (FB used to, at least) often serve the same scripts from different hostnames (based on what CDN you're connected to, I believe). What happens if the same script (say, jQuery!) is downloaded from two entirely different sites? What if I change some comment, is that still the same script? What if I minify it and variable names change? What if we allow some small semantically equivalent changes? What if the script is non-cacheable and changes on every load (some are!), how do we replace that?
Presto-based desktop releases of Opera would allow you to modify code (and HTML and CSS) on a page identifying it by URL, but I don't know of anything else comparable.
We most certainly are, there's very little may be about it.
It's nice that we can see Javascript (albeit, often minimized) but we should never assume that visibility === free.
JavaScript code is more of a trap because it runs without the user having to do anything! Just by visiting a website, an application is transparently downloaded and run on your computer. Most people don't even think of what is going on when they visit a web page in a modern web browser. System software needs to be explicitly installed by the user.
Try disabling JavaScript or using the Mozilla browser extension LibreJS and notice how much of the web breaks. That's the state of free software on the web. It's terrible.
Stallman and the FSF are not everyone's cup of tea, but they are extremely coherent about their philosophy. They (over)think about how we interact with technology, lay it bare for everyone else to see, and then propose alternative ways. Not everything Stallman says or does can be practiced in everyday life (among others, he runs a Chinese-made laptop that only contains hardware that is fully documented, and spends quite a lot of time sleeping on other people's sofas as he travels around the world to spread his FSF gospel), but it's usually impossible to attack his position on purely-rational grounds.
And that's why I release all my code under the AGPL[1] license.
GPL 3 is just too weak.
[1] - https://en.wikipedia.org/wiki/Affero_General_Public_License
Dont worry,the EU will fix that! It will ask for "explicit consent" to run javascript in the browser ,just like that inane cookie law /s
On a serious note Stallman continuously points out that he does not support the open source movement and that free/libre software and open source software are two different concepts.
He does frequently do this, but I don't think its actually substantively true -- Free Software and Open Source software are basically identical concepts, however, the FSF has a strong commitment to combating non-Free software while the open source movement is more about promoting open source software. The big difference in the movements isn't really "Free" vs. "Open Source", its opposing things that don't meet our ideal (with promoting certain things that do meet the ideal as sometimes an instrumental means to that) vs. promoting things that do meet our ideal (with opposing certain things that don't as sometimes an instrumental means to that).
E.g.:
In practice, open source stands for criteria a little weaker than those of free software. As far as we know, all existing free software would qualify as open source. Nearly all open source software is free software, but there are exceptions. First, some open source licenses are too restrictive, so they do not qualify as free licenses. Fortunately, few programs use those licenses.
Second, and more important, many products containing computers (including many Android devices) come with executable programs that correspond to free software source code, but the devices do not allow the user to install modified versions of those executables; only one special company has the power to modify them. We call these devices “tyrants”, and the practice is called “tivoization” after the product where we first saw it. These executables are not free software even though their source code is free software. The criteria for open source do not recognize this issue; they are concerned solely with the licensing of the source code.
https://www.gnu.org/philosophy/open-source-misses-the-point....
https://www.gnu.org/philosophy/free-software-for-freedom.htm...
"Free Software" terminology emphasizes its ethical necessity to maintain a free society.
One is technical, one is political/ideological. Open source advocates don't care about politics, Free software advocates think technical superiority is unimportant in a non-free society.
Stallman's own words on this distinction in this video: https://www.youtube.com/watch?v=Ag1AKIl_2GM
Whether or not a user even knows of this tension, or of the open/closed source status of the code they run, does not exclude whether they may experience benefits. I think this because open-sourcing code does not only increase one's own personal freedom (which is unlikely to be exercised alone due to the magnitude of the task), but more realistically it allows the opportunity for an outside skilled individual or group to be looking over the code, and the benefits can be transferred to all users of the software.
It is akin to a person's relationship to the law, where legal writing is not designed for common consumption, but professionals or organizations may digest and disseminate the data to interested groups. While much of legal code may be away from the searchlights of society or its groups, at the very least, when the situation calls upon it, we may look when we want to. It is not requested on a need-to-know basis where we have burden of proof.
No, they're not. Software released under the BSD and GPL licenses would both be considered "open source", but only the latter is Free (per RMS' and FSF's definitions of "Free"), for many significant reasons.
[Update: I stand corrected. Thanks for that.]
Well, no. All three versions of the BSD license are recognized by the FSF as "free software licenses"; only two of them are OSI-approved "Open Source" licenses,
1. The original four-clause license, which is neither an OSI approved Open Source license (apparently its never been submitted for review -- OSI, unlike FSF, does its reviews based on submissions, rather than on its own initiative) [0] but is an FSF-recognized Free Software license. [1]
2. The three-clause BSD license, which is both an OSI approved Open Source license [2] and recognized by the FSF as "a lax, permissive non-copyleft free software license, compatible with the GNU GPL." [3]
3. The two-clause BSD license, which is both an OSI approved Open Source license [4] and recognized by the FSF as "a lax, permissive non-copyleft free software license, compatible with the GNU GPL." [5]
[0] http://opensource.org/licenses/BSD-3-Clause ("The original license used on BSD Unix had four clauses. [...] The four clause license has not been approved by OSI.")
[1] https://www.gnu.org/licenses/license-list.html#OriginalBSD
[2] http://opensource.org/licenses/BSD-3-Clause
[3] https://www.gnu.org/licenses/license-list.html#ModifiedBSD
[4] http://opensource.org/licenses/BSD-2-Clause
[5] https://www.gnu.org/licenses/license-list.html#FreeBSD
I love Stallman and what he stands for, but this is a bit misleading. Shipping obfuscated source code is NOT the same thing as shipping some prepackaged binary. I can still dig through the Google Docs source and pull out anything I find valuable. No one is going to stop me. Furthermore, obfuscation of JavaScript is intended to reduce network load for Google. I mean, yes, obfuscation has a side-effect of "limiting interested parties," but to reiterate my point: it's not like Google is sending me PageRank as obfuscate C code each time I load their homepage.
Yes, it is. Obfuscated source code, like a binary, is not the corresponding source code.
"The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities."
See: https://gnu.org/licenses/gpl.html
It's not the source code, because its not the first code produced before any automated transformation. Its an intermediate form that happens to still remain text, and remain legal code in the same language as the source code.
It definitely can be exactly isomorphic to just that via emscripten.
If thats the case then you can make the case that any software is open source. After all you can run your favorite program through a debugger and get all the machine calls. And someone can dig through them and convert it to C. From a human pov, minification isn't all that different from compilation.
Yeah, and you can use a dissasembler on a binary. Noone is going to stop you either.
Both cases put difficulties and slow down your understanding of the program AND are not the original code the programmers worked with.
At any rate, where this is coming from would make a lot more sense if you'd come up in the 80's and 90's, and remembered what it was like before open-source gained a serious foothold.
I think that drastically overstates the support programmers as a class have ever had for the Stallman/FSF view that tools to combat the use of non-Free software are a moral imperative, though I do think that that extremist position of actively combating non-Free software did seem, if not a moral imperative, at least to be important instrumentally to the promotion of Free/open source software before the pragmatic case for open source was broadly accepted by much of the industry.
I'm still trying to explain to him that Obamacare was originally proposed by the Heritage Foundation as an alternative to "Hillarycare." Sigh.
The software world has changed a lot in the last 30 years. There are almost as many users directly using a Linux kernel-based operating system every day (Android) as there are Windows users worldwide, and Android will almost certainly take the lead from Windows by the end of 2015. I think this would've been unfathomable to the handful of people who knew what Free Software (in the rms sense) back in the 1980s and 1990s.
Err, back in the mid-to-end nineties far from being unfathomable, a widespread belief was that each year (or 'soon') would be the year of "Linux on the Desktop" and Linux overthrowing Windows.
Is it because we own our desktop and we don't allow non-free code to execute on our machines? If not then it is just issue of proximity, your laptop vs distant data center. If it is more philosophical point that we should not use non-free software then using website running on closed source back-end is as much a problem as obfuscated Javascript.
Because it's entirely possible to write purely client-side web apps using Javascript that involve no server at all.
The calculus changes when you go from client to server software, but licensing is intimately tied to data ownership and portability.
I often don't subscribe to FSF's philosophy, but the issues they're generally concerned with do enter into my decisions about what services I use and/or trust.
That being said, I don't really care much about using non-GPL programs. But that's the rationale.
So, let's see if we can work up this wishy-washy analogy a bit.
I like to eat food. (I like to use software.)
Much of the food I eat is prepared by vendors who employ 100% documented citizens or immigrants with valid visas. (Much of the software I use is 100% Free.)
Some of the vendors employ undocumented immigrants. (Some of the software I use contains nonFree components.)
My ability to get this food from these vendors depends on a number of other vendors - even a simple sandwich needs bread, meat, vegetables and condiments all sourced from and delivered by companies that may or may not employ undocumented immigrants.
I may purchase a completely prepared meal and eat it at home. (I may install and run boxed software locally on my machine.) I may purchase ingredients and prepare a meal from scratch. (I may obtain source code and locally build software to run on my machine.) I may purchase both raw ingredients and some pre-cooked food to take on a picnic. (Modern software distribution is complex, and "using a website" is a vague reference umbrella.)
In each of these scenarios, to eat my desired meal, I may need to source an ingredient produced by a complex system chain which may or may not have involved undocumented immigrants. Tracking this information down for every ingredient is tedious, but I agree should absolutely be possible.
I could prepare all of my meals myself, in my own kitchen, and source all of the raw ingredients from a small number of vendors whom I trust. I would probably have a limited number of basic ingredients to work with at the beginning. I would probably be able to produce reasonably healthy, functional meals. I would not be able to produce a rich menu that appealed to a variety of tastes, however. (A basic GNU system is pretty functional but you've got to wire up most things yourself.) I would have to work with these vendors frequently and would spend much more time managing the ingredients in my kitchen and preparing meals. I would also likely be limited in what I could produce by my locality and kitchen equipment. (Data must be created locally and hardware must be self-managed.)
I might trust these same vendors to prefabricate side dishes (system libraries) or larger heat-at-home dishes (application source bundles) that I integrate into my day-to-day meals. I may gain some variety because they can prepare dishes that I do not have the skill or kitchen equipment to prepare myself. (The trust that I confer on these vendors for not using undocumented immigrant labor does not prevent me from contracting a case of salmonella. [Heartbleed.])
I can get food in many forms from many varieties of vendors - delivered meals, take-out meals from a restaurant eaten at home, sit-down meals at a restaurant, meals from a food truck eaten on a nearby patio, meals from a food truck eaten at home... (Apps, desktop, websites, servers. Simply browsing the modern web means code runs in response to your every input on hundreds of machines around the globe.)
Sometimes my act of eating employs undocumented immigrants. Crap.
The code that generated the resource you're viewing, regardless of script content, may not be Free. The code running the server may not be Free, and that might not be part of the details of the transmission. There is probably plenty of nonFree code in the hardware that got your packets there and back.
How the Hell does Stallman even use the Internet?
How that work more precisely depend on where you live and what legal framework is in place.
Defining "nontrivial" is probably impossible, and the attempt looks a bit clumsy: making a network request apparently instantly qualifies you as non-trivial, even though your browser probably made a bunch of network requests for static content just to load the page. Want to load a sound to play with the Web Audio API? You now need to open source your Javascript code and provide a correct license to avoid blocking. The given description also means use of obj[prop] (often used to mimic a hashmap, thereby arbitrarily disqualifying certain data structures) or loading an external script via <script src="..."></script> (thereby disqualifying certain kinds of optimisation or organisation) count you as "nontrivial".
How can this ever be objectively determined? And if the punishment is blocking then how is it ever going to be fair?
Oh, and the reasoning behind the "one character method names" mentioned: It's for minification of code, because we don't live in a world with infinite resources. If the FSF donated to me to keep my code "open" then I'd gladly keep it un-minified. Even when "obfuscated", though, it's pretty trivial to undo. [1]
[1]: http://features.jsomers.net/how-i-reverse-engineered-google-...
[0] http://llvm.org/devmtg/2013-11/slides/Zakai-Emscripten.pdf
Although asm.js code is probably more C-like than LLVM IR is, given you have to decompile gotos back into ifs and loops, operations back into expressions, etc. (See page 23 onwards)
Obfuscation of C or otherwise native code can prevent people from modifying it or learning from it, and that is a problem to some people. However, that doesn't seem to exist in my view of JavaScript. It has never been a real problem as far as I have seen. I am open to seeing examples that I truly could not understand.
I'm all for open source as much as possible and whenever it's practical, but this blog post is akin to saying you shouldn't use C code on your system because there's non-free software written in C.
And how is it any different than the server doing the exact same thing server side?
I think the rational ordering will normally be:
RMS seems to prefer: But unknown code on someone else's server can generally do far more in terms of anti-features than non-free code on your server. You can at least see how much data is being exfiltrated; they still have to worry about people reverse engineering the code and ruining their reputation if they do something too bad; you at least have the option to reverse engineer the data format or network protocol and replace their code with something you completely understand and control. If the data is on their server, you give up a tremendous amount of control.I think some of the stuff RMS writes can serve as a cautionary tale about not letting rational heuristics that start with good intentions become dogma (as can the development of many religions which also probably started with good intentions) - hyperbolic thinking and using words like evil and wrong to describe something you think should be avoided always seems to lead to things getting taken too far.
To me, closed source source software running in a sandbox is not a problem. The problem arises when (a) binary blobs that might do literally anything with your machine, are the only way to get certain things done, or (b) all hardware/software is so locked down that it is infeasible for anyone to do any hardware/software work without the blessing of the people in control of the hardware/software.
But to the FSF, the ability to modify and see the source code for software is fundamental, even when (a) and (b) don't apply. Perhaps they see opposing all non-free software as a kind of prophylactic measure. But I'm inclined to take them at their word that they care about "freedom" for its own sake. I wish they would drop the word, because what they are really arguing is that their notion of freedom is important. I get sick of their debating tactics which end up with saying "oh you don't have to use free software. But you wont' be free [by our definition]".
I've never seen a convincing argument for why sandboxed closed source software is a bad thing.
2. There is complete no sandboxing.
I don't know what you mean by 2. Do you mean that sandboxes can break? If so that seems like a very weak point. The browser sandbox is very secure. Furthermore, similar critiques can be made of free software. Someone could sneak in malicious code into free software.
If they are implying that the complexity of a snippet of code has some bearing on whether copyright protection applies, that is simply untrue. Forgive me for that strawman, but if they had told us we wouldn't have to guess.
I also sense a bit of fear mongering here. Half a megabyte of Javascript for a web page? Goodness, what could they be putting in there? And just a reminder, eval is evil. But why does that automatically qualify code as nontrivial? And how does that have anything to do with free software in the first place?
(As to what it actually means, the case law is complex and the FSF would probably tell you to go ask a lawyer if you really want to know. Otherwise they will just offer you some arbitrary guideline, somewhat like their prohibition on linking to GPL C programs.)
[1]http://www.iusmentis.com/copyright/software/protection/
No, its not. The article lays out precisely what the FSF's policy on triviality is, and it has no relation to any criteria in copyright law; that's not to say that "triviality" might be a good common-language term for a real consideration in copyright law that relates to whether something is an original work of authorship subject to copyright law, but to the extent it is it has nothing to do with the "triviality" at issue in the article here.
So I will maintain that my copyright explanation is the best explanation, simply because (sofar) it's the only explanation.
I didn't say they did. I said that they say what their policy is, and I said that the policy they describe has no relation to any distinction in copyright law. A counterargument would be to show such a relationship, not to point out the absence of something that I never claimed was present.
In any case, "trivial" has a meaning under copyright law and therefore is very relevant to the GPL and whatever argument they're putting forth. That is all.
Yes. Largely because you keep inventing things I'm not saying to respond to. Such as:
> you're telling me that "you're wrong, but I don't know why".
No, I never said anything like that, and I stated quite directly how you were wrong.
> In any case, "trivial" has a meaning under copyright law
I don't think that's accurate, and the article you offered upthread to support that position does not -- in fact, the only uses of trivial in that article are to make the point that the legal concerns it discusses (idea vs. expression, and functional vs. creative works) are relevant in the same way to trivial (which it doesn't discuss as a term with legal significance) and non-trivial programs. And, in any case, the use of "trivial" in Stallman's post isn't connected to anything related to copyright law -- even if "trivial" was a term that had legal significance, that wouldn't make every use of "trivial" in regard to the GPL automatically related to that significance, especially when the sense of "trivial" being used is explicitly defined in the work in which it is used and isn't tied to the definition of any legally-significant distinction.
Fight some other battle, gnu!
This only really applies to JS served from the website. Offline apps are a little more iffy, and browser extensions certainly qualify as installed software that you are running. Possibly less so in Chrome, where the extension API has some pretty hard limits on what extension code can access, but in Firefox you have the ability to do almost anything on the user's machine, which is why Mozilla reviews add-ons before approving them and has stricter guidelines for how they should behave.
If a bank websites JS software goes wrong and causes damages, whose fault is it? Is it the customer fault, maybe because his machine had broken hardware? Is it the bank, because its their service and they are responsible that all transactions are done correctly? Is it the JS developers who maybe introduced a bug?
When we can define whose responsibility it is, we can define if the user of the software/service need access to change, modify and distribute the code.