I also prefer the current approach of meta.license = stdenv.lib.licenses.unfree, in some companies it's not always allowed to use some 'viral' licenses (the opposite case of license.unfree).
N. --- nat...@nathan.gs | nathan.gs <http://nathan.gs?utm_source=footer&utm_medium=email&utm_campaign=n> | @nathan_gs <http://twitter.com/nathan_gs> | linkedin.com/in/nbijnens On Mon, Jan 26, 2015 at 2:19 PM, Matthias Beyer <m...@beyermatthias.de> wrote: > On 26-01-2015 14:00:10, Eelco Dolstra wrote: > > Hm, I have the impression the license checking code is becoming pretty > heavy at > > this point. For instance, what (realistically) is the use case for > whitelisting? > > Whitelisting a non-free license. > > > Even a basic NixOS system configuration probably has dozens of (free) > licenses, > > and I can't imagine users going to the trouble of specifying them all. > Also note > > that all this license checking is on the mkDerivation critical path, so > anything > > we do there slows down "nix-env -qa". > > Of course things have to be optimized here. > > > > I actually think we should *remove* meta.license entirely (because it > doesn't > > provide useful info to users and tends to be wrong or incomplete > anyway), and > > replace it with attributes that have operational meaning: > > I'm heavily against this. Having the license in the package > information is (IMHO) the right way to do this. > > Removing the license of a package is removing information about the > package, which I do not consider a good idea at all. You could remove > the maintainer and version, too, if you remove the license. > > -- > Mit freundlichen Grüßen, > Kind regards, > Matthias Beyer > > Proudly sent with mutt. > Happily signed with gnupg. > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev