Re: [gentoo-dev] License for Google Chrome
On Fri, Aug 26, 2011 at 6:51 PM, Mike Gilbert flop...@gentoo.org wrote: Perhaps I used the wrong term here. I mean that 2.2 (B) allows the user to download and install the software without having to explicitly click the Agree button on the software download page. I did not review the Chrome license, but speaking generally: 1. RESTRICT=mirror must be used if anything in the license prevents free redistribution. I'd suggest that if the license isn't OSDL approved give it a VERY close look. Simply mirroring a file is a violation of copyright law, and so Gentoo MUST accept license terms to do it. 2. RESTRICT=fetch generally is only needed if there is no reliable way to fetch a file (such as if upstream doesn't provide a stable URL, sticks the file behind an interactive website, etc). Gentoo does not need to accept a license to allow users to fetch a file directly, so the EULA/license in itself doesn't necessarily force us to use RESTRICT=fetch. Most of the time this is a moot point, as upstreams that are concerned with forcing people to accept EULAs tend to not provide stable URLs. If upstream raised a stink over using a stable URL we would probably give serious thought to blocking fetches - in theory not doing so is legal, but many people have been successfully sued for providing links, or for deep-linking. Rich
Re: [gentoo-dev] License for Google Chrome
On 2011.08.26 23:06, Mike Gilbert wrote: I have been maintaining an ebuild for Google Chrome in an overlay. It basically extracts a deb file to /opt. This serves as an easy alternative for people who do not have the patience to compile Chromium. Now that I have developer access, I would like to move this to the tree. Before doing so, I need some advice on how to deal with the EULA[1]. I think clause 2.2 (B) allows me to avoid a fetch restriction. I think clause 5.3 prohibits mirroring. Do I need to worry about anything else here? [1] http://www.google.com/chrome/intl/en/eula_text.html Mike, You will need to add the licence to the tree as its a EULA. The package will need to be masked by the licence. If Google provide a click through licence agreement, complying with clause 2 is out of our hands. If not, licence masking should ensure that users read the licence before they install and subsequently use the package. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods trustees pgppbhFEDuhtW.pgp Description: PGP signature
[gentoo-dev] Re: License for Google Chrome
Il giorno sab, 27/08/2011 alle 08.23 -0400, Rich Freeman ha scritto: Gentoo does not need to accept a license to allow users to fetch a file directly, so the EULA/license in itself doesn't necessarily force us to use RESTRICT=fetch. Let me try to use this point to remind that unclear patent status is generally not a good reason to RESTRICT=fetch.. maybe RESTRICT=mirror, but definitely not fetch. Otherwise probably half the tree wouldn't be fetchable in US... -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] License for Google Chrome
On 8/26/11 9:32 PM, Mike Gilbert wrote: To clarify: Chrome is a pre-built, officially branded version of the open-source Chromium project. It also includes a few proprietary components, like a PDF reader plugin from Adobe. To be precise, the PDF reader in Chrome is not Adobe's, but Google's own. But the Flash player shipped with Chrome is Adobe's. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [sys-boot/grub] Grub2 series prepared for testing
Tomáš Chvátal posted on Sun, 28 Aug 2011 13:28:26 +0200 as excerpted: I updated the grub2 ebuilds in main tree and took maintainership of grub2. Thanks. I've been wondering about trying grub2, but have some questions. What is needed to compile it? Specifically, my main machine is ~amd64 no-multilib and runs grub-static for grub1 (0.97-r10) Should 64-bit gcc without multilib be able to compile grub2, or is 32-bit gcc needed? If 32-bit is needed, I should be able to build it in my 32-bit netbook build-image chroot, but obviously I don't want it trying to do anything funny like trying to load into boot records, from there. The grub-static-0.97-rX tarball is simply a binpkged grub-0.97-rX built and binpkged on a 32-bit machine, with an ebuild that extracts and installs the binaries from the binpkg. Could the same technique be used for grub-static-2? Slotted is good, as on my main machine I run a quad-disk md/RAID set, normally all four in RAID-1, but for /boot, only two in RAID-1, with a second RAID-1 for the other two, with the idea of experimenting with grub-2 there and selecting which to boot from the BIOS. BTW, does grub- static slot nicely with it as well? Of course, for this to work, I'll presumably have to install the binpkg built in the 32-bit chroot slotted with grub-static on my main machine, then manually install to the second /boot after mounting it, and manually install to those disks boot records. grub2 supports gpt I'm told. I'm 100% gpt on both systems (main and netbook) and my bootable thumbdrives as well, all using grub-static at this point, but both systems are still conventional BIOS. All bootable drives have both a legacy BIOS boot partition (1024 KB) and an EFI system reserved partition (127 MB, thus 128 MB for the two of them combined), both empty/reserved at this point, in addition to the normal md/RAID-1 /boot partition. Again, they're all GPT but BIOS booting. Where's the optimal place to install grub2 in this setup and how do I tell it to do so, and/or tell the ebuild to not try to install to any boot records when I'm simply building/installing it in the 32-bit netbook build-image chroot? Some of this might be in your devspace docs already, but I doubt it all is. I could probably help with them as the answers are worked out. I'm still posting this to the (devel, not announce) list as I imagine others will find your answers at global level useful as well and getting some discussion into the public list archives is likely to be useful, given the dearth of info I've seen on grub2 in Gentoo so far. However, taking it to bugs or to private mail will probably be better at some point. -- 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
Re: [gentoo-dev] License for Google Chrome
On Sat, Aug 27, 2011 at 8:27 AM, Roy Bamford neddyseag...@gentoo.org wrote: On 2011.08.26 23:06, Mike Gilbert wrote: I have been maintaining an ebuild for Google Chrome in an overlay. It basically extracts a deb file to /opt. This serves as an easy alternative for people who do not have the patience to compile Chromium. Now that I have developer access, I would like to move this to the tree. Before doing so, I need some advice on how to deal with the EULA[1]. I think clause 2.2 (B) allows me to avoid a fetch restriction. I think clause 5.3 prohibits mirroring. Do I need to worry about anything else here? [1] http://www.google.com/chrome/intl/en/eula_text.html Mike, You will need to add the licence to the tree as its a EULA. The package will need to be masked by the licence. If Google provide a click through licence agreement, complying with clause 2 is out of our hands. If not, licence masking should ensure that users read the licence before they install and subsequently use the package. Thanks for the info from everyone. I have added the license to the tree and EULA group and will add the ebuild with RESTRICT=mirror later this weekend.
[gentoo-dev] Xen completely busted in the stable tree
Hey guys, I think app-emulation/xen-tools are completely broken in stable tree, especially see bugs like https://bugs.gentoo.org/show_bug.cgi?id=376819 and https://bugs.gentoo.org/show_bug.cgi?id=379815 I noticed some activity and work being done on those packages, but only in ~arch. If someone can pick good stabilization targets and get fixes into the stable tree, that'd be great. signature.asc Description: OpenPGP digital signature
