3:28 p.m.
As part of a continuing effort to make derivative distributions of
Fedora easier, we're making the path names within the tree a bit more
generic. Instead of os/Fedora/<packages> the path will now be
os/Packages/<packages>. This may cause you some shuffle or churn when
syncing, and I apologize for the late notice. We've been having a heck
of a time getting a rawhide to compose and I hadn't taken the time to
send a mail about this.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
3:36 p.m.
So it used to be Fedora/RPMS/ but then just Fedora/ was better, and now
Fedora/Packages/ is better still? Really? How "Packages/" "more
generic"
than ""? What's the point?
3:43 p.m.
On Wed, 29 Aug 2007, Roland McGrath wrote:
So it used to be Fedora/RPMS/ but then just Fedora/ was better, and
now
Fedora/Packages/ is better still? Really? How "Packages/" "more
generic"
than ""? What's the point?
Err, it's Fedora/RPMS/ -> Fedora/ -> Packages/, not Fedora/RPMS/ ->
Fedora/ -> Fedora/Packages/ .
Jima
5:20 p.m.
On Wed, 2007-08-29 at 16:28 -0400, Jesse Keating wrote:
As part of a continuing effort to make derivative distributions of
Fedora easier, we're making the path names within the tree a bit more
generic. Instead of os/Fedora/<packages> the path will now be
os/Packages/<packages>. This may cause you some shuffle or churn when
syncing, and I apologize for the late notice. We've been having a heck
of a time getting a rawhide to compose and I hadn't taken the time to
send a mail about this.
Why not os/RPMS/<the rpms here>? That is what they are :P
And when is this move planning on taking place?
--
Mike Chambers
Madisonville, KY
"Best little town on Earth!"
6:40 p.m.
On Wed, 29 Aug 2007 17:20:31 -0500
Mike Chambers <mike(a)miketc.com> wrote:
Why not os/RPMS/<the rpms here>? That is what they are :P
Because when I talked to the anaconda folks about it they preferred
Packages/ to RPMS/.
And of course it hedges our bets for when we go to debs, or tgzs, or
fpkgs...
</crazy>
And when is this move planning on taking place?
The rawhide that is slowly rsyncing it's way to the master mirror
servers has this change in it, wanted to get it in for the Feature
freeze and test2.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
7:51 p.m.
Jesse Keating wrote:
As part of a continuing effort to make derivative distributions of
Fedora easier, we're making the path names within the tree a bit more
generic. Instead of os/Fedora/<packages> the path will now be
os/Packages/<packages>.
This seems like a good time to bring up this question regarding
derivative distributions-
Is it okay - (and I'm pretty sure the current position is yes, but I'd
like reassurance, and ideally a wiki/faq entry if none exists already)
- to include the fedora-release rpm (not fedora-logos) in a derivative
distribution?
If not, what I am more specifically interested in, is the fedora rpm gpg
key, and the yum configurations that point at fedora servers.
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.
Thoughts? Pointers to existing wiki/faqs that -
google://"fedora derivative distributions policy"
didn't make utterly obvious?
Thanks,
-dmc
8:43 p.m.
On Wed, 29 Aug 2007 19:51:55 -0500
Douglas McClendon <dmc.fedora(a)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.
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.
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.
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.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:26 p.m.
Jesse Keating wrote:
On Wed, 29 Aug 2007 19:51:55 -0500
Douglas McClendon <dmc.fedora(a)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
9:35 p.m.
On Wed, 29 Aug 2007 21:26:11 -0500
Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
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?).
GPL wants "No less than 3 years".
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.
There are multiple ways to distribute the binaries (and source) under
the GPL. You either deliver it at the same time as you deliver the
binaries:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections 1
and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years,
to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the
terms of Sections 1 and 2 above on a medium customarily used for
software interchange; or,
c) Accompany it with the information you received as to the offer to
distribute corresponding source code. (This alternative is allowed only
for noncommercial distribution and only if you received the program in
object code or executable form with such an offer, in accord with
Subsection b above.)
Right now, Fedora does A. That means that when we make the binary go
away, we can make the source go away too. Otherwise we'd be on the
hook to keep hosting the sources to every binary we release for no less
than 3 years time.
What you're asking to do is c), include the forwarded promise that
Fedora made to you. It's not clear to me how to handle cases where
it's near the end of year 3 of the original promise, yet you do a "new"
binary release of your distribution including the notice. The notice
is only good for say another year, do you have to some how extend that
to 3 years?
By far, the easiest to use and comply with is A), and that's what
Fedora chooses to do, therefor we aren't already obligated to keep
anything around for any amount of time other than for as long as the
binaries are available.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:53 p.m.
Jesse Keating wrote:
On Wed, 29 Aug 2007 21:26:11 -0500
Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
> 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?).
GPL wants "No less than 3 years".
> 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.
There are multiple ways to distribute the binaries (and source) under
the GPL. You either deliver it at the same time as you deliver the
binaries:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections 1
and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years,
to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the
terms of Sections 1 and 2 above on a medium customarily used for
software interchange; or,
c) Accompany it with the information you received as to the offer to
distribute corresponding source code. (This alternative is allowed only
for noncommercial distribution and only if you received the program in
object code or executable form with such an offer, in accord with
Subsection b above.)
Right now, Fedora does A. That means that when we make the binary go
away, we can make the source go away too. Otherwise we'd be on the
hook to keep hosting the sources to every binary we release for no less
than 3 years time.
What you're asking to do is c), include the forwarded promise that
Fedora made to you. It's not clear to me how to handle cases where
it's near the end of year 3 of the original promise, yet you do a "new"
binary release of your distribution including the notice. The notice
is only good for say another year, do you have to some how extend that
to 3 years?
That was a truly excellent reply (very clear).
Because of your first reply, and how it is OK to have a derivative
distro pointing at fedora yum repos by default, this is not such a big
deal. Especially as I am personally only concerned with a livecd style
derivative distro. Maintaining my own hosted set of just the src rpms
that match what I put on a livecd, is not so bad. The real worry was if
I couldn't leech off of fedora yum repos, and if I had to go and
maintain my own copy of Everything.
Thanks,
-dmc
5:01 a.m.
On Wed, 29 Aug 2007 21:53:27 -0500
Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
That was a truly excellent reply (very clear).
Because of your first reply, and how it is OK to have a derivative
distro pointing at fedora yum repos by default, this is not such a
big deal. Especially as I am personally only concerned with a livecd
style derivative distro. Maintaining my own hosted set of just the
src rpms that match what I put on a livecd, is not so bad. The real
worry was if I couldn't leech off of fedora yum repos, and if I had
to go and maintain my own copy of Everything.
Perhaps I wasn't clear enough. You'll still need to host all the srpms
you use in your initial binary release. After that, if you're just
relying upon Fedora for the updates, since Fedora handles the binary
and the source for those you don't have to worry. You just have to
worry about updates to the additional packages you put in your spin.
You have to make sure that the source rpms used to create your Live
image stay around for as long as your Live image is available for
download. This may be longer than Fedora keeps those srpms around.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
4:36 a.m.
Douglas McClendon writes:
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.
Tough. It's what the GPL says. If you supply someone with a binary,
you have to supply the source. You can't point someone somewhere else
and say "the source is over there, get it yourself".
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
4:39 a.m.
Andrew Haley wrote:
Douglas McClendon writes:
> 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.
Tough. It's what the GPL says. If you supply someone with a binary,
you have to supply the source. You can't point someone somewhere else
and say "the source is over there, get it yourself".
You can in some circumstances do exactly that. A derivative distribution
can very well point to the upstream distribution as the canonical source
if the upstream distribution agrees to it explicitly.
Rahul
5:30 a.m.
Rahul Sundaram writes:
Andrew Haley wrote:
> Douglas McClendon writes:
>
> > 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.
>
> Tough. It's what the GPL says. If you supply someone with a binary,
> you have to supply the source. You can't point someone somewhere else
> and say "the source is over there, get it yourself".
You can in some circumstances do exactly that. A derivative distribution
can very well point to the upstream distribution as the canonical source
if the upstream distribution agrees to it explicitly.
If you distribute binaries, it is your responsibility to
"offer equivalent access to the Corresponding Source in the same
way through the same place at no further charge. You need not
require recipients to copy the Corresponding Source along with the
object code. If the place to copy the object code is a network
server, the Corresponding Source may be on a different server
(operated by you or a third party) that supports equivalent
copying facilities, provided you maintain clear directions next to
the object code saying where to find the Corresponding Source.
Regardless of what server hosts the Corresponding Source, you
remain obligated to ensure that it is available for as long as
needed to satisfy these requirements."
Of course, the source and binary may be on different servers, but it
remains *your* responsibility to make sure the source is available,
even if it's on a third party server.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
6 a.m.
Andrew Haley wrote:
Of course, the source and binary may be on different servers, but it
remains *your* responsibility to make sure the source is available,
even if it's on a third party server.
Of course but derivative distributions and even respins would want is
the ability to point to Fedora for the source and I think we can
accommodate that requirement without any additional liability.
Rahul
8:37 a.m.
On Thu, 30 Aug 2007 16:30:41 +0530
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
Of course but derivative distributions and even respins would want is
the ability to point to Fedora for the source and I think we can
accommodate that requirement without any additional liability.
I don't think we can, as we'd have to start distributing under 3b, for
every single binary we ship. That's going to piss off a lot of mirrors
if they have to carry all copies of the source of every update we've
ever released for (at least) three years.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:12 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Keating wrote:
On Thu, 30 Aug 2007 16:30:41 +0530
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
> Of course but derivative distributions and even respins would want is
> the ability to point to Fedora for the source and I think we can
> accommodate that requirement without any additional liability.
I don't think we can, as we'd have to start distributing under 3b, for
every single binary we ship. That's going to piss off a lot of mirrors
if they have to carry all copies of the source of every update we've
ever released for (at least) three years.
Do they have to be in the same tree on all mirrors, or can the master
download server (say http://download.fedora.redhat.com) have a larger
tree then the master server the mirrors sync from?
- --
Kind regards,
Jeroen van Meeuwen
- -kanarip
- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG1tBlKN6f2pNCvwgRAigQAKCT4lr+wbSaOcT6ppC78Mx5WwbsUwCeM/vK
nourPxinHt9Hx+rhByn6HQA=
=D9uX
-----END PGP SIGNATURE-----
9:16 a.m.
Jeroen van Meeuwen wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Keating wrote:
> On Thu, 30 Aug 2007 16:30:41 +0530
> Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
>
>> Of course but derivative distributions and even respins would want is
>> the ability to point to Fedora for the source and I think we can
>> accommodate that requirement without any additional liability.
> I don't think we can, as we'd have to start distributing under 3b, for
> every single binary we ship. That's going to piss off a lot of mirrors
> if they have to carry all copies of the source of every update we've
> ever released for (at least) three years.
You can store things but not mirror them.
Rahul
9:16 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Keating wrote:
On Thu, 30 Aug 2007 16:30:41 +0530
Rahul Sundaram <sundaram(a)fedoraproject.org> wrote:
> Of course but derivative distributions and even respins would want is
> the ability to point to Fedora for the source and I think we can
> accommodate that requirement without any additional liability.
I don't think we can, as we'd have to start distributing under 3b, for
every single binary we ship. That's going to piss off a lot of mirrors
if they have to carry all copies of the source of every update we've
ever released for (at least) three years.
In addition (I forgot to mention that in my previous message), 3b
requires you distribute the sources (along with the binaries, for 3
years from the moment the offer for the sources is made) using a common
method; that requirement doesn't include any mirrors also carrying the
sources or entire tree of binaries; or that you provide instructions on
how to get the source code (3c can pass those instructions along) and
you may not charge any more then it costs you (example burning and
shipping the media).
- --
Kind regards,
Jeroen van Meeuwen
- -kanarip
- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG1tEgKN6f2pNCvwgRAvnwAKDMbl7Y45xEbqXJGaJKbheSMiBIVwCffh/O
h3NcqEH9xjk0tEU2Oh5wpsw=
=QSPQ
-----END PGP SIGNATURE-----
6101
days inactive
6102
days old
18 comments
8 participants
participants (8)
-
Andrew Haley -
Douglas McClendon -
Jeroen van Meeuwen -
Jesse Keating -
Jima -
Mike Chambers -
Rahul Sundaram -
Roland McGrath