AMD has released version 3.0.1 of its libm replacement. I took the liberty to modify the current ebuild: 1. a proper env.d file is created and thus, the library is found by the linker 2. the one and only header file is linked into /usr/include for convenience 3. no more linking to /opt/lib or /opt/include 3. ReleaseNotes was renamed to ReleaseNotes.txt 4. the user no longer gets a complete download link he can c&p to wget because I think this is legally questionable as AMD has a quite restrictive license wrt redistribution and put the library behind a registration wall Hope everything else is fine and dandy. :) Reproducible: Always
Created attachment 303203 [details] updated ebuild I forgot to mention one more thing: The AMD license file in portage is not the same that is shipped with the libm package. How should this be handled? I think it is important for the user to know what he can and cannot do with this.
Created attachment 303219 [details, diff] diff against 2.1 ebuild How about pkgconfig file instead of symlinks?
(In reply to comment #0) > 4. the user no longer gets a complete download link he can c&p to wget because > I think this is legally questionable as AMD has a quite restrictive license wrt > redistribution and put the library behind a registration wall It's between user and AMD to sign EULA. We don't download it, don't mirror it, don't redistribute. Nothing forbids us to have valid SRC_URI.
Created attachment 303295 [details] pkg-config file
Created attachment 303297 [details] ebuild v2 - installs pkg-config file - no longer links header to /usr/include
(In reply to comment #3) > It's between user and AMD to sign EULA. We don't download it, don't mirror it, > don't redistribute. Nothing forbids us to have valid SRC_URI. Hm, I mostly I agree but providing a link for a direct download that circumvents AMD's registration wall (and thus accepting the license agreement during registration) is questionable at best. I strongly believe this should not be in the ebuild, honestly.
Added trustees@g.o to distribution. Two things:- AMD set up their site the way they did for a reason. The reason doesn't matter and we should respect it. We should not help users bypass the EULA. The AMD site is broken by design. Many sites provide a 'one time' link to enable the payload to be fetched after the EULA is agreed. We still should not help users to bypass a broken site. This is my personal view - not the collective view of the trustees.
My feeling is that SRC_URI is just factual information. Whether EULAs are legally binding in any particular jurisdiction is a matter between the user of software, the owner of software, and the local government. I don't really see Gentoo as being a party to any of this as long as we do not redistribute anything. Now, if a SRC_URI pointed to somebody who did not have legal permission to redistribute a file, that could be legally problematic based on some recent court decisions. That doesn't seem to apply here, since AMD is the one distributing the file, and they claim at least to have the rights to do so. From what I've read I believe that deep linking is not in itself illegal in the US. Most legal arguments around it involve side-issues, like sites that confuse ownership/etc of information. Anybody who installs an overlay on Gentoo, takes the time to read an ebuild and find a SRC_URI, and directly downloads the file is not likely to misinterpret where the URL is going. That said, what are the chances that users will even see the SRC_URI anyway? When I go to emerge a fetch-restricted package I tend to just follow the instructions output by emerge, not go digging into ebuilds to see if something inside might offer some other way to obtain the file... As with Roy this is my personal view.
*** Bug 405913 has been marked as a duplicate of this bug. ***
Why is this package even fetch-restricted? The license file included with the tarball says: | a. Subject to the terms and conditions of this Agreement, AMD grants | Licensee the following non-exclusive, non-transferable, royalty-free, | limited copyright license to download, copy, use, distribute and sublicense | the foregoing rights through multiple tiers of sublicenses the object code | version of the Software and materials associated with this Agreement, | including without limitation printed documentation, (collectively, | "Materials"), provided that Licensee agrees to include all copyright | legends and other legal notices that may appear in the Materials. BTW, this is not what we have as "AMD" license in the tree.
Ok, I've reviewed the matter in both my role as licenses & trustee. Clarifications on the license: 1. The license explicitly permits redistribution. 2. The license ALSO contains a restriction on export outside of the US in clause #11. To ensure that the burden of export proof remains on the original vendor, we must ensure: 1. This is never placed on Gentoo mirrors. 2. The user only downloads via the main AMD page, with verifies the user's country. This means no easy SRC_URI. To comply with the license: 1. We MUST include the license in the Portage tree. Somebody please use the text version from the download page.
(In reply to comment #11) > 2. The license ALSO contains a restriction on export outside of the US in > clause #11. To be clear the license says that the software MAY be restricted with regard to exports outside of the US. This is true of all software everywhere. It is also true that reading the license MAY cause cancer. > > To ensure that the burden of export proof remains on the original vendor, we > must ensure: I guess my only concern is when do we need to ensure that the burden of export proof remains on the original vendor? All software packages in portage have to comply with US law in this regard - not just ones where the vendor mentions it. I don't see how the vendor mentioning that export restrictions may apply in the license has any bearing on whether we can redistribute this. Now, a determination that the law does apply certainly does, and if the vendor stated that they've been contacted by a government agency and told that export restrictions DO apply then that should also impact our decision. Looking at the ITAR list, it tends to point to stuff like cryptography software, modeling software specifically designed for weapons purposes, and in general software designed specifically for use in particular controlled applications. I didn't really see anything that applies to numerical analysis software in general. The CCL doesn't seem to have anything either. Stanford has a decision tree that I thought was useful at: http://export.stanford.edu/tree/index.html I can't say I have strong confidence that this software ISN'T export-controlled, but I could say the same of Chrome. Is there anything specific that points to this software being export-controlled? > To comply with the license: > 1. We MUST include the license in the Portage tree. Somebody please use the > text version from the download page. Certainly agree 100% with this.
@trustees thanks for your help on this commit 1cc8e366e091eb2e2443b2336cf41ecb4b4951f3 Author: Kacper Kowalik (Xarthisius) <xarthisius.kk@gmail.com> Date: Mon Mar 19 14:41:18 2012 +0100 [sci-libs/amdlibm] remove SRC_URI wrt #405803, add valid 'amdlibm' license (copied to txt from pdf) applies all remarks from c#11 @Matthias since we've got all figured out, I'll bump it shortly
(In reply to comment #11) > Clarifications on the license: > 1. The license explicitly permits redistribution. > 2. The license ALSO contains a restriction on export outside of the US in > clause #11. Does it qualify for the BINARY-REDISTRIBUTABLE license group? Looks like the criteria listed in the license_groups file are fulfilled.
commit db59bc2efa82eeab021fa4ef571f45d21aca978e Author: Kacper Kowalik (Xarthisius) <xarthisius@gentoo.org> Date: Thu Mar 22 22:18:53 2012 +0100 [sci-libs/amdlibm] version bump wrt #405803 by Matthias Dahl <ua_gentoo_bugzilla@binary-island.eu>