[Tickets #11870] Re: JsMin is non-free ("The Software shall be used for Good, not Evil")

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/11870
------------------------------------------------------------------------------
  Ticket             | 11870
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | JsMin is non-free ("The Software shall be used for
                     | Good, not Evil")
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
-State              | Unconfirmed
+State              | Not A Bug
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2012-12-12 16:11) wrote:

> "The restriction might be unenforcible, but we cannot presume that.  
> Thus, the license is nonfree."

This is laughable.  The MIT License might contain restrictions for all  
I know.  There is nothing preventing someone from trying to sue under  
that license.  And if your response is "Yeah, someone could sue but  
the case would be thrown out because of the license terms" my response  
would be "Exactly - thanks for making my point".

Just because some group says it is a "free" license, doesn't mean  
s***.  It is up to any individual/company to make this decision on  
their own.

For the record: there are WAY more legal ramifications for using  
software with the GPL (or LGPL) license than there is for using  
software with a license term of "do good, not evil", regardless of  
whether the former is labeled "free" and the latter is labeled  
"non-free".  Just saying.

> You don't need to make a new package. What is the impact of simply  
> removing the file? replacing it with a void class?

There is minimal impact.  If that file/class is not available, the  
compression code will attempt to run, the factory will throw an  
exception, and the exception will be caught/ignored and the JS output  
as-is.  So there is a slight run-time penalty if the php jsmin  
configuration option is used, but I am OK with that.

> What if I propose a fallback mode using php-packer?

We already have fallback javascript minifiers.  And we absolutely  
don't need to maintain another PHP-based solution, since we already  
have one that works perfectly fine.