Duncan wrote: I believe that's the way it is now, yes. Thus what we're proposing would simply keep the legacy meaning for world (and system) as they are, while @world (and @system) would refer to the specific sets. Now that it has been suggested, I do believe that's the simplest way to handle it, since it would involve no change at all for the existing words. One could avoid the confusion about world != @world completely, if one would simply rename @world into e.g. @worldfile Then one could define without any ambiguity world = @world = @worldfile + @system (and of course, one should then let @system not be a @worldfile candidate, at least by default). I am aware that currently @world is already implemented, but only in testing portage and probably not too many user scripts have been converted to this already (resp. _if_ they have been converted, they have most probably been converted from world to @world @system which would not harm either).
IANAL, and I'm sure most of us aren't either, but I would appreciate some opinions on Bug https://bugs.gentoo.org/234542 and whether the binary patch proposed there conflicts with section 2.5.1 of the license agreement from Adobe: http://www.adobe.com/products/eulas/pdfs/Reader_Player_WWEULA-Combined-20060724_1430.pdf Specifically, here is the passage I'm wondering about: 2.5.1 You may not modify, adapt, translate or create derivative works based upon the Software. You may not reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software except to the extent you may be expressly permitted to decompile under applicable law, it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. I *think* I would be okay using this binary patch since: 1) This is specifically to make it operable with libcurl.so.4 2) I have (and others have) asked Adobe to recompile it with support for libcurl.so.4 instead of libcurl.so.3, but they have not done so (or responded to any of these requests, as far as I am aware). Anyone care to weigh in, lawyer or not? -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature
On Wed, 20 Aug 2008 15:10:18 -0400 Jim Ramsay [EMAIL PROTECTED] wrote: IANAL, but the following line is critical: it is essential to do so in order to achieve operability of the Software with another software program, and you have first requested Adobe to provide the information necessary to achieve such operability and Adobe has not made such information available. Given the situation as you outline it, I think the sub-section above expressly permits the binary patch. The request has been made, Adobe have not co-operated, that clause has been invoked... At least, that's how I would read it. Rob. signature.asc Description: PGP signature
Jim Ramsay wrote: 2.5.1 You may not modify, adapt, translate or create derivative works based upon the Software. You may not reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software... Anyone care to weigh in, lawyer or not? Obviously I'm not a lawyer but I don't see an issue here. I don't see that Gentoo or its developers are in any way a party to this agreement. This is an agreement between Adobe and those who distribute its software. Some argue that EULAs also apply to those who use software (which is debatable), but Gentoo does not use this software either (to my knowledge). Gentoo distributes ebuilds - which are not the property of Adobe and are not derivative works of any of Adobe's software. A user who executes an ebuild might obtain a copy of an Adobe product that Adobe distributes. A user who executes an ebuild might create a derivative work of an Adobe product, and users who use proprietary software are advised to consult with lawyers as appropriate if they are concerned about the terms of license agreements that they may or may not be parties to. To me this is kind of like RiffTrax or similar along-side products that allow users to improve the experience of using a copyrighted work, but which are not themselves derivatives of copyrighted works. If a user using one of these products happens to create a derivative work that is a matter between them and the copyright owner. If such work is occurring without further distribution in an end-user context it is likely to be considered fair use. Gentoo doesn't distribute software (well, except to the degree that we mirror it). Gentoo makes it easier for users to use software that others distribute. As a result, Gentoo stays fairly clear of copyright law, and we do make a good-faith effort to not mirror content which we are not licensed to redistribute. That is my personal take on things like this, but again, I'm not a lawyer and others might not agree (makes no difference to me one way or another if you don't). :)
Richard Freeman [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 20 Aug 2008 21:07:08 -0400: Gentoo doesn't distribute software (well, except to the degree that we mirror it). It probably doesn't apply in this particular case, but note that Gentoo DOES distribute software in binary form on the LiveCDs, and prepackaged on the package-CDs as well. That definitely applies to GPLed works, for instance, and there's a discussion in the archive where it was pointed out that at the time, Gentoo wasn't in compliance, because we weren't ensuring our sources were available for three years, thus missing on the offer-to-provide, good-for-three-years, clause, AND we weren't always satisfying the make-sources-available-at-the-time-of-distribution alternative clause either. (In that, at the time, for conference distribution and the like, we often made available LiveCDs, without corresponding directly available at the time of distribution, copies of the sources used to create them, not just patches, but the complete sources.) This came up because it had been applied to Knoppix and etc and had forced them to change their ways, and Gentoo was interested in correcting the problem before it likewise became a legal one for us. Again, note that the license specifies all sources and scripts necessary to build, etc, NOT just distribution applied patches, which is what many were doing and what was catching them off guard. There was also some discussion of removing some of the outdated LiveCDs etc from distribution, so the three- year-clock could start ticking, since until distribution has ceased it is being continuously reset. Presumably that has been corrected now, and releng is properly archiving all sources used in the creation of the LiveCDs, etc, for three years after they've ceased distribution. The alternative, as mentioned, would be to ensure that sources are always made available at the time of distribution, including at conferences and the like. In either case, presumably we've stopped distributing historic LiveCDs and etc for which this was not done, so at least the 3-year clock is ticking, even if we can't easily go back and get the required sources should anyone call us on the 3-year thing before it expires. -- 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