1 |
if you want to utilize the LICENSE variable in ebuilds to help with licensing |
2 |
compliance, you quickly run into issues with the licenses that require |
3 |
explicit copyright attribution. specifically, the BSD and MIT family of |
4 |
licenses. this clause is the annoying part: |
5 |
2. Redistributions in binary form must reproduce the above copyright |
6 |
notice, this list of conditions and the following disclaimer in the |
7 |
documentation and/or other materials provided with the distribution. |
8 |
|
9 |
since all of the ebuilds point to the same stock file (e.g. licenses/BSD) |
10 |
which has this stock header: |
11 |
Copyright (c) <YEAR>, <OWNER> |
12 |
the file is not sufficient for automatically producing a file that covers all |
13 |
packages in a compliant manner. |
14 |
|
15 |
in Chromium OS, we're attacking the problem in two ways: |
16 |
- during build (when all the source is available), scan for copyright |
17 |
owners and save the results into the vdb |
18 |
- allow for people to override on a per-package basis in the |
19 |
licenses/copyright-attribution/ subdir |
20 |
|
21 |
the first option would be nice to integrate into portage, but there are going |
22 |
to be cases where it either cannot find all the right answers (because the |
23 |
source doesn't correctly state it), or might find too many wrong answers |
24 |
(unused source files with outdated names). so we're going to want to |
25 |
integrate this somehow on a per-ebuild basis. metadata.xml might work, but |
26 |
doesn't work well with something that can change across ebuild $PVR's. so |
27 |
maybe something like a new LICENSE_COPYRIGHT variable that can be a scalar or |
28 |
array. |
29 |
|
30 |
has anyone else been looking at this ? or have thoughts on how to tackle the |
31 |
problem in a non-sucky way ? |
32 |
-mike |