| 1 |
On Tue, 21 Nov 2006 09:48:42 -0500 |
| 2 |
Chris Gianelloni <wolf31o2@g.o> wrote: |
| 3 |
|
| 4 |
> It does with Id Software, which is the only company who has ever made |
| 5 |
> any sort of complaint, which is what brought about check_license in |
| 6 |
> the first place. |
| 7 |
|
| 8 |
I think it would be a good idea to document this more explicitly in the |
| 9 |
GLEP, perhaps under "Motivation". Then if people come back to it later, |
| 10 |
the reasons are not lost: |
| 11 |
|
| 12 |
Current text from "Motivation": |
| 13 |
---- |
| 14 |
Furthermore, some software requires that a user interactively accept |
| 15 |
its license for its author's to consider it legally binding. This is |
| 16 |
currently implemented using ``eutils.eclass``. |
| 17 |
---- |
| 18 |
|
| 19 |
Suggest: |
| 20 |
---- |
| 21 |
Furthermore, some software licenses must be accepted interactively |
| 22 |
when the package is installed for the licensor to consider it legally |
| 23 |
binding. For example this has been explicitly brought to Gentoo's |
| 24 |
attention by Id Software, and upon inspection other software packages |
| 25 |
have similar license conditions. |
| 26 |
This is currently implemented using ``eutils.eclass``, and this |
| 27 |
GLEP does not affect how such licenses are accepted. |
| 28 |
---- |
| 29 |
|
| 30 |
|
| 31 |
Am I correct in thinking that the ACCEPT_LICENSE behaviour will just |
| 32 |
affect how portage calculates whether something can be installed or not |
| 33 |
(much like the behaviour w.r.t. KEYWORDS)? In this is the case, |
| 34 |
interactivity doesn't have much to do with it. As Brian suggests, a |
| 35 |
RESTRICT=interactive seems to be the most appropriate way to allow the |
| 36 |
admin to prevent portage from trying to install packages that need |
| 37 |
interaction during the install (whether it's for inserting CDs, |
| 38 |
accepting licenses, or any other reason). It depends on what |
| 39 |
"ACCEPT_LICENSE" means to the package manager. I take it to mean that |
| 40 |
the package may be considered for inclusion during emerge - i.e. the |
| 41 |
sysadmin is happy for portage to attempt to install packages under |
| 42 |
those licenses onto the system - rather than that licenses are actually |
| 43 |
accepted by the admin or user. If that's correct, perhaps naming it |
| 44 |
"ACCEPTABLE_LICENSES" would be clearer. |
| 45 |
|
| 46 |
Some packages require each user to accept the license explicitly when |
| 47 |
it is run (e.g. Acrobat Reader), some require it to be accepted |
| 48 |
explicitly during install (Enemy Territory) - in neither case should |
| 49 |
portage be taking automatic responsibility for actually accepting the |
| 50 |
license. |
| 51 |
|
| 52 |
|
| 53 |
On naming - please can we avoid calling any group "NOT-<something>". |
| 54 |
Since the ACCEPT_LICENSE syntax allows -<license>, it's much better to |
| 55 |
use affirmative names always; in this case for example |
| 56 |
INTERACTIVE-INSTALL-ACCEPTANCE instead of NON-MUST-HAVE-READ. One can |
| 57 |
define |
| 58 |
|
| 59 |
ACCEPTABLE_LICENSES="* -@INTERACTIVE-INSTALL-ACCEPTANCE" |
| 60 |
|
| 61 |
easily enough. |
| 62 |
|
| 63 |
|
| 64 |
-- |
| 65 |
Kevin F. Quinn |
Archives