Group talk: Free Javascript Action Team
Interested in helping with this project? Make a user page and introduce yourself here :). --johns 12:24, 24 March 2009 (EDT)
Contents
Bad Edits
These edits were bad:
- removal of Lenny record has no rationale.
- removal of eBay note has no rationale. eBay's javascript snoops which is useful to know in a porting effort
- the rationale for suppressing the fact that Duckduckgo is hosted by Microsoft is bogus.
DDG's IP is 52.149.246.39, which most certainly belongs to Microsoft. It used to be Amazon but that changed.
Places to Start
I'm concerned about Greasefire being on this list. The code on userscripts.org 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 userscripts.org. I think we want to be clear that Greasfire could provide useful code to start with, and userscripts.org 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 identi.ca as the first entry. Obviously identi.ca is free software (both the current StatusNet implementation and the pump.io implementation going live soon), and I've volunteered to implement machine readable license information in identi.ca (so pump.io) in the conversation at http://identi.ca/conversation/99262645#notice-100478601 .
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 ( http://lduros.net/pipermail/librejs/2012-March/000030.html ), 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.
Hello,
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.
- I propose a more verbose (and less short-cut-y) introduction.
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
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.
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
- (personal rant)
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.
- Furthermore, I propose that the source code recommendation be restated and disambiguified in the article's page :
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
Source code conventions
The article by Richard Stallman contains an appendix listing recommendations, such as
// @source: URL
in the minimised code, or
@licstart
(Copyright notice : (C) [date] [author])
(Copyleft mention here)
@licend
in the JavaScript source code.
\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
Issues, discussions and other suggestions
- This very page has non-free JavaScript. It kicks off the GNU LibreJS plugin in Firefox, anyway... shouldn't we start closer to home? (cmhobbs)
- A strict syntax is not defined for the suggested tags. This potentially affects parsers, and corner cases (like spaces or tabs) are unclear, so complex regular expressions become necessary. A single space after the opening comment character and after the ":" is all that is needed (in theory). So we rule out the following :
//@source:URL
//@source: URL
// @source : URL
etc.
- These recommendations only deal with JavaScript files, while a modern web site deals at least with HTML, JS, CSS and XML (now JSoN too), and if we count server-side software, we may add PHP, Ruby, C (CGI) and countless others. The original recommendation can be generalised to a higher problem : that of indicating (and tracing) source code origins and licenses. They need to be specified unambiguously with comments embedded in the served files in the HTTP stream. HTTP headers should not belong to this debate (in theory too).
Ideally, the same tags should be used whatever the file's language.
- The original suggestions are logical for a web site that is complex like a small homepage : one HTML, one CSS and one JS file for example. More complex websites require tens or maybe hundreds of source files (in different formats) and adding 13 lines to each poses serious maintainability issues, such as code bloat (even though it compresses well) and the eventual case when the license is changed or simply updated (don't trust sed scripts for that).
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.
- Minimised code often contains more than one file, so the generated header should be able to contain more than one URL (space-separated for easy processing through bash scripts for example).
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 ?)
- Because I need to specify both where the source archive is located, and what files were used to generate a specific minimised file, I suggest 2 tags :
- "@archive URL" points to the .tgz of the whole project
- "@files URL" lists which source files were used to generate the minimised file.
- The original article does not mention the Affero GPL and its pertinece with web-based software. It could be an interesting read.
- The original article adds a permission to redistribute compacted files without the accompanying source code : this part is not mentioned in the body of the article and should be only optional (though I admit that there may be cases where it can be useful).
===> Examples are needed to make this point clear.
- The different existing compaction/minimisation software should be encouraged to follow these suggestions (once they are stabilised) :
and others...
- Reference that can be added :
- Minification v Obfuscation by Douglas Crockford (interesting discussion by the author of JSMIN)
- Maybe, in the end, we could submit a RFC to the IETF ?
- Insert a link to this page on the main/original article ( http://www.gnu.org/philosophy/javascript-trap.html )
- A census of the existing code source tags would be a great hint to optimise ours, and avoid name collisions.
I welcome further suggestions that are useful, not invasive and well defined.
Yann / Whygee
