Hi Nix developers,
Lately, Eelco and I are thinking about some licensing issues we've discussed
before and we're trying to implement a solution in dealing with these issues.
One of the issues we have is that for most packages licenses aren't specified
or that the license identifiers aren't well defined. The first thing we have to
do is getting consensus about what license identifiers we have and what their
meaning is.
To solve this. I propose that we define an expression called licenses.nix,
which contains all these identifiers and maps them on a description e.g:
[
{ identifier = "BSD-original";
description = "Original BSD license with advertising clause";
}
{ identifier = "BSD-2";
description = "2-clause BSD license";
}
{ identifier = "BSD-3";
description = "3-clause BSD license";
}
{ identifier = "GPLv2";
description = "GNU General Public License version 2 only";
}
{ identifier = "GPLv2+";
description = "GNU General Public License version 2 or later";
}
{ identifier = "GPLv2+classpath";
description = "GNU General Public License version2 or later, with classpath
exception";
}
{ identifier = "GPLv2+OSS";
description = "GNU General Public License version2 or later, with OSI
approved licenses exception";
}
{ identifier = "GPLv3+";
description = "GNU General Public License version 3 or later";
}
{ identifier = "LGPLv2";
description = "GNU Library General Public License version 2 only";
}
{ identifier = "LGPLv2.1";
description = "GNU Lesser General Public License version 2.1 only";
}
{ identifier = "MPL1.1";
description = "Mozilla Public License 1.1";
}
...
]
This expression can be used a reference for license identifiers. I noticed that
a lot of packages in our repository have no license attribute yet, or the
license specification isn't very precise (e.g. some packages have "GPL" as a
license, but we don't know whether this means GPLv2 or GPLv3 or maybe GPLv2 or
later). Therefore we need to fix those meta attributes and we have to make sure
they match license identifiers that we know (i.e. which are defined in
licenses.nix). I found some inspiration for license identifiers here:
http://fedoraproject.org/wiki/Licensing
Policies
---------
We can use these license identifiers later on to see whether a package fits in
a certain policy. We could define several policies, such as:
FSF = [ "BSD-3" "GPLv2" "GPLv3" ... ]; # All licenses that conform to the free
software definition defined by the free software foundation
OSI = [ "BSD-3" "GPLv2" "GPLv3" ... ]; # All OSI approved licenses
DFSG = OSI; # All licenses that conform to the Debian Free Software guidelines
freely_distributable = FSF ++ OSI ++ [ "corefonts" ]; # Software which is
freely distributable, but not always free as in speech
or maybe other custom definitions such as FSF_with_firmware and use a tool that
checks of all the installed packages meet a given policy.
Disjunctive licenses
---------------------
Another issue is that some packages aren't available under a single license,
but more disjunctive licenses are applicable (packages such as Mozilla Firefox,
Mono, Qt etc.). In such cases the meta.license attribute has to be a list of
strings instead of a string.
Examples:
Mozilla Firefox is triple-licensed under the GPL version 2 or later, LPGL
version 2.1 or later or the Mozilla Public License version 1.1:
meta.license = [ "GPLv2+" "LGPL2.1+" "MPL1.1" ];
Qt 4.5 is licensed under the GPL version 2 or later (with an exception of
linking from every OSI approved license), LGPL version 2.1 or later or a
proprietary license:
meta.license = [ "GPLv2+OSS" "LGPL2.1+" "proprietary" ];
Collections
-----------
Some packages don't really have one single license, but are essentially
collections of several components released under multiple licenses. Mono is an
example of this, which includes a compiler dual licensed under the X11 license
and GPLv2, various other tools released under the GPLv2, runtime libraries
released under the LGPLv2.1 and class libraries released under the X11 licence.
In such cases we need to specify that the package is a collection of
subcomponents, each having its own meta attributes, e.g.:
meta.subcomponents = {
compiler = {
license = [ "X11" "GPLv2" ];
description = "Mono compiler";
};
tools = {
license = "GPLv2";
description = "Mono tools";
};
runtimeLibs = {
license = "LGPLv2.1";
description = "Mono runtime libraries";
};
classLibs = {
license = "X11";
description = "Mono class libraries";
};
};
Maybe when we don't want to explicitly specify everything for a subcomponent
the attribute meta.license will automatically apply to all subcomponents,
except when it's overridden in meta.subcomponents.*.license.
What do you guys think about these notations and conventions? I know this will
take some work/effort in implementing it, but I think this is worth the effort
and by using this approach we can build a mechanism that automatically
verifies/builds a system configuration that conforms to a policy a user wants
(e.g. if a user only wants to use free software, we can verify this and so on).
Best,
Sander
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
