Hi, the problem is only, that Sam is right, and we are wrong. The dapper sources of backported packages are not archived.
Example: http://archive.ubuntu.com/ubuntu/pool/universe/k/k3b/ Backported version from dapper to breezy: 0.12.7 Latest Dapper version: 0.12.10 Missing source version: 0.12.7 Regards, \sh On Wednesday 28 December 2005 04:04, John Dong wrote: > Ok, so what you're saying is that as soon as sources are pulled, binaries > must be pulled pretty fast thereafter, correct? > > That's already done with the current Backports system. If we cache packages > for retrieval, we'll cache sources along with binaries, and remove them at > the same time. > > On 12/27/05, Sam Liddicott <[EMAIL PROTECTED]> wrote: > > John Dong wrote: > > > > Well, again, sources are exactly the same as in Dapper, so that'll lessen > > the burden... > > > > It will not lessen it, depending on dapper sources management it will > > increase the burden. > > > > > > http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSit > >es suggests that references to dapper sources *are* enough, but it will be > > neccessary to remove backports binaries at the same time the original > > dapper sources are removed or to retain dapper sources as long as > > backports are available. > > > > If my understanding is correct, the dapper packages are likely to be > > around for less time than the backports, as packports either lag dapper > > slightly or miss some dapper upgrades altogether. > > > > Thus an extra admin burden is involved, in synchronizing dapper sources > > with hoary backports. > > > > > > Also, is the 3 year clause really that tightly enforced? > > > > > > The 3 year clause is actually worse than many think, it applies to mail > > order requests for the source: > > > > http://www.gnu.org/licenses/gpl-faq.html#TOCDistributeWithSourceOnInterne > >t shows that the 3 year clause of section 3 of the GPL cannot be satisfied > > with mere internet access to source. > > > > Whether or not it is "enforced" is irrellevant, it's a matter of > > copyright law. For GPL packages, nothing apart from the GPL gives right > > to distribute GPL works or derivative works. If the license is not > > followed, the works cannot be legally distributed, it may just be the FSF > > or copyright holding developers that come knocking instead of the RIAA. > > > > You are right, how can someone enforce the 3 year clause 2 years after > > the binary was pulled and the source has long gone? > > > > A question that may be asked is: Is a reasonable effort being made to > > comply with the requirements of the GPL? > > > > Unless steps are taken to archive sources such that they can be supplied > > by mail order, the answer to such a question would be "no steps are taken > > to reasonably comply" which indicates very bad faith. > > > > For example, (http://archive.ubuntu.com/ubuntu/pool/main/f/firefox/), the > > earlier (1-2 month old) ubuntu builds of 1.4.99+1.5rc3 have already been > > removed from the repository. > > > > > > This makes it knowingly hard to rely on that archive to provide older > > sources. > > > > The only low-admin way to comply with the GPL is to provide sources at > > the same point of distribution as the binaries; this permits the sources > > to be pulled as soon as the binaries are pulled, it may also duplicate > > sources between dapper and backports, but thats a small downside for > > having no other overheads. It also removes the need to fulfil the 3 year > > mail order clause, which though unyielding, is burdensome and not > > appropriate. > > > > I'll even pay for the disk to stick in the server. > > > > The GPL is clear and the GPL faq is clearer and after much reading and > > multiple question and answer sessions with the FSF I am convinced that > > source-with-binary is the only sensible method for small organisations > > with online distribution to comply with the GPL. > > > > Its most attractive feature is that it limits the duration of liability > > to the time during which the organisation engages in distribution. Other > > features are low procedural overhead which can easily be automated, and > > less troublesome correspondance from users who want the source (which may > > be impossible to fulfil). > > > > Sam > > > > On 12/26/05, Sam Liddicott <[EMAIL PROTECTED]> wrote: > > > John Dong wrote: > > > > My vision for it: > > > > > > > > Users enter a backport request into a web interface. > > > > > > > > The request is quickly run through a set of rules (i.e. no libraries, > > > > package blacklist), and then a build is done. > > > > > > > > After the build, users can "pick up" their debs. Other users with the > > > > same request will get the same debs (caching) > > > > > > Please don't shoot me.... or feel the need to respond just to me; I'm > > > not critisizing anyone; > > > > > > just a reminder, for GPL/LGPL licensed packages, it would have to make > > > the source available at the same time/place or for 3 years to all 3rd > > > parties. Such management is a curse. It would be easiest to make the > > > src debs available as part of the automatic system for all packages. > > > > > > Sam > > > > > > > > > -- > > > ubuntu-backports mailing list > > > [email protected] > > > http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports > > > > -- > > ubuntu-backports mailing list > > [email protected] > > http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports -- ubuntu-backports mailing list [email protected] http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
