Chris Gianelloni <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Wed, 05 Jul 2006 16:28:10 -0400:
> On Wed, 2006-07-05 at 08:51 -0700, Brian Harring wrote: >> Every few months is a rough rate going by memory at 8:30am. Not huge, >> but as said, if need to provide access to gpl'd sources for bin (not >> just releng cds btw, people are forgetting we have precompiled pkgs in >> the tree also), it _is_ a potential route for handling that requirement >> while killing off another bit of manual work. > > How many of those -bin packages are GPL? I'm sure there's a few, but I > can't think of a single one. > > Also, we don't have pre-compiled packages in the tree. We have ebuilds > that pull down pre-compiled packages. That's easily fixable with a > RESTRICT=mirror for the few that are GPL and binary. > > ...and then I decided to actually look at the one package that I thought > about, and it's mplayer-bin, though we do provide those sources, since it > is just the mplayer ebuild compiled, and we have the sources for the > source-based ebuild already. The thing is, for precompiled tree stuff, if it's GPL, we already have sources, and the sources version and bin version should come and go from the tree more or less together. As long as it's "more" (or should I say "most" =8^) , having them both in the tree together pretty much directly satisfies condition 3a -- which doesn't require holding onto them for three years after the binary ceases to be distributed, unlike 3b, on-request. BTW, that's the potential down side to the CD/DVD of sources on request idea, too. That means sources must be available for three years /after/ the binaries are no longer distributed. If sources are made available with the binaries, they can cease to be made available with them. If sources are only available on request, they must be made available on request for three years. Do we want that three-year obligation and is it worth that to make it on-request vs having them available at the same time? I don't know, but it needs to be considered. An example tree package would be grub-static. A number of the emul-linux-x86-* packages are also GPL, including at least baselibs, qtlibs, compat, sdl. Also, the amd64 project distributed was it binary gcc or glibc or both at least for some of their historic profile changes, to help with the multilib conversion. Now, being historic those may be a lost cause, but something similar may happen in the future. glibc is lgpl not gpl but does the lgpl have similar conditions. In any event, gcc does as it's dual licensed, but according to the ebuilds we are distributing it under both licenses, so the gpl conditions would apply. Whether other dual bitness archs have done similar or whether this applies to only amd64, I don't know. -- 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@gentoo.org mailing list
