Certain activities should be done, for example, jointly only between such regions as American states and Europe (e.g., the European Union is right not to set its standards too low in just allowing anyone to join, though I hope such like-minded unions progress across the Atlantic and Americas and into other like-minded regions).

However, in other non-critical areas, such as ICANN and membership on the United Nations General Assembly itself (since the General Assembly resolutions are currently not binding), I believe the most effective policy is, at this point in time, to deny only the most egregious deniers of human rights the right to participate, while allowing most voices to be heard until such time as standards improve (The U.N. charter does not give an unequivocal right to stay in the U.N.; it can be revoked). If a country wants to block traffic to a particular domain, they can already do it, so I'm not sure that the repercussions would be so serious if oppressive regions provisionally get to deny certain domains assigned under their country's specific top-level domains. In non-critical cases where widespread participation is reasonable and beneficial even with somewhat oppressive regimes (it defuses perceptions of American exceptionalism for one), you can exercise more influence when you pick your battles wisely and engage, rather than being quixotic (and no doubt inconsistent) in throwing all problematic countries into one lump and failing to have any influence at all on human rights because the net was cast too wide.

But it is a good impulse to recognize there need to be certain standards, especially if effort is made to apply them progressively.

While this might go against the Church of the Anti-Religion (Gathering of the Tribe: here), maybe the fact that those of you who admit partisanship in yourself or among those who use the same technologies you do, could concede that systems of morality--including those which justify themselves on supernatural inspiration and use that to enhance its effect (indisputably quite frequently for good), while admittedly broader in scope (and power) than technology fan-clubs, are not themselves inherently to blame for fanatics and fundamentalists any more than Linux or the like is inherently to blame for the type of dude who kicked me out of a chat room for the FUD blasphemy of joking to the effect that if I couldn't get help from them testing a potentially useful open source Firefox extension on Linux that Linux users might otherwise cede territory to the "Dark Side".

It shouldn't be such a marvel to people who recognize that our ubiquitous use of a brain--however much you may joke that religionists do not have any (isn't treating and taunting others as a whole a sign of fervid attachment and insecurity, btw?; most cults don't even go that far)--in filtering reality, with its propensity for emotional and/or communal attachments, will apply such a propensity, more or less universally, for good or ill, across all subjects. I am in you, and you are in me...

"Exponents of the world's various theological systems bear a heavy responsibility not only for the disrepute into which faith itself has fallen among many progressive thinkers, but for the inhibitions and distortions produced in humanity's continuing discourse on spiritual meaning. To conclude, however, that the answer lies in discouraging the investigation of spiritual reality and ignoring the deepest roots of human motivation is a self-evident delusion. The sole effect, to the degree that such censorship has been achieved in recent history, has been to deliver the shaping of humanity's future into the hands of a new orthodoxy, one which argues that truth is amoral and facts are independent of values." (The Prosperity of Humankind)

The problem with a lot of sites dealing with spam is that they are using the same software that tries to solve everything at the top. Uniformity doesn't help.

But leaving people to their own devices to create or adapt their own forum/blogging/wiki software is not a good solution either. Uncoordinated diversity leaves a lot of people to fend for themselves.

Having unity-in-diversity (a common strength across systems and organisms), however, might well solve the problem.

If forum/blogging/wiki software creators would give sites the opportunity to make (and be able to change) their own set of question and answers for first-time-users (and not trouble them after that), I think bots would be hard-pressed to be programmed to interpret all such site-specific questions on their own. If bots could actually be programmed to intelligently answer all such human language questions, I think the bot-makers could be making a lot more dough in legitimate business...

RMS brings up the client vs. server issue,

Besides this, I'm surprised the article didn't make mention of the Affero GPL to force server-side code to be shared back.

As far as the parent comment:

What if the http server and database are free software, but the people who operate the server don't allow you to download all of their data in bulk and serve it yourself?

I for one think that might make an excellent optional addition to the GPL, as with Affero. If crowd-sourcing sites like Wikipedia didn't make their data available in bulk, they are much less appealing. Yes, one can make their own spider/scraper, but that is not exactly in the spirit of the data itself being wholly "free", assuming it is even possible with some sites to reverse engineer their complete data package. And nothing is to prevent the site from modifying their robots.txt file at any time to cause/force the Wayback Machine, etc. to stop distributing their archived copies (and taking the content offline or requiring paid access to it), thereby leaving every contributor in the lurch who expected to be able to get their content contributions back, even if those contributions were GPL.

