Group talk:Free Javascript Action Team

From LibrePlanet

(Redirected from Group talk:Javascript Trap)
Jump to: navigation, search

Interested in helping with this project? Make a user page and introduce yourself here :). --johns 12:24, 24 March 2009 (EDT)


Places to Start

I'm concerned about Greasefire being on this list. The code on don't seem to be necessarily free software, and could be obfuscated or non-freely licensed just as any other javascript. teddks 12:56, 24 March 2009 (EDT)

I totally agree, and it's why Stallman's article doesn't point to I think we want to be clear that Greasfire could provide useful code to start with, and is a useful model for a community JS repo site, but they are not exactly what we want to be recommending. Of course, one idea could be to approach the developers and see if they would be willing to consider the changes we are talking about. --johns 13:05, 24 March 2009 (EDT)

Sites sympathetic to software freedom

This heading lists as the first entry. Obviously is free software (both the current StatusNet implementation and the implementation going live soon), and I've volunteered to implement machine readable license information in (so in the conversation at .

However, before I do so I would like to have some tools which make it easy to check whether LibreJS would interpret things as intended. Preferably LibreJS itself should just have a non-blocking mode so sympathetic developers can keep it installed and just be notified about non-free javascript. I've asked for this on the LibreJS mailing-list in March 2012 ( ), but afaik no progress has been made there.

I think it is important that we make it easy for developers to implement machine-readable license information for their free javascript, so if anyone is in a position to develop tools for this or help out with LibreJS, that would be appreciated. --warp.


I often use JavaScript for unusual purposes, such as the design and support of a custom microprocessor (YASEP). I have recently tried to optimise my site with minification and even though I am not a worldwide specialist, the little practice that I have lets me believe that I could add some insight to this issue. Feel free to copy-paste whatever to the main article when the issues are settled.

Also, note that I started playing with these suggestions on my own code, so I can provide some feedback in the context of moderatly complex use patterns.

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

The problem

Currently, countless web applications like Google Docs are transmitting programs written in JavaScript and other languages to the users' web browser, in a modified formatting that optimises download bandwidth and latency. The source files pass through (more or less) simple filters (concatenation, useless space removal and variable renaming) that are harmless (in theory, unless syntax bugs are inserted in the process).

However, this obfuscates the source code, and the original is rarely available. This creates a very confuse situation because the usual copyright rules have been disregarded by unconcerned web developers, whose works become increasingly dominant. And because of the inherent obfuscation, the users are not able to examine or modify the software that their brower runs. This means that even in free software web browsers, users are running nonfree programs.

\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

Note that the title "The problem" could be renamed to "The grey area of copyright on web software" or "An ambiguous situation". The word "problem" is both too imprecise and negative, because there is yet no urgency, even though the situation is completely unclear. "As long as it works", people are happy, and they will always find ways to keep things going on beyond sanity (think IPv4 or older protocols). We won't solve the situation, we just propose a new and simple set of tags that will help define a clear limit between "those who don't care" and "those who abide to some specific principles". We can't change the status quo but invite others to move on and to realize that the code they write has a deeper impact than they imagined.

/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

Source code conventions

The article by Richard Stallman contains an appendix listing recommendations, such as

// @source: URL

in the minimised code, or


(Copyright notice : (C) [date] [author])

(Copyleft mention here)


in the JavaScript source code.

\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

Issues, discussions and other suggestions


//@source: URL

// @source : URL


Ideally, the same tags should be used whatever the file's language.

A simple solution, when the number of files grows, could be in the form of adding different tags to the source code, like :

@Copyright (C) [date] [author]

@LicenseURL [URL in the site or external]

@LicenseType [GPL|AGPL|Whatever]

This only uses 3 short lines and moves all the legalese where it belongs : to a subdirectory for example, where a HTML page discusses all the licensing details. Relative paths should be allowed.

Once again, strict syntax definitions will save us countless headaches in the future.

Furthermore, to where should this/these URL(s) point ? To a list of the original files ? (my current choice) To the URL of the archive where all the files can be downloaded ? To the script that has generated the minimised file ?

===> RMS says :

It should point to a URL where ALL the source code is available. Any scripts used for compilation are part of that source code.

(What about an open directory ?)

- "@archive URL" points to the .tgz of the whole project
- "@files URL" lists which source files were used to generate the minimised file.

===> Examples are needed to make this point clear.




and others...

- Minification v Obfuscation by Douglas Crockford (interesting discussion by the author of JSMIN)

I welcome further suggestions that are useful, not invasive and well defined.

Yann / Whygee

Personal tools
Important Teams
Community Norms