1 |
Ciaran McCreesh wrote: |
2 |
> The duplicate licences situation is getting rather silly... We don't |
3 |
> include each variation for licences that vary only by the copyright |
4 |
> holder (if we did, we'd need a zillion new GPL-2s and BSDs, but instead |
5 |
> they just use <placeholder>s), and we don't care about whitespace |
6 |
> variations. |
7 |
> |
8 |
> <snip> |
9 |
> |
10 |
> |
11 |
|
12 |
I'll refer to the MIT license as the one in ${PORTDIR}/licenses, |
13 |
although I'm sure it exists in roughly the same form under some other |
14 |
names as well. |
15 |
|
16 |
The reasons that this system was chosen were correctness and |
17 |
maintainability. Many of these essentially use the good old MIT license |
18 |
with various companies' and/or individuals' copyrights at the top, as |
19 |
you have stated. However, the MIT license does refer to the copyrights |
20 |
within the license script itself, and many of the licenses have been |
21 |
slightly altered to include a company's name directly. I'm no lawyer, |
22 |
but to me this means that the license does indeed include the |
23 |
copyright. (Note that I'm not intricately familiar with other licenses |
24 |
that often have copyrights associated, so I don't know if MIT is |
25 |
unique). If this isn't correct, I'd be very happy to switch all the |
26 |
packages that use various forms of the MIT license over to it instead |
27 |
and you can blissfully ignore the next paragraph. However, I'd rather |
28 |
be on the safe/correct side than save a few MB that have to be |
29 |
downloaded once. |
30 |
|
31 |
Now, that splinters the licenses a good amount already, and thus |
32 |
maintenance becomes an issue. If one half of the licenses are unique, |
33 |
and we only keep unique ones, packages start depending on other licenses |
34 |
in a spaghetti-like fashion. We can't just go ahead and change any |
35 |
given license since it will mess up other packages dependent on that |
36 |
license. Like good programming practice, I would argue that less is not |
37 |
necessarily better. |
38 |
|
39 |
Although I'm happy to take suggestions, my warning is to think from the |
40 |
maintainer's perspective while proposing. That doesn't mean I'll whine |
41 |
and say go away, but rather that I'll expect you to provide some |
42 |
reasonable thought about maintainability, and possibly, like above, some |
43 |
data to help us out. To me, the argument first comes down to whether or |
44 |
not my thoughts in the first paragraph are valid. |
45 |
|
46 |
Joshua Baergen |
47 |
-- |
48 |
gentoo-dev@g.o mailing list |