Last modified: 2012-04-12 13:56:05 UTC
Hi all I am creating the content of a training dedicated to legal security in software developments, and decided to use mediawiki source code as a support on how to audit from a legal standpoint source code. The JSMin.php component which is a core class from mediawiki is licensed under a MIT/X license which has been modified by including the following mention. "The Software shall be used for Good, not Evil." This restricts the use of the software in certain case, renders in turn the software non-free, therefore non compatible with the GNU GPL v2 used for mediawiki. A colleague of mine has contacted the authors of the latter class, by uploading the issue on their gitHub site (see https://github.com/rgrove/jsmin-php/issues#issue/4 ). Although this might seem like a minor issue, it nonetheless impacts the legal situation of your excellent wiki platform. I hope you will be able to solve this, Best regards, Matthieu
Not a maintenance script issue, reassigning to General/Unknown (or is it a Docs issue?) instead of me. Also removing my CC, because I'm not really interested.
Hi, Thanks for your quick answer. JSMin is a core class from Mediawiki. grep -C 4 -r JSMin.php . Load for by the global loader and it seems called one time by a maintenance script : minify.php switch ( $extension ) { case 'js': $outText = JSMin::minify( $inText ); break; default: $this->error( "No minifier defined for extension \"$extension\"" ); } As you can see the only script relying on JSMin is basically a maintenance script and that's the reason why we put it there. Although legal, this is NOT a docs issue. This impacts the very "free" nature of MediaWiki. Regards, Matthieu
minify.php was removed, so this isn't a maintenance issue anymore. This is an issue with includes/libs/JSMin.php
I just checked in the nightly build tarball, MediaWiki 1.17alpha, and minify.php is still in the maintenance directory and JSMin.php is still used by this component. From where has it been removed? Cheers, M.
My mistake, I was confusing it with removing a Makefile to run minify.php on a series of JS files (see r79641).
The Free Software Foundation also says this license is non-free and therefore incompatible with the GPL. See http://www.gnu.org/licenses/license-list.html#JSON
Which maintenance script(s) use this component? Reedy marked this as a blocker for bug 26611, but I disagree that this should block our deployment to WMF sites. We *may* want to block 1.17 tarball release for this.
As Chad mentioned, JSMin is now in includes/libs/JSMin.php - ResourceLoader uses it. We can either request special permission from the author, or use something else entirely. I did some benchmarking with JSMin, Tim's modified JSMin, and some GPL friendly alternatives. Tests were run on the development version of jQuery 1.4.4. ------------------+-----------+-----------------+------------------ Library Time (sec) Minified (bytes) Compressed (bytes) ------------------+-----------+-----------------+------------------ JSMin (Original) 3.50 100221 27983 JSMin (MediaWiki) 1.71 105990 29087 JavaScriptPacker 1.36 54886 26327 JSMinPlus 5.47 98382 27636 ------------------+-----------+-----------------+------------------ As you can see, Tim's changes to JSMin got the cost of running it down a bit. JavaScriptPacker is still the fastest, but it does some really scary things to try and get the minified size down, which are pretty much done in vein since the gzipped version is so similar in size as all the other minifiers which output much more sane and reliable code. JSMinPlus is really expensive to run, but I'm sure we could optimize it - at least it's a GPL compatible starting point. The alternative is of course, we write something of our own. I ended up doing just that for CSS minification since we wanted to do some really particular things that other libraries did not do or did not do well enough for our needs, such as data URI embedding and URL remapping. But the most compelling reason was that all the CSS minifiers out there were way too complex, and caused a lot of problems when CSS hacks were introduced. Furthermore, the difference between running the text through about 5 regular expression replacements and parsing the CSS into a structure and spitting it back out was negligable. This may or may not prove to be the case with JavaScript, but it's something to consider. If we could have something incredibly simple and 80% effective and support hooking into things like Google ClosureCompiler or the JSMin PHP extension on our own cluster, we will be in the clear license-wise and still be able to get the final 20% in our own production environments.
Resolved in r80656 by replacing JSMin with a new library called JavaScriptDistiller, which is essentially an improved version of the minification step that JavaScriptPacker uses before doing it's evil packing magic. Good news, it's really fast! --------------------+-----------+-----------------+------------------ Library Time (sec) Minified (bytes) Compressed (bytes) --------------------+-----------+-----------------+------------------ JSMin (Original) 3.50 100221 27983 JSMin (MediaWiki) 1.71 105990 29087 JavaScriptPacker 1.36 54886 26327 JSMinPlus 5.47 98382 27636 --------------------+-----------+-----------------+------------------ JavaScriptDistiller 0.87 110178 29987 --------------------+-----------+-----------------+------------------
What we really need is a statement from Douglas Crockford, along these lines: "I give permission for Wikimedia, its customers, partners, and minions, to use JSLint for evil." (<http://wonko.com/post/jsmin-isnt-welcome-on-google-code>)
LOL - JSLint? You mean JSMin surely.
Andrew, although such a statement would clarify if Wikimedia was clear or not to make use of JSMin, it wouldn't solve everything... In particular, it wouldn't allow the licensing scheme chosen for the derivative and distributed work based on the latter (MediaWiki) - GNU GPL v2. The issue would remain: such a statement unfortunately makes the code under license non-free software. Which is evil in itself :-)
