This bug-report is not a rant about gentoo developers being evil and immoral. I would simply like to have the possibility of chosing if I want non-free software on my system or not (not). I think it would be nice for emerge to be able to determine whether or not the license of the software it tries to install is acceptable or not. In my case, I only want to use software which can be considered to be Free Software (according to the FSF lists of licenses). Also, barring things like "free" microsoft fonts would be very nice. I suggest this is done by an environment variable, such as ACCEPT_LICENSES, and if the license of the thing being installed does not conform, emerge could say "no", and tell me what license it was that failed the test. Perhaps a USE_LICENSES would be a better idea, specifically disallowing licenses with -license instead. The workaround involves checking all licenses manually, and is not really a viable option, considering all dependencies and stuff. Reproducible: Always Steps to Reproduce: emerge nvidia drivers. Actual Results: see how they get installed, without complaint. Expected Results: emerge will warn me that I'm trying to install non-free software, stopping the merge (if I've said "no" to nvidia licensing that is).
ACCEPT_LICENSES already exists (for this purpose) i just dont think there is any code behind it ;)
Has there been made any progress on ACCEPT_LICENSES? I am willing to implement it myself but want to avoid duplication of effort.
no, no code has been produced concerning said variable
*** Bug 30945 has been marked as a duplicate of this bug. ***
who is making this feature ? tom did you started to code something ?
Created attachment 21107 [details, diff] Basic implementation of license checking (Doesn't include * or -license) I've created a small patch to handle ACCEPT_LICENSES. Presently, the checks are done after the deptree is created. When I get some more time, I will move this stuff into the deptree creation and handle it the same as blocked packages. There is an inconsistency in the way ebuilds handle multiple licenses which needs to be addressed before this will work 100%.
Should have also said that the logic used by the patch is as follows: LICENSES=" lic1 lic2 | lic3 lic4" -> (lic1 AND lic2) OR (lic3 AND lic4)
LICENSES=" lic1 lic2 | lic3 lic4" The above should not be interpeted as: (lic1 AND lic2) OR (lic3 AND lic4) It should be interpeted at: lic1 AND (lic2 OR lic3) AND lic4 Meaning lic1, lic4, and at least one of lic2 or lic3 are required.
Created attachment 21265 [details, diff] New and improved licensing patch! New patch now includes -* and -license. The USE code has no support for * and, thinking about it, it could be considered legally dangerous so I did not include it at this stage. Also changed is that packages requiring a license to be accepted is done in the style of blockers. i.e. --pretend will list all packages. However, dependencies of packages that are missing an accepted license are not checked. Also, I have no idea what will happen when using tbz2 packages. Lastly, comments have been added!
Regarding the interpretation of the LICENSE, I'm not sure what to do. It seems that the original decision was "(LIC1 LIC2) | LIC3" but it wasn't documented. See bug 34146 to see what I'm talking about. I think I'll wait until that is sorted to implement what you've suggested (which is a much bigger PITA :-)
ACCEPT_LICENSE="*" is easy to check and i dont think should be left out if it's 'legally dangerous' then it's not our problem really ...
Created attachment 21296 [details, diff] Added support for "*", Changed ACCEPT_LICENSES to ACCEPT_LICENSE I added in support for "*". I wasn't concerned with the difficulty of it. My concern is that most users will set this if it is available. I'm not to certain about the legalities, but it seems very much that Gentoo Inc. could be held as an "accessory" to license infringement. I also changed ACCEPT_LICENSES to ACCEPT_LICENSE as it is already listed in portage.py under incrementals[]. Don't know if that means that portage will get incrementally from make.profile, make.globals, etc...
Created attachment 59091 [details, diff] The prior patch, updated to fit into emerge 2.0.51.22 The last patch no longer cleanly applied to emerge. I went ahead and fixed the rejections (blindly, mind you), and re-diffed. The resulting emerge seems to work correctly in most cases. Note that there are a few cases where this patch can't seem to properly figure out the license, and errs on the side of installing. Example run (with ACCEPT_LICENSE="-*"): $ ./emerge-test --pretend --emptytree --world These are the packages that I would merge, in order: Calculating world dependencies ...done! [license ] sys-apps/man-pages-2.01 (GPL-2) [license ] sys-libs/zlib-1.2.2 (ZLIB) [license ] sys-apps/grep-2.5.1-r7 (GPL-2) [license ] dev-util/monodevelop-0.5.1-r4 (GPL-2) [license ] media-sound/alsa-utils-1.0.8 (GPL-2) [license ] games-emulation/dosbox-0.63 (GPL-2) [license ] x11-misc/xscreensaver-4.16 (BSD) [license ] app-office/dia-0.94-r1 (GPL-2) [license ] app-shells/bash-2.05b-r9 (GPL-2) [license ] app-shells/sash-3.7 (freedist) [license ] sys-kernel/linux-headers-2.6.8.1-r2 (GPL-2) [license ] sys-libs/cracklib-2.7-r11 (CRACKLIB) [license ] app-text/dos2unix-3.1 (freedist) [license ] sys-apps/hotplug-20040923 (GPL-2) [license ] sys-apps/texinfo-4.8 (GPL-2) [license ] sys-apps/man-1.5p (GPL-2) [license ] games-arcade/frozen-bubble-1.0.0-r5 (GPL-2) [license ] net-wireless/ipw2200-1.0.3 (GPL-2) [license ] dev-lang/python-2.3.5 (PSF-2.2) [license ] app-admin/localepurge-0.2-r1 (GPL-2) [license ] app-cdr/cdrtools-2.01-r2 (GPL-2) [license ] app-editors/nano-1.3.4 (GPL-2) [license ] mail-client/mutt-1.5.8-r1 (GPL-2) [license ] app-arch/cpio-2.6-r3 (GPL-2) [license ] sys-devel/make-3.80-r1 (GPL-2) [license ] sys-process/procps-3.2.4-r3 (GPL-2) [license ] app-admin/syslog-ng-1.6.7 (GPL-2) [license ] sys-power/acpid-1.0.2-r2 (GPL-2) [license ] sys-devel/gcc-config-1.3.10-r2 (GPL-2) [license ] app-arch/gzip-1.3.5-r6 (GPL-2) [license ] net-misc/wget-1.9.1-r5 (GPL-2) [license ] sys-apps/which-2.16 (GPL-2) [license ] app-crypt/gnupg-1.4.1 (GPL-2) [license ] net-misc/openssh-3.9_p1-r2 (as-is) [license ] app-office/gnucash-1.8.9 (GPL-2) [license ] media-sound/id3v2-0.1.11 (GPL-2) [license ] sys-devel/gcc-3.4.3.20050110-r2 (GPL-2) [license ] app-misc/cdctl-0.15 (free-noncomm) [license ] media-sound/alsa-tools-1.0.8-r1 (GPL-2) [license ] sys-fs/dosfstools-2.10-r1 (GPL-2) [license ] sys-fs/reiserfsprogs-3.6.19 (GPL-2) [license ] media-video/gxine-0.3.3-r1 (GPL-2) [license ] sys-devel/libtool-1.5.16 (GPL-2) [license ] app-text/enscript-1.6.3-r3 (GPL-2) [license ] sys-apps/gawk-3.1.3-r2 (GPL-2) [license ] app-arch/tar-1.15.1 (GPL-2) [license ] sys-apps/sed-4.1.4 (GPL-2) [license ] sys-libs/glibc-2.3.5 (LGPL-2) [license ] sys-devel/patch-2.5.9 (GPL-2) [license ] sys-process/vixie-cron-4.1-r7 (as-is) [license ] media-video/ati-drivers-8.12.10 (ATI) [license ] sys-devel/autoconf-wrapper-2-r1 (GPL-2) [license ] net-dialup/ppp-2.4.2-r10 (BSD) [license ] net-misc/dhcpcd-1.3.22_p4-r5 (GPL-2) [license ] gnome-base/gnome-2.8.3-r1 (as-is) [license ] sys-apps/coldplug-20040920 (GPL-2) [license ] x11-misc/synaptics-0.14.0 (GPL-2) [license ] media-video/xine-ui-0.99.3 (GPL-2) [license ] app-text/unix2dos-2.2 (freedist) [license ] sys-apps/hdparm-5.9 (as-is) [license ] sys-apps/less-382-r2 (GPL-2) [license ] app-misc/zisofs-tools-1.0.4-r1 (GPL-2) [license ] net-misc/ntp-4.2.0-r2 (as-is) [license ] net-analyzer/macchanger-1.5.0 (GPL-2) [license ] dev-python/psyco-1.2 (MIT) [license ] sys-apps/iproute2-2.6.10.20050112-r1 (GPL-2) [license ] sys-apps/kbd-1.12-r4 (GPL-2) [license ] sys-devel/binutils-config-1.8-r2 (GPL-2) [license ] sys-devel/gnuconfig-20050324 (GPL-2) [license ] sys-devel/flex-2.5.4a-r5 (FLEX) [license ] net-dialup/wvdial-1.54.0 (LGPL-2) [license ] sys-fs/e2fsprogs-1.35-r1 (GPL-2) [license ] app-editors/vim-6.3.068 (vim) [license ] sys-libs/readline-4.3-r5 (GPL-2) [license ] sys-apps/module-init-tools-3.0-r2 (GPL-2) [license ] sys-apps/file-4.12 (as-is) [license ] app-arch/bzip2-1.0.3 (BZIP2) [license ] sys-apps/portage-2.0.51.19 (GPL-2) [license ] sys-devel/automake-1.9.5 (GPL-2) [license ] net-misc/iputils-021109-r3 (BSD) [license ] net-dialup/slmodem-2.9.9a-r2 (Smart-Link) [license ] sys-apps/shadow-4.0.5-r3 (BSD) [license ] sys-apps/groff-1.19.1-r2 (GPL-2) [license ] app-emulation/wine-20050111-r1 (LGPL-2.1) [license ] app-portage/ufed-0.36 (GPL-2) [license ] net-im/gaim-1.3.0 (GPL-2) [license ] sys-apps/diffutils-2.8.7-r1 (GPL-2) [license ] net-p2p/bittorrent-3.4.2-r2 (MIT) [license ] games-arcade/pydance-1.0.3 (X11) [license ] net-misc/streamtuner-0.12.4 (BSD) [license ] app-laptop/radeontool-1.5-r1 (ZLIB) [license ] sys-apps/util-linux-2.12i-r1 (GPL-2) [license ] sys-fs/lvm2-2.01.09 (GPL-2) [license ] sys-apps/net-tools-1.60-r11 (GPL-2) [license ] media-libs/freetype-2.1.9-r1 (FTL) [license ] media-libs/libpng-1.2.8 (as-is) [license ] dev-db/unixODBC-2.2.6 (GPL-2) [license ] x11-misc/ttmkfdir-3.0.9-r3 (as-is) [license ] dev-lang/perl-5.8.5-r5 (Artistic) [license ] sys-libs/ncurses-5.4-r6 (MIT) [license ] dev-libs/expat-1.95.8 (as-is) [license ] x11-base/opengl-update-2.2.1 (GPL-2) [license ] media-libs/fontconfig-2.2.3 (fontconfig) [license ] x11-terms/xterm-200-r1 (X11) [license ] media-libs/libmng-1.0.4 (as-is) [license ] net-print/cups-1.1.23-r1 (GPL-2) [license ] media-libs/jpeg-6b-r4 (as-is) [license ] net-firewall/iptables-1.2.11-r3 (GPL-2) [license ] sys-apps/baselayout-1.9.4-r6 (GPL-2) [license ] net-mail/fetchyahoo-2.8.6 (LGPL-2.1) [license ] sys-devel/prelink-20041123 (GPL-2) [license ] net-dns/bind-tools-9.2.5 (as-is) [license ] sys-devel/bison-1.875d (GPL-2) [license ] sys-boot/grub-0.96-r1 (GPL-2) [license ] net-misc/rsync-2.6.0-r4 (GPL-2) [license ] sys-apps/debianutils-1.16.7-r4 (GPL-2) [license ] x11-misc/hotkeys-0.5.7.1-r1 (GPL-2) [license ] net-dialup/pppconfig-2.3.11 (GPL-2) [license ] net-www/netscape-flash-7.0.25 (Macromedia) [license ] sys-apps/coreutils-5.2.1-r5 (GPL-2) [license ] sys-devel/automake-wrapper-1-r1 (GPL-2) [license ] sys-process/psmisc-21.5 (GPL-2) [license ] sys-fs/sysfsutils-0.4.0 (GPL-2) [license ] sys-fs/udev-056 (GPL-2) [license ] sys-apps/findutils-4.1.20-r1 (GPL-2) [license ] www-client/mozilla-firefox-1.0.4 (MPL-1.1) [license ] sys-devel/m4-1.4.2-r1 (GPL-2) [license ] media-gfx/inkscape-0.41 (GPL-2) [license ] net-wireless/kismet-2005.04.1 (GPL-2) [license ] sys-devel/autoconf-2.59-r6 (GPL-2) [license ] app-shells/tcsh-6.13-r1 (BSD) [license ] media-libs/libart_lgpl-2.3.17 (LGPL-2.1) [license ] net-misc/curl-7.13.1 (MIT) [license ] dev-util/pkgconfig-0.15.0 (GPL-2) [license ] app-arch/zip-2.3-r4 (Info-ZIP) [license ] x11-libs/startup-notification-0.8 (LGPL-2) [license ] sys-libs/pam-0.77-r6 (PAM) [license ] dev-java/blackdown-jdk-1.4.2.01-r2 (sun-bcla-java-vm) [license ] app-arch/unzip-5.50-r2 (Info-ZIP) [license ] dev-java/blackdown-jre-1.4.2.01-r1 (sun-bcla-java-vm) [license ] app-portage/gentoolkit-0.2.0 (GPL-2) [license ] net-irc/xchat-2.4.3 (GPL-2) [license ] app-admin/fpm-0.60 (GPL-2) [ebuild N ] sys-libs/pwdb-0.62 [ebuild N ] sys-devel/binutils-2.15.92.0.2-r7 *** Please update portage to the above version before proceeding. Failure to do so may result in failed or improper merges. A simple 'emerge -u portage' is sufficient. [ebuild N ] x11-base/xorg-x11-6.8.2-r1 [ebuild N ] x11-libs/qt-3.3.4-r3 [ebuild N ] app-office/openoffice-1.1.4-r1
Any progress on this? It is a nice feature to have, and at least a preliminar patch is already there, so...
*** Bug 109876 has been marked as a duplicate of this bug. ***
*** Bug 112416 has been marked as a duplicate of this bug. ***
Removing old keyword.
*** Bug 12551 has been marked as a duplicate of this bug. ***
*** Bug 118514 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > I added in support for "*". I wasn't concerned with the difficulty of it. My > concern is that most users will set this if it is available. I'm not to certain > about the legalities, but it seems very much that Gentoo Inc. could be held as > an "accessory" to license infringement. > Why would anybody need to accept a license at all to use a piece of software? You only need to accept a license if you are going to do something which would otherwise be a violation of copyright - such as distributing it. Gentoo, Inc., clearly needs to accept a license in order to host a file on one of its mirrors, for example. On the other hand, if Gentoo had a license from Microsoft to distribute Windows Server 2003, I wouldn't need a license to use it (obviously MS would not give out licenses to freely distribute software). Sorry if this sounds like a Stallman rant - licenses are only needed when you are doing something which would otherwise be illegal - such as copying software. Compiling software that was acquired legally does not require a license at all...
according to law of various country, license does not limit distribution of a peace of software, but also the use of it ! In example, from memory, MS-XP-Home has a license limiotation about incoming connections: a givent computer can not accept more than 4 incoming requests (including all requests of all services at a time), because if you have more than 4 requests at a time on a box, MS considers you better want a Profesionnal or Server License ... As an example to that, MS instalaltion CD for MS systems ask for agreement BEFORE installation, and then , once more for each user for recent systems. Knoppix has a License agreement BEFORE DOWNLOAD, and a license reminder at boot time. OOo has a license agreement for every single user using it (according to local profile). License of most softwares deals about how many users can use the application at a time on the computer, how many computers to install it on, for how long, and which features may be used. Agreement to license to use a software is a legal problem to me. See http://bugs.gentoo.org/show_bug.cgi?id=112416 Limiting the License problem to copy is non sense to me: remember XP home can not accept more than 4 incoming network connection at a time: thats about use, not distribution. Thats about *one* license I have read and remember about. I guess about free softwares some stuff under MySQL or some BSD license may have similar limitations related to use, and not only to *re-distribution*. I can tell about MS because I have read it, and did not read yet all forms of SQL and BSD ones ... but for example, Xilinx and Oracle Licenses may also be very interesting. Finally, some driver license have LUA on CD folder, with a lebel that sounds like: "opening this felder to extract the CD, and breaking this label implies agreement of the license printed in the book that came in the same box as this folder when you bought the box in the shop; if this folder was accidently delivered to you without the book-LUA, please ask one to your local vendor." (from memory). Here license does not event to 'using soft', not even installing it ... but just taking the CD out of the box !
(In reply to comment #21) > according to law of various country, license does not limit distribution of a > peace of software, but also the use of it ! > > In example, from memory, MS-XP-Home has a license limiotation about incoming > connections: a givent computer can not accept more than 4 incoming requests > (including all requests of all services at a time), because if you have more > than 4 requests at a time on a box, MS considers you better want a Profesionnal > or Server License ... Uh, what does the MS license have to do with the law? It is illegal to violate the law. It is not illegal to violate a license, except to the degree that violating the license eliminates permission to otherwise violate copyright, or otherwise violates the law. If you violate the GPL, for example, you lose any rights to distribute the software. You do not lose any rights to use the software. Likewise, if you violate an MS EULA, you lose any rights under the EULA to distribute Windows. EULAs as they are commonly used are a fairly controversial area of law, and are not well-tested in the courts. Most lawsuits are over distribution of software, not use...
Er, I'd like to put forward that perhaps bugzilla comments aren't the appropriate venue for a discussion as to what's legally required in terms of license acceptance, whether it be for use or distribution. To my mind, at the very least it's enough of a gray area that it'd be something worthwhile to have around, and if anyone doesn't like it they can just "ACCEPT *" and be done with it. If you want to debate the usefulness of the feature I'd say that gentoo-dev would be the place for it, not here. (Says the person wholly unrelated to any official gentoo development)
> It is illegal to violate > the law. It is not illegal to violate a license, except to the degree that > violating the license eliminates permission to otherwise violate copyright, or > otherwise violates the law. I thought that violation of *some* licenses could lead to forbidding the use of related softwares ... even if those cases are rare, I think they exist. > area of law, and are not well-tested in the courts. Most lawsuits are over > distribution of software, not use... maybe because it is VERY HARD for developper to proof the soft have been used above the way restricted by the license ... an area where TCPA/Palladium and associated technologies could be important. (please, I do NOT think about TCPA for music protection, but ONLY software use). As example, Xilinx sells 'grouped licenses' to universities, where 20 students can use a soft within the uni: the software being installed on all box of a room, only 20 people at a time can *use* it, when the practical users did not actually pay for that, and the people who actually paid (financial service) is not to use it ... thats why I desagree with your last point. The point of http://bugs.gentoo.org/show_bug.cgi?id=112416 being EXACTLY to ask to remove the default "ACCEPT *" to make Gentoo more easily comply to laws in contries on the earth ... (some one told me I could eventually move contry if I dont like local laws, why not even change planet ?) Thats why I ask for a Gentoo license agreement before first use of 'portage & emerge'
Is anything new happening here? Any search I perform on the topic of ACCEPT_LICENSE implementation shows only old and outdated links to various forums where everyone seems to claim that it's only a matter of time before it's implemented. But it's been years and there's still no code behind the variable? I'm not a programmer, but it doesn't look like a real problem.. I could hire someone to implement it :)
*** Bug 58195 has been marked as a duplicate of this bug. ***
This is on my projects list, Aiming for simplified (non-grouping as of yet) since set support is quite shaky. Would require essentially USE sets.
*** Bug 137030 has been marked as a duplicate of this bug. ***
Well, I guess you have already given this a bit of thought but, why not using virtual packages and package dependencies? licenses/gpl licenses/bsd ... license-groups/freesoftware license-groups/opensource Blocking and accepting licenses can be done by just masking the licenses you don't want to have. For those uses who just don't care, they don't have to mask any license.
I like Ivan Perez' idea in comment #29 However, I am not involved in portage development... Anyway, it would be easy to implement and easy to use. It's just nice and clear. Thanks Ivan.
(In reply to comment #29) > Well, I guess you have already given this a bit of thought but, why not using > virtual packages and package dependencies? > > licenses/gpl > licenses/bsd > ... > license-groups/freesoftware > license-groups/opensource > > Blocking and accepting licenses can be done by just masking the licenses you > don't want to have. For those uses who just don't care, they don't have to mask > any license. > Works yes; but isn't at all pretty (contamination of namespaces).
Using virtual packages also makes it difficult to allow for an ACCEPT_LICENSE="*" setting - if you don't care what licenses gentoo and the mirrors are accepting when they distribute software to you.
(In reply to comment #31) > (In reply to comment #29) > > Well, I guess you have already given this a bit of thought but, why not using > > virtual packages and package dependencies? > > > > licenses/gpl > > licenses/bsd > > ... > > license-groups/freesoftware > > license-groups/opensource > > > > Blocking and accepting licenses can be done by just masking the licenses you > > don't want to have. For those uses who just don't care, they don't have to mask > > any license. > > > > Works yes; but isn't at all pretty (contamination of namespaces). Not to mention that changing all ebuilds in the tree to add a ... ehm ... "special" dependency isn't an option (well, could do it internally), that you can't create a "licenses" category (clashes with the existing dir), error messages would be confusing for some people from my experience and adds naming limitations on licenses (must be valid package names). The last point is the real killer for this idea.
(In reply to comments #33 and #32) >(In reply to comment #31) >> (In reply to comment #29) >> > Well, I guess you have already given this a bit of thought but, why not using >> > virtual packages and package dependencies? >> > >> > ... >> > >> >> Works yes; but isn't at all pretty (contamination of namespaces). > I do agree with the 'contamination of namespaces' thing. However, it thinks it's kind of pretty. Adding more code to check the valid licenses is much more difficult than adding a few more ebuilds. > > >Not to mention that changing all ebuilds in the tree to add a ... ehm ... >"special" dependency isn't an option (well, could do it internally), Actually, you can do it, and it's a very easy change. It wouldn't be hard to write a script that changes every ebuild, adding this new dependency to it.I guess your point is related to the big, huge commit to the portage main tree, when everything is changed. But both systems can coexist for a while (it wouldn't be very pretty, though): you add the licenses as packages, then you add the dependencies for every new package, then you update the old ones. > that you >can't create a "licenses" category (clashes with the existing dir), The "licenses" category name was just an example. You can pick name you like the most. > error messages would be confusing for some people from my experience I do agree with this, in a way. People with a bit of experience would be a wee bit confused. However, it would be much more easy to understand a system where everything has the same data type, wouldn't it? If I want to block a specific license, I know that the clue to find out how is inside the portage tree. That's a starting point. > and adds naming >limitations on licenses (must be valid package names). >The last point is the real killer for this idea. Actually, I can't recall any license with an invalid package name. gpl2? bsd? freebsd? Can you give any example? >Using virtual packages also makes it difficult to allow for an >ACCEPT_LICENSE="*" setting - if you don't care what licenses gentoo and the >mirrors are accepting when they distribute software to you. In that case, just don't mask any license. Anyway, the main point of my suggestion is that, in my opinion, it's much better to add new packages than to add new code. Most of the license ebuilds (if not all of them) should be almost empty. The main question here should be what structure, data type, pattern, etc. represents the concept the best. I think the biggest problem is the "changing all ebuilds in the tree to add a special dependency" one. We are using new variables for every new feature. Different video cards? Let's add a new variable in make.conf (and include some code for it, I guess). Input devices? Another new variable! Licenses? Another one. This is just the same problem under different names. All of them could have been solved by adding new ebuilds to the portage tree. Cheers
(In reply to comment #34) > >Using virtual packages also makes it difficult to allow for an > >ACCEPT_LICENSE="*" setting - if you don't care what licenses gentoo and the > >mirrors are accepting when they distribute software to you. > In that case, just don't mask any license. Agreed - hadn't thought about that but you are correct that it would just install all the virtual packages as needed unless you explicitly choose to reject packages with a particular license. > I > think the biggest problem is the "changing all ebuilds in the tree to add a > special dependency" one. Well, in theory you need only create a new policy and adjust repoman to complain if it isn't followed. You don't necessarily need to go and fix every ebuild overnight. Long-term support would become automatic. There are probably 100 examples of deprecated behavior that was handled in this way. If you wanted full support overnight then a massive commit would be the only way to accomplish it.
I like the package approach. If you step back a second and remind yourself that accepting licenses is just a dependency problem (you depend on accepting the license the package uses), using DEPEND for the task seems like a sane idea. Looking through GLEP 23, the LICENSE variable even uses the DEPEND syntax, so > [snip] and adds naming > limitations on licenses (must be valid package names). > The last point is the real killer for this idea. This isn't really an argument. Assuming there was a license that uses a name which is invalid as pkgname: Who cares? How is this any different then a software package that uses a name which doesn't match our requirements? We just make the name sane. Let the license package install the license text in /usr/share/licenses, so the user can read the text whenever he likes. For licenses that need to be approved interactively, the license can be masked with a note that unmasking it is taken as acceptance of the license. Further, the groups logic can get realized with meta-packages which the license packages depend on. However, this makes the whole issue no more a portage-related discussion. I think I will write up a GLEP and have it discussed to see what the ebuild devs think. Once the council has accepted it, everything can get started.
(In reply to comment #34) > (In reply to comments #33 and #32) > >Not to mention that changing all ebuilds in the tree to add a ... ehm ... > >"special" dependency isn't an option (well, could do it internally), > Actually, you can do it, and it's a very easy change. It wouldn't be hard to > write a script that changes every ebuild, adding this new dependency to it.I > guess your point is related to the big, huge commit to the portage main tree, > when everything is changed. But both systems can coexist for a while (it > wouldn't be very pretty, though): you add the licenses as packages, then you > add the dependencies for every new package, then you update the old ones. Well, with "internally" I meant that portage does it based on the LICENSE field without any ebuild modifications. Adding those deps to the ebuilds would be redundant. > > > and adds naming > >limitations on licenses (must be valid package names). > >The last point is the real killer for this idea. > Actually, I can't recall any license with an invalid package name. > gpl2? bsd? freebsd? Can you give any example? Depends if you want to version licenses the usual way or not. If not (so each licenses is a separate "package") you'll get problems with all versions that contain a version (GPL-2, CPL-0.5, APL-1.0, ...), if not you'll have to invent versions for all non-versioned licenses. And then there are a few licenses that aren't valid anyway: bea.jsr181, werken.xpath, distributed.net, gips_iLBClicense.pdf, bea.ri.jsr173 to name a few. Another issue I forgot to mention is that you'll get more duplicate package names (e.g. cedega), not a big issue but another annoyance. Don't get me wrong, I actually like this idea, but these are real problems making it pretty difficult.
(In reply to comment #36) > I like the package approach. If you step back a second and remind yourself that > accepting licenses is just a dependency problem (you depend on accepting the > license the package uses), using DEPEND for the task seems like a sane idea. > > Looking through GLEP 23, the LICENSE variable even uses the DEPEND syntax, so > > > [snip] and adds naming > > limitations on licenses (must be valid package names). > > The last point is the real killer for this idea. > > This isn't really an argument. Assuming there was a license that uses a name > which is invalid as pkgname: Who cares? How is this any different then a > software package that uses a name which doesn't match our requirements? We just > make the name sane. Let the license package install the license text in > /usr/share/licenses, so the user can read the text whenever he likes. For > licenses that need to be approved interactively, the license can be masked with > a note that unmasking it is taken as acceptance of the license. > > Further, the groups logic can get realized with meta-packages which the license > packages depend on. > > However, this makes the whole issue no more a portage-related discussion. I > think I will write up a GLEP and have it discussed to see what the ebuild devs > think. Once the council has accepted it, everything can get started. >
(In reply to comment #36) > so the user can read the text whenever he likes. Users don't actually need to read the text of licenses unless they are distributing software - you only need a license when you would otherwise be violating copyright. > For > licenses that need to be approved interactively, the license can be masked with > a note that unmasking it is taken as acceptance of the license. > This is contrary to the earlier assertion that if a license were not user-masked it would be seamlessly merged. Users should not be required to manually unmask licenses to emerge packages - users have no need to accept licenses in the first place unless they are distributing software. Now, if gentoo is hosting copyrighted files on its servers for mirrored distribution it is important that gentoo ensure that it has a valid license to distribute them. Users do not need to be pestered when installing a package merely because the author of the package would prefer it. If somebody has a license to distribute a copy of a piece of software to me, I don't need a license to run it. Now, if I want to make 20 more copies of it and run them all, then I do need a license - not to run it but to make a non-transient copy of it. The same applies to books/music/etc - you don't need a license to read it or play it (even with a few others in the room), but you do need a license to distribute copies. If license support is being implemented to give users the option to explicitly avoid using software distributed under certain licenses then it is a great idea (such as when prototyping embedded systems that will get distributed en masses and need to be properly licensed, or making LiveCDs/etc). If license support is being implemented to somehow compel users to "accept" licenses then I have an issue with it. Users of software do not have a legal need to "accept" a license at all - at least not in any jurisdiction I'm familiar with (as if all users were even subject to the same laws with regard to this topic). It should be the role of a distro to help users be compliant, but the user is the best person to determine what compliant behavior is. It is not the role of a distro to try to compel a user to be compliant, as a distro is not in any position to determine what compliance entails except as to its own actions. So, making it easy for users to avoid packages with licensing issues that might make further distribution difficult is a great thing, but trying to force users to accept a license is not - as users may not have any legal need to accept the license at all, and if they do it would be dependant on intended use or jurisdiction.
(In reply to comment #39) > Users don't actually need to read the text of licenses unless they are > distributing software - you only need a license when you would otherwise be > violating copyright. Sounds like you need to be reading more license... Using deps in place of LICENSE is no good. I'll only offer 2 points but one or both should appeal to >99% of people. #1 Both paludis and pkgcore (alphabetical order!) already support masking based on LICENSE. #2 Abstracting LICENSE to DEPEND means that interactive user interfaces will be unable to interactively ask for license acceptance in the long term. Either way, I'll update my patch of 22 months ago and get it finalized this weekend. Unless somebody wants to do it before me? It's only a couple of hours work for those that actually have a couple of hours to spare...
> Users don't actually need to read the text of licenses unless they are > distributing software - you only need a license when you would otherwise be > violating copyright. May be right, IANAL, but even if, the user might want to redistribute the software, so he is required to read it. Think of giving a binpkg to a friend/someone on IRC who broke his box. That being said, *I* (others may) don't care at all about this. I am just giving an example of how the current behaviour (yes, we do it already) can be kept within the new systems. Whether or not we drop it after all - I don't care, I'm just stating that it works in case we don't. Either way, this has nothing to do with this bug which is about the implementation. I propose you take that discussion to gentoo-dev@lists.gentoo.org.
(In reply to comment #40) > > Sounds like you need to be reading more license... > Uh, while I have read plenty of licenses, what bearing do they have on what I cannot do? A license can grant you rights, it cannot take them away. Copyright law prohibits me from distributing software (in the US at least), a license from the copyright holder might give me that right back (perhaps in exchange for some conditions). If I want to know what I can or can't do I have to start with the law in my jurisdiction. If the law doesn't say that I can't do something, then I can do it. There aren't any laws stating that I need any kind of permission to use software, read books, watch movies, etc - only to copy them. So, as long as I am not copying/distributing software I do not need to be concerned with what licensing on that software is. Now, many people do have a need to be concerned with licenses, but in general it isn't the end-user sitting at their PC. > #2 Abstracting LICENSE to DEPEND means that interactive user interfaces will be > unable to interactively ask for license acceptance in the long term. > Is that a problem? Are gentoo users clamoring for more ebuilds that cannot be emerged non-interactively? It is a big enough of a pain when ebuilds don't auto-fetch packages, but that isn't in gentoo's control if the vendor doesn't keep the package at a constant URL and doesn't license redistribution. Once a package has been copied/downloaded no further issues remain with using the software, and forcing users to type "yes" when emerging packages is just an extra hurdle. What gentoo legal problems exist with the status quo? If we're going to implement license filtering, shouldn't it be in a way that makes devs/users happy, rather than unhappy? What is the actual driver/sponsor/purpose behind this change? All things being equal if there is a way to make the users happy and a way to make the mythical license police happy, doesn't it make more sense to make the users happy? Now, if gentoo is currently subject to some legal liability that we are working to correct, and forcing users to accept licenses somehow mitigates that liability, then perhaps it makes sense. I'm not aware of any legal theory that makes software distributers who have a license to distribute liable for actions of users that violate that license - and at worst the remedy would probably be to not allow gentoo to mirror the file in question, which would be of more harm to whoever would be bringing suit against gentoo than to gentoo itself. Perhaps I'm just missing the point of this whole exercise?
(In reply to comment #41) > > Users don't actually need to read the text of licenses unless they are > > distributing software - you only need a license when you would otherwise be > > violating copyright. > > May be right, IANAL, but even if, the user might want to redistribute the > software, so he is required to read it. Think of giving a binpkg to a > friend/someone on IRC who broke his box. Well, the user might be required to read it if he intended to redistribute it and doing so was otherwise illegal in his jurisdiction (not everyone lives in the US). > Either way, this has nothing to do with this bug which is about the > implementation. I propose you take that discussion to > gentoo-dev@lists.gentoo.org. > Agreed that non-implementation-oriented discussion should be outside of bugzilla. My only concern implementation-wise is that the system be seamless to users who don't care what distribution licenses apply to the software they use. ACCEPT_LICENSE support should therefore allow for a wildcard acceptance of all packages without interaction (regardless of redistribution restrictions), and most likely this should be the default behavior, but this is probably more debatable. In any case, any wording in parameters/instructions/documentation/etc should not in any way suggest that users are somehow agreeing to abide by the wording of the license by installing software which uses it - a license only applies to distribution, not use. If users must be prompted to answer a yes/no prompt it should be along the lines of "This software is subject to the foo license for any activities not otherwise permitted by law or fair use in your jurisdiction, do you want to install this software and others which utilize the same licensing?", and then have a no/yes-always/yes-once type of response. Honestly, though, a less interactive solution would be better.
(In reply to comment #42) Wow... too many words... can't comprehend... Seriously, I saw maybe two or three points in two or three hundred words. If you can state them clearly, I'll see my way to answering them clearly.
Ok, I just wanted to take a moment to apologize for the amount of discussion in this forum. I guess my basic point is that it seems like there are differing opinions as to what the goal of this project is. It sounds like a requirements issue, essentially. The first comment in this bug was asking about the ability for users to choose to exclude non-free software, and it seems like the request is morphing into a license-acceptance-enforcement system. This really isn't the right forum to debate requirements. Might I suggest that if this is going to end up being something transparent to most users (ie it doesn't do anything by default unless you mask licenses) that it just be implemented in the most expedient manner possible in the opinion of the devs doing the work? If, on the other hand, the intent is to enforce software license acceptance perhaps this should really be a GLEP or something along those lines - this would give the requirements/scope/etc a public airing with an official decision-making process in place. It just strikes me that something like that should be a policy decision of the distro and not the result of a few implementation decisions discussed in some obscure bug report. Once the GLEP is approved then there are no longer open questions regarding puprose/scope/etc. Actually, getting back on topic here is another random idea - if somebody wants the ability to avoid installing software based on license might a non-portage solution be to simply write a utility that parses a list of acceptable licenses and creates a package.mask or .unmask file? The use of such a tool would be complete non-intrusive to users who don't care to use it.
I haven't really this bug past comment #12 (which was my own..) While I personally think that the profiles should provide a set of OSS-compatible LICENSEs in their ACCEPT_LICENSE property and that ACCEPT_LICENSE should be an incremental, it seems that many people think that almost all license should be accepted by default because that's the way it has alweays been. Personally, I'm for the former but that really has (almost) nothing to do with the reimplementation of my patch from comment #12. As has been said, license issues are not to be decided by the implementors of portage. That in itself sayd that this bug should be brought up on gentoo-dev@gentoo.org. And it has been brought under the subject of "GLEP 52". Either way, whether the default is "-* +OSS-LICENSES" or "* -DOOM3 -OTHER-INTERACTIVE-LICENSES", the difference to the portage team is very slight. The root decision really needs to go all the way to the top.
(In reply to comment #42) > (In reply to comment #40) > > > > Sounds like you need to be reading more license... > > > > Uh, while I have read plenty of licenses, what bearing do they have on what I > cannot do? A license can grant you rights, it cannot take them away. While not common in the FOSS world, many licenses (attempt) to do just that. If we go and make an ebuild for Windows XP (crazy free version), you need to actually read and agree to the license prior to running the software; if you do not agree to the license you must return the software for a full refund. Many binary software packages request things of you in their licenses; or have information; or they make unwieldy (and often illegal) demands of you in their EULA. That doesn't mean it should be ignored however.
(In reply to comment #47) > ... (and often illegal) ... But possibly legal.. We have to cater for the loweest common denominator..
(In reply to comment #48) > But possibly legal.. We have to cater for the loweest common denominator.. > Well, I don't agree with this if only because there will always be some jurisdiction somewhere with some onerous rule that "must be obeyed", and then to comply with positions that even legal experts don't agree on is going to greatly limit your options. However, I do agree with your previous comments - the focus should be on making the software work unobtrusively and let the defaults be a policy issue. In any case, this does belong in -dev as you pointed out...
*** Bug 151813 has been marked as a duplicate of this bug. ***
Any news on this? I'd like to choose FSF-approved licenses only as well :-)
There is one big probleme I can think of, if licenses aproval was managed by package installation: imagine package A have an aproved license Ln and B license M. B depends on A. Imagine root apooved L, but not M. When trying emerge B, portage will try and suceed installation of A, then will try B, and fail. Result is that only at this stage root is said not to be allowed to install B, but A now lays quietly on the computer: there is a useless package in the box; this is un-avoidable with one package per license system. What I loved on portage was precisely that, in stable architectures, when ebuilds all work well, root is always warned about problems before actually compiling sources. I think this advantage should be kept for licenses as well. I mean, we need to find a way to get license check and warnings BEFORE "emerge -va foobar" would show the list, as it is done for masked ebuids. this leads me to the idear of using flags ? Hope there is an alternative to flags if you dont want to use them for this. Good luck.
(In reply to comment #52) > What I loved on portage was precisely that, in stable architectures, when > ebuilds all work well, root is always warned about problems before actually > compiling sources. I think this advantage should be kept for licenses as well. This is not always true, since portage won't warn situations like the following: Package A has use flag myflag Package B has use flag myflag2 Package B with 'myflag2' needs package A to be compiled with 'myflag'. Portage will emerge package A and warn about the problem when trying to unpack or, most likely, configure package B.
(In reply to comment #52) > imagine package A have an aproved license Ln and B license M. B depends on A. > Imagine root apooved L, but not M. When trying emerge B, portage will try and > suceed installation of A, then will try B, and fail. Result is that only at > this stage root is said not to be allowed to install B, but A now lays quietly > on the computer: there is a useless package in the box; this is un-avoidable > with one package per license system. Won't happen, as B would be (implicitly) masked so the dependency calculation would fail before anything gets built/installed.
Relooking over my old patch, it's full of problems. I can now see why it was never included. ;) dep_check really needs to be refactored so that it'll work with licenses as well. Once that's done, it'd just be a case of updating portdbapi.gvisible and getmaskingreason. Refactoring dep_check looks like it's going to be a not enjoyable experience though...
Created attachment 100120 [details, diff] Patch against 2.1.2_pre3-r6 Rewritten as per my above comment. Didn't really refactor dep_check and friends at all as the changes were minimal by adding (yet another) parameter. I changed the "if trees is None" code in dep_zapdeps as there no longer seems to be a global db var and the change means that it'll work for *DEPEND and LICENSE vars. I've also added back an optimization to config.setcpv that seems to have been removed at some stage that skips calling regenerate when USE flags haven't changed. This brings my -uDNvp down from 22 seconds to 11 seconds. With the ACCEPT_LICENSE modifications, it comes down from 45 seconds to 13 seconds. Given the number of bugs in my recent patches, I'm sure this one has its fair share as well. ;) Review and testing would be appreciated.
(In reply to comment #56) > Given the number of bugs in my recent patches, I'm sure this one has its fair > share as well. ;) Review and testing would be appreciated. Nice patch. I made a few changes and committed it in svn r4792. The only semantic difference in my patch, as far as users are concerned, is that when ACCEPT_LICENSE is unset it defaults to * for backward compatibility. That way, people who don't care about licenses don't even have to think about it.
This has been released in 2.1.2_pre3-r7. ACCEPT_LICENSE is documented in `man make.conf` and package.license is documented in `man portage`. I've written a script that generates a list of licenses that haven't been accepted for installed packages: http://dev.gentoo.org/~zmedico/portage/branches/2.1/bin/required-licenses.py Set ACCEPT_LICENSE="" in /etc/make.conf and then run that script to see what licenses need to be added.
(In reply to comment #57) > ACCEPT_LICENSE is unset it defaults to * for backward compatibility. Umm... so do we still use check_license in the ebuilds for packages that *require* the user to accept it? Allowing these packages to be installed without the user explicitly accepting them causes a license violation, which was one of the main reasons the games team started using this. How do accepted licenses get added, and to where? What happens when a package requires a license which isn't accepted?
... it happens lawsuits
While I haven't looked at Zac's changes with regards to defaulting to "*", I'm assuming that an unset ACCEPT_LICENSE is equivalent to "*". As far as portage goes, this was probably the best thing to do as setting a base set of licenses in the profiles (OSI-approved?) allows others to easily change it. With packages that require the license to be explicitly accepted, the current state is still not yet good enough. However, the debate over what licenses should be set as default is an argument that we shouldn't have final say on.
I'll be honest. I don't care what packages are accepted by default. I only care about retaining what is currently done to allow us to package some programs that we otherwise would not. Pretty much anything using check_license from eutils.eclass or any game with GAMES_CHECK_LICENSE="yes" in the ebuild *requires* the user accept the license. We're currently doing this via check_license. Should we continue with this, and will it ever be the case that this is no longer necessary, as portage will have support itself?
What exactly is required? check_license really should go in the long run, so what will enable that? Currently, portage supports (and defaults to) "*" but specifying anything else (in make.conf or profiles) will mask anything that requires a non-specified license. I'm not sure how much more can be done on portage's side. Even with dropping of "*", `echo ACCEPT_LICENSE=\"$(ls $PORTDIR/licenses)\" >> /etc/make.conf` is pretty much identical. There is one possibility.. If ACCEPT_LICENSE were to default to $(ls $PORTDIR/licenses) and the profiles were then to subtract anything that currently uses check_license, would that suffice? That would still leave the possibility of the profiles doing "-* <OSI-APPROVED>" if Gentoo wants to go that way...
(In reply to comment #63) > There is one possibility.. If ACCEPT_LICENSE were to default to $(ls > $PORTDIR/licenses) and the profiles were then to subtract anything that > currently uses check_license, would that suffice? That would still leave the > possibility of the profiles doing "-* <OSI-APPROVED>" if Gentoo wants to go > that way... To me it seems strange to have licenses inserted into ACCEPT_LICENSE automatically by the profile. I think we need a list of the restrictive licenses in the base profile so that they never get matched by * when we export ACCEPT_LICENSE into the ebuild environment.
(In reply to comment #64) > I think we need a list of the restrictive > licenses in the base profile so that they never get matched by * when we export > ACCEPT_LICENSE into the ebuild environment. Actually, if * is prevented from matching certain licenses, there's no need for the ebuild to explicitly check ACCEPT_LICENSE (or for it to be exported into the ebuild environment). As long a the package manager is not allowed to match such licenses with *, it will imply that the user has accepted the license in order to unmask the package. Anyway, this bug seems to be fixed according to it's original description, since the user is now able to mask any ebuilds for which they haven't explicitly accepted the license. The part about preventing restrictive licenses from being matched by * is really a separate feature. I suggest that we introduce a new incremental variable into the profiles, such as EXPLICIT_ACCEPT_LICENSE, which the package manager can use to identify licenses that need to be explicitly accepted.
(In reply to comment #65) > Anyway, this bug seems to be fixed according to it's original description, > since the user is now able to mask any ebuilds for which they haven't > explicitly accepted the license. if you take it this way, I will fork again my bug #112416 since the proposed solution does not solve mine. Do you really think we can play such game when talking about "legal problems" ? Legally, Gentoo should not provide any easy way to install any thing without making the admin READ AND ACKNOWLEDGE the license, INCLUDING GPL. This means, even the possibility to run echo ACCEPT_LICENSE=\"$(ls $PORTDIR/licenses)\" >> /etc/make.conf is un-acceptable to me, because it is an easy way not to read licenses, and thus is legally not acceptable, or in other words, does not satisfy me as author of bug #112416 > The part about preventing restrictive > licenses from being matched by * is really a separate feature. I suggest that > we introduce a new incremental variable into the profiles, such as > EXPLICIT_ACCEPT_LICENSE, which the package manager can use to identify licenses > that need to be explicitly accepted. If they are also to be easily put in a global system variable (in short, in /etc/whatever.conf), this still does not solve the problem. Any child able to read Gentoo-install-doc can also do echo EXPLICIT_ACCEPT_LICENSE=\"$(ls $PORTDIR/licenses)\" >> /etc/make.conf PS: I talk for myself, because I did not check whether all other bugs marked dup if this one are also un-satisfied by proposed fix, or not. Regarding the reason why licenses have been created, and how country laws consider them, I am concious there is no easy way to take care of them in Gentoo. Since the proposed solution should also work for pure crossinstalls (those who dont use Gentoo CDs at all), the fix should touch the internal core code or portage/emerge. The use of variables in conf files is (for me) obviously a very bad way to try to solve this, simply because it is *easy* to do ls /usr/share/licenses/ >> /etc/acked_licenses # or what ever and because this is too easy to be acceptable defense during a lawsuit, if there is lawsuit ... and every body know there will be within a few years. If Gentoo does not manage to comply law, governments will manage to technically prevent access to it (cf use of filtered IPv8 in China; French law should theoritically force internet providers to use and apply similar restriction; I wonder why it is not yet the case in USA).
Bug #152593 is for my feature request... As for comment #66, it's a bit asinine for force users/admins/etc to read and acknowledge licenses which do not apply to them. The GPL is a distribution license. It places no restrictions on use. In fact, most of the licenses are like that. We are not breaking any laws by not showing *those* licenses. The only licenses which we are required by law to display are the ones which I have been speaking of. At least, that is the case in the USA. I'm not sure where you're from, but any WIPO country works the same way.
I forgot to mention that I am a Gentoo Trustee and the Trustee that is responsible for ensuring that Gentoo complies with trademark, copyright, and other laws.
(In reply to comment #66) > Legally, Gentoo should not provide any easy way to install any thing without > making the admin READ AND ACKNOWLEDGE the license, INCLUDING GPL. This means, > even the possibility to run > echo ACCEPT_LICENSE=\"$(ls $PORTDIR/licenses)\" >> /etc/make.conf > is un-acceptable to me, because it is an easy way not to read licenses, and > thus is legally not acceptable, or in other words, does not satisfy me as > author of bug #112416 Sorry, but even if I'd agree with you there simply is no way to prevent people using stuff like this without resorting to closed-source code. If they don't want to bother with licenses we can try as hard as we want, in the end they always could simply disable the license check altogether in the code.
(In reply to comment #67) > Bug #152593 is for my feature request... > As for comment #66, it's a bit asinine for force users/admins/etc to read and > acknowledge licenses which do not apply to them. The GPL is a distribution > license. It places no restrictions on use. In fact, most of the licenses are > like that. We are not breaking any laws by not showing *those* licenses. The > only licenses which we are required by law to display are the ones which I have > been speaking of. At least, that is the case in the USA. I'm not sure where > you're from, but any WIPO country works the same way. Well put - I'd suggest that even use licenses are debatable in the USA, but due to the high cost of court battles they don't tend to get litigated all the way to the supreme court, so it is hard to say for sure. It isn't Gentoo's job to ensure that its users have taken an oath to uphold some company's business model. If a vendor wants to license redistribution of their software to Gentoo, then fine. If a vendor doesn't want to license redistribution (a la java) that is fine too. Gentoo doesn't have to give a 10 question quiz during emerge to see if the user has memorized the 40-page distribution license (especially if the user doesn't intend to distribute the software).
It seems that some people are opposed the idea of having a license group that encompasses all licenses (currently implemented as *). If this group is not allowed to exist, then we will certainly need support for some other groups in order for this feature to be viable.
Anybody that may be opposed to the * group (or whatever we choose to call a group that encompasses all licenses), please note that repoman needs a way to ignore licenses in it's visibility checks. Therefore, even if this group isn't exposed to users, it still needs to exist internally for the operation of repoman (unless someone thinks of another way).
(In reply to comment #72) > Anybody that may be opposed to the * group (or whatever we choose to call a > group that encompasses all licenses), please note that repoman needs a way to > ignore licenses in it's visibility checks. Therefore, even if this group isn't > exposed to users, it still needs to exist internally for the operation of > repoman (unless someone thinks of another way). Repoman should just bypass this filter completely which should be trivial to do on the API level.
ACCEPT_LICENSE support has been disabled in portage-2.1.2_pre3-r8 pending the implementation of license groups.
As a gentoo user, I'd like to make the following comments: 1) There are licenses which restrict use (e.g. for nonmilitary use, noncommercial, etc) 2) Linux is multiuser. Accepting licenses by the system administrator can determine which software is installed, but license violation also depends on the end user. One user can be complying with the license while another one is not (on the same machine with the same software/license). 3) Users do not emerge software, so annoying the sysadmin during an emerge wont make the users aware of the license terms (thats why openoffice shows the license in a per user basis). 4) It is possible that one piece of software have different licenses for different countries due to different legal systems. As root I would like that: 1) emerge be as noninteractive as possible 2) have a LICENSES="ACCEPTED_LICENSE -DENIED_LICENSE" in make.conf in a similar fashion as USE flags. 3) if LICENSES is unset, emerge failes and gives an error message like "as of portage-123 you must explicitly set LICENSES="something" in make.conf. See documentation in /somewhere" 4) each package can be given individual license control in /etc/portage/package.license, when more than one license is available. (similar to package.use). 5) a package could have the build process depend on the license. For instance, if I select one from two of the licenses given in a package, It would support feature X but not Y. (make use flags availability depend on licenses?) 6) have groups of licenses like "free", "non-free" and "contrib" in debian, and also a "all" or "*" to accept everything. 7) equery license some_package, shows me the license to read. As a final cosmetic/ergonomic note, ACCEPT_LICENSE makes me thing that there is a DENY_LICENSE. Also its not coherent with the remaining variables, e.g., FEATURES is not ADD_FEATURES.
(In reply to comment #75) I agree, and OOo is a very good example. Still, softwares like Java have a license that restricts download; Skype restricts installation. Both also restrict execution, but my point is that license HAVE to be considered by root at emerge stage. To go further, we may dream of Gentoo being able to install non-cost-free softwares. In some case, some Windows firewalls are cost free for private use; this is the cas also for Linux demo version of Xilinx and some other electronic softwares (forgot names). When gentoo will be able to store registration numbers, credit card number, and pay online licenses (lets dream), we will need to differenciate licenses that apply based on "parc", "machine", "user". Deprecated examples of famous non-cost-free Linux app: Winex, Lindows components. In an ideal world, I would dream of Gentoo being able to pay mensual registration for Winex, or user-based Xilinx support ... Conclusion: IMHO license should be considered BOTH at root-emerge and user level. My 2 cents. Hmmm... USD or euro cents ? ok, let's put 2 pennies :)
My feeling is that if a piece of software is non-free, it should be up to whoever wrote it to make it install correctly. If you want to help out the users of proprietary software, I think a better investment of time might be some tools that drop you into a chrooted shell where you can do an install, and then have the tool merge the resulting installed files into the main filesystem recording their locations so that the package can be uninstalled cleanly, and so that config files are still protected. This would also be very useful for users of free software which isn't packaged/ebuilded. If a company is making money from their software they ought to be able to figure out the right place to put all their files to be LSB-compliant.
(In reply to comment #75) > As a final cosmetic/ergonomic note, ACCEPT_LICENSE makes me thing that there is > a DENY_LICENSE. Also its not coherent with the remaining variables, e.g., > FEATURES is not ADD_FEATURES. ACCEPT_LICENSE works exactly like ACCEPT_KEYWORDS (which uses the same negation syntax as USE or FEATURES). (In reply to comment #76) > Conclusion: IMHO license should be considered BOTH at root-emerge and user > level. My 2 cents. Well, portage doesn't (and IMO never will) have any control over runtime, so no influence over what users do. Btw, the code for this is finished and will most likely be merged in portage-2.1.3, so not much point to argue about it anymore.
(In reply to comment #78) > ACCEPT_LICENSE works exactly like ACCEPT_KEYWORDS (which uses the same negation > syntax as USE or FEATURES). These variables have a default value inherited from first the profile selected, then make.default. Depending on the profile and make.default defaulting definition to "none" or "all", then the distribution can choose either a "shall add" or "shall neg" policy. "shall neg" just requires that somewhere in the profile, there is a place where every single supported license will be listed so that "all" makes sense. I dont think that would be difficult. => we have a choice between 2 policies. > (In reply to comment #76) > Well, portage doesn't (and IMO never will) have any control over runtime, so no > influence over what users do. Portage does not, thats right. But, we are having distribution discussion. I mean, Gentoo is not LFS. For me, distribution is a bunch of tools+default settings+ tweaking pocibilities. Further more, Gento inherits UNIX philosophy. And there is a tool that I have always consuidered under-used: /etc/groups+sudoers. a solution for runtime would be to: chown root:my_license /usr/bin/my_app chmod 774 /usr/bin/my_app during installation. This can be technically be performed when the app tree is merged to / : every file that have execution flag shall get this flag removed for all, and group shall be changed to a group specific for each license, like gpl_licensed bsd_licensed etc ... then, when a user accepts a license, it shall be added to corresponding group. Problem in actual conception of Linux is that an end_user can not be added to /etc/group without root ID. I think Gentoo team could develop a new tool to do that. A new (binary) program that would be executed with root SUID, and allow any user to add or remove himself from a group. To avoid side effect, the operation could be restricted to a given list of group (either groups with a name starting or ending with "license", or a list of groups specified in /etc/group_allowed_license_for_self_user_licensing. I really think the group concept in UNIX could help on this problem. > Btw, the code for this is finished and will most likely be merged in > portage-2.1.3, so not much point to argue about it anymore. Whatever have been done can be unused or undone. Refusing further discussion would mean one consider Portage so much perfect it does not need any further improovement. Even if done the right way, there may be missing features. I mean, discussion MUST stay open. New problems will appear. That's why BTS exist. Nothing is never perfect. Severity is just likely to get lower priority, and kind of query become an "improovement querry". Because in regard to laws, an unsuffisant effort is often better that no effort at all. You say that release is coming soon, and Gentoo is thus likely to be the second distribution after Knoppix to really take care of licensing of third part softwares ( as Miguel Barao mentionned ). Never heard of similar discussion in other famous dists.
(In reply to comment #79) [skipped lots of irrelevant stuff] This bug is about a specific technical portage feature (license based visibility filtering). If you want to start a philosophical debate or propose runtime solutions (which haven't anything to do with what this bug is about) please use one of the mailing lists.
*** Bug 169668 has been marked as a duplicate of this bug. ***
the patch doesn't work with a recent portage: [ebuild R ] sys-apps/portage-2.1.3.9 USE="(selinux) -build -doc -epydoc" LINGUAS="-pl" 377 kB # patch <~/Desktop/ebuilds/accept_license.patch can't find file to patch at input line 3 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |--- pym.orig/portage.py 2006-10-22 14:03:10.000000000 +0000 |+++ pym/portage.py 2006-10-22 19:20:25.000000000 +0000 -------------------------- File to patch: ./pym/portage.py patching file ./pym/portage.py Hunk #1 FAILED at 916. Hunk #2 succeeded at 1355 (offset 171 lines). Hunk #3 succeeded at 1413 (offset 176 lines). Hunk #4 succeeded at 1544 (offset 204 lines). Hunk #5 FAILED at 1729. Hunk #6 FAILED at 1746. Hunk #7 FAILED at 1758. Hunk #8 FAILED at 1770. Hunk #9 succeeded at 4470 with fuzz 2 (offset 1014 lines). Hunk #10 succeeded at 4489 (offset 1012 lines). Hunk #11 FAILED at 4604. Hunk #12 succeeded at 4720 with fuzz 2 (offset 1070 lines). Hunk #13 FAILED at 4741. Hunk #14 FAILED at 4962. Hunk #15 succeeded at 5043 with fuzz 1 (offset 1116 lines). Hunk #16 FAILED at 6510. Hunk #17 succeeded at 6693 with fuzz 2 (offset 1252 lines). 9 out of 17 hunks FAILED -- saving rejects to file ./pym/portage.py.rej port4 portage # ACCEPT_LICENSE="-*" emerge -av portage These are the packages that would be merged, in order: Calculating dependencies / !!! Problem in 'sys-apps/portage' dependencies. !!! local variable 'license' referenced before assignment exceptions Traceback (most recent call last): File "/usr/bin/emerge", line 6474, in ? retval = emerge_main() File "/usr/bin/emerge", line 6468, in emerge_main myopts, myaction, myfiles, spinner) File "/usr/bin/emerge", line 5772, in action_build retval, favorites = mydepgraph.select_files(myfiles) File "/usr/bin/emerge", line 1660, in select_files self.mysd = self.select_dep(myroot, myatom, arg=myarg) File "/usr/bin/emerge", line 1820, in select_dep myeb_matches = portdb.xmatch("match-visible", x) File "/usr/lib/portage/pym/portage.py", line 6523, in xmatch self.xmatch("list-visible", mykey, mydep=mykey, mykey=mykey)) File "/usr/lib/portage/pym/portage.py", line 6508, in xmatch myval=self.gvisible(self.visible(self.cp_list(mykey))) File "/usr/lib/portage/pym/portage.py", line 6674, in gvisible if "?" in license: UnboundLocalError: local variable 'license' referenced before assignment
(In reply to comment #82) > the patch doesn't work with a recent portage: If you want to try a checkout of trunk, there are instructions here: http://www.gentoo.org/proj/en/portage/doc/testing.xml
*** Bug 204740 has been marked as a duplicate of this bug. ***
This is supposed to be fixed in portage-2.2_pre5 or earlier.