On the other side, it would be interesting to see an optional clause compelling the exposure of the live database API (at least read-only, though maybe even a limited-but-meaningful write-access one for wikis, allowing perhaps for free but limited, registration-dependent keys), since sometimes the source of the data (by that I mean the site which is serving the data) is what is important, as it is trusted and contains the latest data which people wish to read or shape.

Actually, a site which acted to expose the write API (whether compelling others creating their own version to expose their data, data API, etc., or not), might be the only way Wikipedia could become more free--and someone setting up such a fork, if Mediawiki didn't do so itself, might be the one way people would actually switch sites. When the API is exposed, it can effectively produce a distributed wiki which addresses the issue of specific hosts being blocked (as Wikipedia has been and is in some countries) as well as opens up opportunities for alternative clients.

I for one think that this article has done a great service by raising the issue. While I might not demand to only use "free" sites (client-side of server-side) myself, and while I might not always want to compel others to go that far in staying "free" by using such compulsory licenses in my own open source projects, I do believe it offers a good option to stimulate development of such fully-free sites, especially if the FSF's future server-side solutions will take into account optionally compelling the exposure of data API's and/or bulk data downloads as mentioned above.

As far as the main thrust of the topic, of course bundling helps--a lot--but maybe the exec just meant that bundling can't suppress good things forever...

Anyhow, the question of what to do if Firefox does gain a 2/3 market share is still valid (and even before that).

My hope is that more aspects of the Firefox browser can become or contribute to their own standards--and that Mozilla will itself adhere to them. XUL, the interface language used in the browser itself and extension building, might be such a candidate for standardization (or at least a subset of it), assuming other browser makers would be interested.

Perhaps there's a lesson somewhere with XBL, assuming it ever goes anywhere (the extensibility of XBL is great, but again, there should, I feel, be some standard for the more frequently recurring bread-and-butter requirement of describing browser elements, as XUL provides).

Likewise, it'd be great for XPCOM functionality to somehow become accepted as XBCOM (cross-browser). Perhaps FUEL API's could be joined with other browser makers' libraries into a standard, again assuming interest. At the very least, I hope other browser-makers-which-allow-extension-of-the-browser may agree to standardize on Mozilla's useful JavaScript module importation so that such code can also be reused cross-browser without modification.

One concern I have is with an existing attitude in Mozilla where repeated mention has been made by prominent Mozilla developers of a distinction between the web and non-web, and arguing against following standards which were conceived without the web in mind. While that may well be true, this can also set up a false dichotomy and introduce exceptionalism. If there is a non-web use for a technology (e.g., support for external DTDs in (especially document-centric) XML for simple localization), then there well is also a web-use. Likewise was such an argument against certain standards made toward not implementing DOM Level 3, even though parsing and serialization from or to strings or the DOM is a pretty basic requirement across browsers (and the API, as with the rest of the DOM, is not that terrible so as to make it impossible to work around, as we all do with levels 1 and 2 of the DOM). I hope such existing cross-browser issues can be addressed, even as new standards if need really be (again, without falsely assuming that non-web uses such as serializing to streams, etc., can't find web (or browser) uses and dumbing down the standards).

I'm also concerned with another topic impinging on the Mozilla-as-gatekeeper concern: modularity within Firefox itself. Firefox should, I feel, quickly make good on its plans to enhance its extension dependency system, so third parties can supply independent modules and have extensions automatically trigger such downloads upon installation. Otherwise Mozilla stays as the albeit friendly gate-keeper within the community (not to mention for other browsers) and either gets bloated or left insufficiently extensible. For example, for dealing with the sparseness of built-in JavaScript functions to handle many common tasks, while using an already familiar API, PHP.JS could eventually be made as such a module. Mozilla expressed openness to allow modules to be added, but it would, I feel, be more extensible and sustainable into the future (and not contribute to browser bloat), if the community "market" could more easily determine which modules were useful as reusables. Thus, extension builders could freely rely (on an ever-expandable number of) reusable but optional dependencies without burdening users into initiating separate downloads (or downloading or reloading the same code repeatedly across extensions, or unnecessarily updating the whole package when only one module needs updating). In the process, this could significantly address the arguments made by some against installing too many extensions.