Managing GPL source; was: Re: backports web interface type thing...

[Stephan Hermann]

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 <sam at liddicott.com> 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 <sam at liddicott.com> 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
> > > ubuntu-backports at lists.ubuntu.com
> > > http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
> >
> > --
> > ubuntu-backports mailing list
> > ubuntu-backports at lists.ubuntu.com
> > http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports