Review of FSF High Priority Projects list -- your input is needed
- Inicie sesión o regístrese para enviar comentarios
I only just found this. Check out the FSF blog post:
Andrew
For me, Libreboot and Replicant come to mind.
They are both so damn important and have severe problems (replicant doesn't support a single device with working wifi, libreboot is limited to very few mainboards).
Besides, I immediately think of reverse engineering of wireless card firmware.
I mean that's one of the biggest obstacles for most users, right?
And yeah, a skype alternative (we have many things that come close, but we're not all the way there).
People tend to use more and more smartphones and tablets. The situation there is horrible to say at least.
Desktop pcs are almost free compared to that...
I am a translator!
libreboot. librejs (a working one)
Hmm Librejs... I would the Project rather call "the javascript problem". I doubt that librejs is the way to go honestly...
Maybe the browser could come with a set of (user)scripts that could replace the most commonly used javascript codes on websites.
Don't know if that's technically possible though.
I think this, too.
Also, I think there should be a variant of a Web browser that executes JavaScript, but only (by default) loads stuff locally, off your own disk, not from servers. This type of thing should be how we run ethical HTML/JavaScript applications (what people tend to call "Web applications").
I am a translator!
I have javascript always turned off but rarely I need it so I temporarely enable it on a website when it is absolutely necessary. Tried using librejs on several for a few days - it never worked. it is full of bugs and it makem me wanna pull off my hair..
It would be very nice if it worked properly being that so far there is really no good alternative for it. I think javascript is going to stay and the majority of websites is going to keep using it. So librejs is a priority in my humble opinion
Please send the bugs you've encountered in LibreJS to name at domain! I'd like to fix them.
I'd rather see an addon with which all scripts are turned off by default, but the user can turn on one-by-one the ones that are needed (having read the license to them, which should be shown as the script to be turned on should be shown to the user, including its licence (or lack thereof)).
But perhaps that'd lead to so many addons it's a pain in the....
I think that would be fine, but only if accepting a script caused it to be stored permanently, like a user script, and with proper controls to determine whether and from what source it should auto-update, again, like a user script.
Why don't you write an email to rms about that issue?
Maybe he has some interesting thoughts on it or even agrees with you.
I have. He expressed disagreement:
> That would be ideal from our point of view, but it would mean more
> compromise or inconvenience for the service developers. (They want to
> distribute JS code so that the service will work automatically for
> ordinary users.)
>
> In practice, some of them do agree to free the JS code sent by the
> site, but I think none of them would agree to replace it with user
> scripts. For ordinary users, the user scripts would be too much
> of a hassle, and the server developers fear the service will fail
> in business as a result.
I then sent this as a response:
> I disagree with this attitude entirely. You can easily justify
> proprietary software the same way, by saying that video game
> developers want digital restriction mechanisms:
>
> No proprietary software would be ideal from our point of view, but
> it would mean more compromise or inconvenience for the video game
> publishers. (They want to restrict what users can do so that they
> can't create unauthorized copies that threaten their copyright
> monopolies.)
>
> If something that some people want is made impossible or more
> difficult by rejecting the mechanism where JavaScript is automatically
> installed and executed in users' browsers, it doesn't follow that we
> should accept it.
>
> You also seem to be imagining a false dichotomy: that maintainers of
> websites either have to require JavaScript in tags or require
> user scripts, but this is nonsense; if interactivity in a Web page is
> really so important, it's easily possible to support both methods.
> Locally installed clients are a third option.
>
> That said, I think you are exaggerating the problem. I can't think of
> any situation that requires interactivity in a Web page, and many
> websites do work just fine as static Web pages. For me, the only
> problem sites are some of the forums I go to ("spoiler" tags), TV
> Tropes ("note" buttons that show some additional text), YouTube, and
> Diaspora, and the only one I have had to abandon as a result of these
> problems is, ironically, Diaspora, whose JavaScript code is mostly
> libre, because it depends on that JavaScript code for *everything*.
>
> For every single one of these JavaScript requirements, I can think of
> an easy replacement, given what they are trying to do. "Spoiler" tags
> could easily be implemented as coloring the text the same as the
> background. "Note" buttons on TV Tropes could easily be made into
> footnotes. All of YouTube's problems didn't even exist in the past,
> except for the problem of videos, which can easily be fixed by doing
> the same kind of thing MediaGoblin does.
>
> In fact, I use the ViewTube user script to watch videos on YouTube.
> This raises another point: it's very possible to replace the scripts
> distributed by popular websites with libre user scripts. That wasn't
> even the purpose of ViewTube, and it's still able to serve that
> purpose, not only for YouTube, but for several other video hosts as well.
>
> Right now, the approach being taken to solve the problem of
> proprietary JavaScript is just to pressure maintainers of websites to
> either release their JavaScript under a libre license, or "at least"
> not require it, while at the same time trying to develop some kind of
> mechanism to allow users to cope with the system (quite ineffectively,
> I might add; it seems all the work for the latter part of the current
> strategy is being left to one person, and at least 5 years after you
> published "The JavaScript Trap", LibreJS is still awfully buggy and
> completely inadequate).
>
> I propose this approach instead:
>
> 1. Pressure maintainers of websites to not require any JavaScript code
> to work. Not even libre JavaScript.
>
> 2. Change IceCat's default configuration to be not accept any
> JavaScript requests at all. Not even if it thinks it has found source
> code and sees that it's under a libre license.
>
> 3. Develop user scripts to replace required proprietary JavaScript on
> popular websites, and convert libre JavaScript to user scripts. The
> latter part could be aided by a mechanism to automatically convert
> regular scripts to user scripts, if it's possible (I don't know if it
> is or not). These user scripts could be distributed with IceCat by
> default to make the user experience better.
This was on December 1. He hasn't responded to it.
Honestly, if rms talks about *practicle* problems with your approach, it's really time to give it some serious thoughts.
> That said, I think you are exaggerating the problem. I can't think of
> any situation that requires interactivity in a Web page, and many
> websites do work just fine as static Web pages.
Maybe you got him wrong: Nobody says that javascript is a _technical_ requirement for webpages to work. The whole web could possibly do without javascript just fine from a technical point of view... but they use it, to a heavy extent. You say that he's exaggerating the problem but honestly it's more that you're doing the opposite, probably because you're too much focusing on your own browsing habits.
> You say that he's exaggerating the problem but honestly
> it's more that you're doing the opposite, probably because
> you're too much focusing on your own browsing habits.
What situations are you thinking of that require interactivity in a Web page beyond what the browser provides on its own?
"Require" in a technical sense like "can't be done without javascript": none.
"Require" as in "won't run today without javascript": an aweful lot.
I gave it some thought and agree with rms even more.
You're proposal is completely beyond any practicability.
Who is supposed to write all the replacements for javascript of popular websites?
1. It's not sufficient to just cover the intersecting set of websites that users consider important... most people have some special hobbies or stuff they like and they really need some special websites to work. Making the browsing experience acceptable for a significant number of users requires a huge number of potential replacements.
2. Popular websites use javascript to a very excessive extent; it's far from a trivial task to a) write the code and b) keep it up to date (because companies tend to change functionality of their websites *all the time* and they won't stop because of us. As a result, code will become non-functual and outdated all the time; websites will be broken non-stop.
Quite and simple: it can't be done. Can't you see yourself?
> "Require" in a technical sense like "can't be done without javascript": none.
> "Require" as in "won't run today without javascript": an aweful lot.
But today, many websites won't work without non-free JavaScript code, which simply isn't going to be made free any time soon. RMS vaguely claimed in an email to me that people sometimes release JavaScript under a libre license, but how often does this really occur?
I recall two campaigns from the FSF to convince single websites to free all their JavaScript or "at least" make the sites work without JavaScript: one for Greenpeace.org, and one for Reddit. I remember absolutely no reaction on Reddit, and while I don't know about the progress with Greenpeace on the "at least" not making it required front, looking at the scripts it's attempting to load, they still seem to be proprietary; the only script I found in my quick trawl that had a license notice was minified, and didn't have a source link. This is not exactly a success story.
> You're proposal is completely beyond any practicability.
> Who is supposed to write all the replacements for
> javascript of popular websites?
The idea of replacing all of the Unix system probably looked just as impractical in 1983. Would you propose that RMS should have instead devoted his time to going to the door of everyone who developed a component of Unix, and pressuring them to release their program under a libre license along with source code?
Replacing the JavaScript code on a few popular Web sites seems to me like a trivial task compared to the task of replacing the entire Unix system. And it's already partially done; look at ViewTube, ViewTube+, and ViewTubePlus, for instance, which replace the proprietary scripts for playing videos on dozens of sites.
Of course it won't ultimately fix the problem, that's not the purpose. Replacing scripts on popular websites with user scripts is a way to deal with the problem today, which the FSF and RMS currently don't have a proposal for at all.
The way I propose to deal with the problem in the long-term is exactly the same as the FSF's current way: convincing webmasters to change their habits. the main difference in my proposal is what habits I want to encourage; the FSF wants to encourage webmasters to put license tags on their scripts, and I want to encourage webmasters to stop requiring scripts.
I want to point something else out:
Freedom is our reason for wanting to do something about JavaScript, but there are other reasons to reject JavaScript on the Web that other groups can get behind: security, privacy, and simplicity. The EFF could be a massive ally here, for example.
With the FSF's current strategy, though, there is no security benefit, no privacy benefit, and no reduction of complexity. This means we're entirely on our own, and the only way we can ever really succeed this way is to create massive social change.
If we're fighting for different goals, sooner or later this will cause problems. For instance, server owners might agree to remove certain functions and our fellows who are concerned about security will get soothed this way - we don't.
That said, i'm not happy with your unix comparison.
First of all, the the creation of a free replacement for unix was one of the biggest deals (maybe the biggest one) in the history of free software. It was a historical effort and we haven't seen something comparable in the last decades.
Today, people are waiting for a piece of video editing software for an eternity, and so do they for free firmware.
Another concern:
Javascript code is mostly available; you can read it, though it's proprietary.
A free replacement would do the same job as the proprietary code and look more or less identical.
I think you can't just write (more or less) the same code and release it as a piece of free software. Sure there are a lot of legal issues here.
Also, unlike back with unix, we can't just write the code and use it; we are dependent on the websites, and those businesses will sure implement technologies to detect whether a visitor runs some userscript and they will come up with technologies to prevent him from doing so.
That said, we don't have a rms at the moment who writes a free replacement for javascript of the web.
Even if we had: due to the size and the dynamic nature of the web, it would be
1. horribly incomplete
2. outdated tomorrow.
What solution do you propose to this problem, exactly?
What we're doing right now is fumbling with trying to convince thousands of people who completely disagree with us to start specially accommodating us.
I'm suggesting a slightly different approach: convince thousands of people to do something slightly different, which they might also see practical reasons for. But to also write user scripts as a supplement to that, rather than focusing all our programming efforts on converting a dangerous system that we don't need into a safe system.
What exactly is so wrong with my proposal that is not also wrong with what the FSF is currently doing?
I don't think your proposal is "wrong", I just think that it can't solve the problem.
My proposal is a mixture of
1. your proposal (writing as many userscript replacements as possible)
2. stallman's proposal (trying to convince as many server owners to release their code as free javascript; i know that you're concerned about the scripts being executed without the users consent, but this could be solved with an addon which asks the user for confirmation to run script xy in version wz; he could agree to run the free scripts of the most visited websites with somekind of whitelist)
3. live without javascript if point 1 and 2 didn't work out, or make somekind of workaround (element inspector)
4. make a compromise for the rest (just like we do with non-free bios)
Web-technology evolves quickly and chances might be decent that a new technology will make javascript disappear... like it happens with flash to some extent at the moment.
I have to say that I gave it some thought and that i'm not so pessimistic about your proposal anymore. I mean there exist already a lot of userscripts and they modify a huge bunch of websites... unfortunately not for freedom's sake.
Still I think that we need to combine all the means we have right now and then we need a bit of luck...
That said, i'm not happy with your unix comparison.
for that rms writes a free replacement
At that time There were no Free Softwares
You can not use the computer freely
But the situation now is different
You can browse the Web without javascript
You can be avoided
I am a member!
Libreboot for sure.
It only works on a handful of chips at the moment, and this needs to change. The BIOS is the only remaining proprietary part of my system, and there's nothing I can do about it. It's all very well trying to make hardware choices that support free software, but Libreboot runs on almost nothing, making this very hard.
My second priority would be drivers for Replicant.
I'd say- Replicant drivers as well as support for newer devices (Most people give you a crazy look when you suggest an S2), Libreboot, and LibreJS. LibreJS is *really* buggy, at least for me.
Replicant for sure.
Thank you very much, andrew, for telling us about this blog post. I wasn't aware of it before. Here is what I wrote to the HPP commitee:
"In my opinion Gnash shouldn't be placed on that list so prominently
anymore because Flash is a dying technology and will (hopefully) soon be
a thing of the past. Any effort put into a free Flash replacement could
probably better used for other projects. For example, I highly recommend
to emphasize the need for a really free smartphone (including free
hardware, free firmware and free software). As this is nothing more than
a very distant dream at the moment, the Replicant project seems to be
the only valuable option. Please put it higher on your list in order to
make sure that free wifi-drivers for some common devices can be developed.
A free Skype replacement and coreboot are in my opinion also equally
important and should continue to be supported.
There is one last thing which hasn't been mentioned at all on the list
so far: A free replacement for the proprietary software and hardware
used in medical environments like hospitals. Often those systems are
developed, deployed and then never touched again for many months and
years. This is especially dangerous if proprietary software is used and
the systems keep being connected to the Internet."
I'm skeptical of just coreboot or Skype-replacement development
succeeding at freeing users' computers. You need nontrivial skills to
flash coreboot (unless it's on a sufficiently old system where someone
provides trustworthy binaries, like Lenovo does), and to use the
Skype-replacement you need to convince your friends to use it too. I
want to believe that it's just my pessimism.
I have a different argument against listing Gnash: it's mostly used to
run nonfree programs that are being replaced by different nonfree
programs that completely support fully free interpreters like in recent
Mozilla browsers. So we need other projects to replace these programs
regardless of Gnash being able to run them. I'm not sure if a single
developer would choose between contributing to a Flash replacement or a
firmware project (but I'm a Web developer interested in coreboot, so it
might be an unusual opinion).
Sure, of course there is much more needed than "just" replacing Skype to really free a computer but it would be a tremendous step forward. The problem of convincing all your friends is a very common one. I had to deal with it many times before because usually the majority of people goes with the most convenient solution and not with the one providoing the most freedom.
Furthermore, I agree that installing coreboot is non-trivial but this is where smart business people could jump in by providing pre-installed and pre-configured motherboards.
I think that Gnash should also be featured as important- there are people that need Flash for work or school, and it may just save them from having to use proprietary software.
Last year, I needed to use a website that required Flash for school. Thankfully, Gnash worked with it. Gnash saved my grades and my freedom.
Flash is slowly dieing out, so it shouldn't be as important as Libreboot or Replicant, though.
gnash is a important project but
arent the majoraty of flash programs non-free?
dose libre-actionscript need to be made?
although if you have to use a non-free flash program then its much better to use gnash than the horrible adobe program
- Inicie sesión o regístrese para enviar comentarios