Last modified: 2012-04-12 13:56:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 26791 - Modified MIT licensed component incompatible with GPL
Modified MIT licensed component incompatible with GPL
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Maintenance scripts (Other open bugs)
1.16.x
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
https://github.com/rgrove/jsmin-php/i...
: upstream
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-18 13:24 UTC by matthieu.farcot
Modified: 2012-04-12 13:56 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description matthieu.farcot 2011-01-18 13:24:34 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
Comment 1 Chad H. 2011-01-18 13:32:06 UTC
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.
Comment 2 matthieu.farcot 2011-01-18 13:52:25 UTC
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
Comment 3 Chad H. 2011-01-18 13:57:27 UTC
minify.php was removed, so this isn't a maintenance issue anymore. 

This is an issue with includes/libs/JSMin.php
Comment 4 matthieu.farcot 2011-01-18 14:08:25 UTC
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.
Comment 5 Chad H. 2011-01-18 14:14:40 UTC
My mistake, I was confusing it with removing a Makefile to run minify.php on a series of JS files (see r79641).
Comment 6 LordAndrew 2011-01-18 15:59:33 UTC
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
Comment 7 Rob Lanphier 2011-01-18 19:43:26 UTC
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.
Comment 8 Trevor Parscal 2011-01-19 00:32:23 UTC
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.
Comment 9 Trevor Parscal 2011-01-20 22:11:23 UTC
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
--------------------+-----------+-----------------+------------------
Comment 10 Andrew Garrett 2011-01-20 22:14:10 UTC
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>)
Comment 11 Trevor Parscal 2011-01-20 22:15:54 UTC
LOL - JSLint? You mean JSMin surely.
Comment 12 matthieu.farcot 2011-01-24 13:50:13 UTC
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 :-)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links