Heads up, slight tree path change

Douglas McClendon dmc.fedora at filteredperception.org
Thu Aug 30 02:26:11 UTC 2007


Jesse Keating wrote:
> On Wed, 29 Aug 2007 19:51:55 -0500
> Douglas McClendon <dmc.fedora at filteredperception.org> wrote:
> 
>> - to include the fedora-release rpm (not fedora-logos) in a
>> derivative distribution?
> 
> The naming of it is probably suspect.  With Test2, fedora-release will
> grow a Provides: system-release so that things can switch over to
> requiring that instead of either 'fedora' release or 'redhat' release.
> This means you can do a drop-in replacement named whatever, so long as
> it also provides system-release.

Sounds good.

> 
>> If not, what I am more specifically interested in, is the fedora rpm
>> gpg key, and the yum configurations that point at fedora servers.
> 
> That's fine, you'd probably also want to add in your key and repo
> definitions for what makes you different than Fedora.

Of course.

>> In some sense, this facilitates derivative distributions 'leeching' 
>> resources from fedora.  But it seems like this is currently allowed,
>> and given the moves to encourage derivative distros, I suspect fedora
>> does not have a problem with this.
>>
>> Then the final question of course would be, since derivative distros
>> of this nature are using binaries actually built by fedora, will
>> fedora be willing to go the extra mile and offer written assurance to
>> keep the source rpms available for 3 years, or whatever the whole
>> fallout from the gpl-derivative-distro thread of recent history was.
>>
>> I mean, it seems plain silly to force derivative distros, that are
>> using binaries compiled and provided by fedora, to maintain a mirror
>> of the source rpms.  Especially if as above, the yum configs in the
>> derivative distros are pointing at fedora servers anyway.
> 
> 3 years is a long time to make such a promise, especially considering
> that you may pick up updates and not the release bits.  Our updates
> definitely don't sit for 3 years, they're only around until they're
> replaced by a later update.  To keep each and every update around for 3
> years is a /lot/ of data.

The 3 years is a number that gets referenced to _a lot_ in this highly 
relevent discussion-

http://linux.slashdot.org/article.pl?sid=06/06/27/217235

I suggest that if fedora wants to encourage derivative distributions, 
that a wiki/faq gets put up, which very specifically addresses the 
issues discussed in the above slashdot thread.

> 
> It's just easier if you're going to go the step of publicly
> distributing a derivative to host the srpms you ship with your
> binaries, or near your binaries.  That way when you're done with the
> binaries and no longer wish to distribute them, you can bring
> them /and/ the source down, as you won't be obligated to keep the
> source around for any other amount of time.

I wasn't really concerned with the issue of source matching binaries on 
a fedora derivative that _differ_ from the binaries that are in fedora 
proper.  That will no doubt only represent a very small fraction of the 
derivative distribution.  What I am worried about is whether there is 
any legal requirement for the deriver, to host the same sources that 
fedora is already hosting.  I believe that somewhere in the thread 
above, is the suggestion that a derivative distro, if not wanting to be 
obliged to host *all* the source rpms, must get some sort of explicit 
written promise from the upstream distro, that the upstream distro will 
host the source rpms for X amount of time (where X==3years?).

The whole reason the slashdot thread was interesting, is because it is 
rather strange to begin with, since one would assume that the upstream 
provider already has the legal obligation.  I suspect the issue was to 
prevent a scenario where an upstream provider goes belly-up/disappears, 
and then the downstream deriver that didn't bother to mirror a copy, 
cannot legally satisfy their own obligations under the GPL.

IANAL, so I may be completely butchering the issue.

-dmc




More information about the devel mailing list