| 1 |
On 01/01/2014 05:28 PM, Ulrich Mueller wrote: |
| 2 |
> Hi, |
| 3 |
> According to GLEP 23 [1], the LICENSE variable regulates the software |
| 4 |
> that is installed on a system. There is however some ambiguity in |
| 5 |
> this: should it cover the actual files installed on the system, or |
| 6 |
> everything that is included in the package's tarball? This question |
| 7 |
> was asked several times in the past and arose in bug 492424 [2] again. |
| 8 |
|
| 9 |
Why do I as a user care about the license of a package? I want packages |
| 10 |
to be in @FREE in case I need to modify (and redistribute) them. But I |
| 11 |
only need to modify the parts that I use. |
| 12 |
|
| 13 |
If an otherwise-GPL package pulls in the latest Justin Bieber CD with |
| 14 |
USE=badtaste, that's not really an issue for me, because I'm not using |
| 15 |
it. I'm happy to install the rest of the package with the USE flag |
| 16 |
unset. The CD might as well be a separate package with a different |
| 17 |
license as far as I'm concerned. |
| 18 |
|
| 19 |
In essence, I don't want to *use* code that isn't @FREE. This includes |
| 20 |
the installed files, of course, but also the build system (that I use |
| 21 |
temporarily). We could generalize this to "any file accessed during |
| 22 |
emerge" to be on the safe side. That ensures that if I need to modify |
| 23 |
(and redistribute) any part of the software that I use, I can. |
| 24 |
|
| 25 |
What use case is there for having the LICENSE apply to anything else? |
| 26 |
|
| 27 |
|
| 28 |
> I've always preferred the first interpretation, because the second one |
| 29 |
> would inevitably require us to repack many tarballs, in order to keep |
| 30 |
> their license in @FREE. This would for example include the Linux |
| 31 |
> kernel, where we could no longer use deblobbing, but would have to |
| 32 |
> provide our own tarball with firmware blobs removed. Not sure if users |
| 33 |
> would be happy if we wouldn't install from pristine sources any more. |
| 34 |
> We also have mirror and fetch restrictions which allow us to control |
| 35 |
> what tarballs we distribute, independent of the LICENSE variable. |
| 36 |
|
| 37 |
I think a better solution here, since these files are *installed*, is to |
| 38 |
introduce a new local flag (e.g. unfreeblobs) for the kernel that would |
| 39 |
append to LICENSE by the mechanism described below. |
| 40 |
|
| 41 |
|
| 42 |
> Nevertheless, I also see the point for covering the distfiles |
| 43 |
> contents. |
| 44 |
> |
| 45 |
> Within existing EAPIs we have only one LICENSE variable available. |
| 46 |
> (Extending it would be possible in future EAPIs, but we would end up |
| 47 |
> with a very long transition period.) USE conditional syntax is allowed |
| 48 |
> in LICENSE, though. So I wonder if this couldn't be used for the |
| 49 |
> intended purpose. For example, for specifying licenses of distfiles: |
| 50 |
> |
| 51 |
> LICENSE="<licenses of installed stuff> |
| 52 |
> srcdist? ( <licenses of unused stuff in distfiles> )" |
| 53 |
> |
| 54 |
> This idea was discussed within the licenses team, and the overall |
| 55 |
> reaction was positive. |
| 56 |
> |
| 57 |
> What do you think? |
| 58 |
> |
| 59 |
> Ulrich |
| 60 |
> |
| 61 |
> [1] http://www.gentoo.org/proj/en/glep/glep-0023.html |
| 62 |
> [2] https://bugs.gentoo.org/show_bug.cgi?id=492424#c3 |
| 63 |
> |
Archives