Chris Gianelloni <firstname.lastname@example.org> posted
1152131291.21775.77.camel@..., 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,
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
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
email@example.com mailing list