Re: [gentoo-dev] Re: Documentation licenses and license_groups
On 01/05/2010 01:07 PM, Duncan wrote: Periodically there's talk of adding + versions of at least the FSF licenses, but while it would probably be quite a good thing, it'd be a LOT of VERY boring work poring thru all those packages and either updating to the + version, or leaving comments in each one saying they'd been checked already. I think that this should at least be added. If some things are more conservatively labeled as v2 when it should be v2+ it doesn't cause all that much harm. Over time the licenses would get updated, and then we'd have more useful metadata. The whole concept of GPL-compatible doesn't work when GPL2 isn't compatible with GPL3, and vice-versa, and all the way back to 1. At best we can have GPL3-compatible or GPL2-compatible or whatever. What happens when GPL4 comes out and we need to edit the group again? What will that break?
Re: [gentoo-dev] Non-free software in Gentoo
On Tue, Jan 05, 2010 at 11:55:49PM -0500, Vincent Launchbury wrote: Greg KH wrote: And note, _I_ placed those images in the kernel image, after consulting lawyers about this issue, so it's not like I don't know what I am talking about here. I'm not questioning whether it's legal to distribute non-free firmware alongside the GPL. I'm merely saying that the firmware _is_ non-free, which should be reflected by the ebuild licenses. So you are saying that the license for the kernel should show the license for all of the different firmware files as well? That would get pretty unusable, and keep the kernel from being able to be installed on anyone's machine that didn't want such licenses, right? Also note that the license of the firmware files do not matter to almost everyone using the kernel, as almost no one uses those files anymore, the ones in the linux-firmware package should be used instead. So as we are a source-based distro, if you object to those firmware licenses, just don't build them in your kernel builds. But to expect to list all of them as the license for the whole kernel package, that's not a workable solution as far as I can see. So it's a pointless effort. To you maybe, but it's important to some. Note that updating the licenses would only affect those with strict ACCEPT_LICENSE settings anyway. I don't understand why you'd oppose the change. So you want anyone with such strict settings to not be able to install the kernel package at all? If so, what kernel do you want them to be able to use? :) thanks, greg k-h
Re: [gentoo-dev] Non-free software in Gentoo
On Wed, Jan 06, 2010 at 10:57:01AM -0800, Greg KH wrote: On Tue, Jan 05, 2010 at 11:55:49PM -0500, Vincent Launchbury wrote: Greg KH wrote: And note, _I_ placed those images in the kernel image, after consulting lawyers about this issue, so it's not like I don't know what I am talking about here. I'm not questioning whether it's legal to distribute non-free firmware alongside the GPL. I'm merely saying that the firmware _is_ non-free, which should be reflected by the ebuild licenses. So you are saying that the license for the kernel should show the license for all of the different firmware files as well? If all the different firmware files get installed, then yes. That would get pretty unusable, and keep the kernel from being able to be installed on anyone's machine that didn't want such licenses, right? Also note that the license of the firmware files do not matter to almost everyone using the kernel, as almost no one uses those files anymore, the ones in the linux-firmware package should be used instead. Right, which is why at the same time it would be useful to have an option to not install those files. There's no problem with USE conditionals in LICENSE; LICENSE=GPL-2 firmware? ( freedist ) or expanded further would be fine, and simply nuke those files on install with USE=-firmware. So as we are a source-based distro, if you object to those firmware licenses, just don't build them in your kernel builds. But to expect to list all of them as the license for the whole kernel package, that's not a workable solution as far as I can see. The kernel sources are unusual in that they install the sources, and the user is responsible for configuration and compilation. For anything built from an ebuild, the license of unused parts of the source code shouldn't matter, but here all of the source files of the kernel get installed. So it's a pointless effort. To you maybe, but it's important to some. Note that updating the licenses would only affect those with strict ACCEPT_LICENSE settings anyway. I don't understand why you'd oppose the change. So you want anyone with such strict settings to not be able to install the kernel package at all? If so, what kernel do you want them to be able to use? :) The GPL-2 licensed parts of all the kernel packages -- so probably everything that matters -- could be installed with ACCEPT_LICENSE=GPL-2 with my above suggestion.
[gentoo-dev] Re: Documentation licenses and license_groups
Richard Freeman posted on Wed, 06 Jan 2010 11:05:52 -0500 as excerpted: I think that this should at least be added. If some things are more conservatively labeled as v2 when it should be v2+ it doesn't cause all that much harm. Over time the licenses would get updated, and then we'd have more useful metadata. I agree. The problem has been finding someone who cares enough about it to push it thru the process. Keep in mind that until recently, it wasn't really practical to do anything (automated, at least) with the license metadata anyway, so whether we had the xxx+ license specifiers or not wasn't of any real practical use anyway. Now that license sets are reasonably working, the plus licenses would actually have a practical application. So my guess is that in practice, mostly the same people (plus/minus) who cared enough to pushed license sets thru from a proposal to working practicality, will probably be the ones that, now that /that/ works, will /eventually/ push plus licenses into the mix, for much the same reason. BTW, if there's a dev (or group) willing to lead such a thing, put my name on the list as a user willing to put some time into doing the leg (aka internet) work on it. I don't know how much, but I'm certainly interested enough to want to follow developments, and will try to do some of the leg work, as I can, for the interested devs to look over and commit. Gentoo's way of course is to use bugzilla, with a tracker bug. I guess that's my permission to CC me. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] QA last rites for dev-java/jrockit-jdk-bin
# Diego E. Pettenò flamee...@gentoo.org (07 Jan 2010) # on behalf of QA team # # Fails to fetch, bug #228929, open June 2008, still not # fixed. # # Removal on 2010-03-08 dev-java/jrockit-jdk-bin
