[copyleft-next] copyleft-next compliance for Debian

Richard Fontana fontana at sharpeleven.org
Sat Aug 23 06:06:39 UTC 2014


On Fri, 22 Aug 2014 21:25:11 -0700
Ben Hutchings <ben at decadent.org.uk> wrote:

> I'm preparing to package a new version of crda for Debian and
> therefore I'm looking at the text of its new licence, copyleft-next
> 0.3.0[1].
> 
> This seems to meet the DFSG[2], making the new version of crda
> suitable for inclusion in Debian, yet I'm not certain that we and our
> distributors would currently comply with its terms:
> 
> > 5. Conditions for Distributing Object Code
> > 
> >    You may Distribute an Object Code form of a Covered Work,
> > provided that you accompany the Object Code with a URL through
> > which the Corresponding Source is made available, at no charge, by
> > some standard or customary means of providing network access to
> > source code.
> > 
> >    If you Distribute the Object Code in a physical product or
> > tangible storage medium ("Product"), the Corresponding Source must
> > be available through such URL for two years from the date of Your
> > most recent Distribution of the Object Code in the Product.
> > However, if the Product itself contains or is accompanied by the
> > Corresponding Source (made available in a customarily accessible
> > manner), You need not also comply with the first paragraph of this
> > section.
> 
> Since we don't keep old releases in the main FTP archive, the source
> URLs that APT is configured to use can become stale within 2 years of
> receiving a CD/DVD (or could even be stale already).  So far as I
> can see, our CD/DVD distributors cannot comply with this by
> making the sources available in the same way - they must provide a
> URL for network access.

Hmm, yes. I hadn't thought of this sort of case.

> We can now advertise stable URLs for source packages on
> http://snapshot.debian.org, but we do not include such URLs in binary
> packages.  Perhaps it would be sufficient to document the site
> somewhere in the base system?

Yes, that seems like a reasonable approach.

I think a future revision of the license ought to clarify this, so
thank you for calling attention to it.

> > 15. Definitions
> [...]
> >     "Corresponding Source" of a Covered Work in Object Code form
> > means (i) the Source Code form of the Covered Work; (ii) all
> > scripts, instructions and similar information that are reasonably
> > necessary for a skilled developer to generate such Object Code from
> > the Source Code provided under (i); and (iii) a list clearly
> > identifying all Separate Works (other than those provided in
> > compliance with (ii)) that were specifically used in building and
> > (if applicable) installing the Covered Work (for example, a
> > specified proprietary compiler including its version number).
> > Corresponding Source must be machine-readable.
> [...]
> >     "Separate Work" means a work that is separate from and
> > independent of a particular Covered Work and is not by its nature
> > an extension or enhancement of the Covered Work, and/or a runtime
> > library, standard library or similar component that is used to
> > generate an Object Code form of a Covered Work.
> 
> I'm not sure quite what we need to for item (iii) of Corresponding
> Source.  Are the Build-Depends and Build-Depends-Indep fields[3]
> in a Debian source package sufficient?  Or do we need to record which
> versions were actually used to build each binary package?  We do log
> the versions of build-dependencies for auto-built binaries, but not
> for developer-uploaded binaries.  We don't advertise the URLs for
> build logs anywhere in the installed system.

The Build-Depends and Build-Depends-Indep fields (as I understand them)
should be sufficient for a Debian source package.

The policy intention here is for the user to be able
to rebuild the binary from the supplied Corresponding Source without
undue effort or experimentation. The real target here
is the proprietary or trade secret build systems that I understand
plague many of the widely-encountered GPL noncompliance cases (hence
the example refers to a specific version of a proprietary compiler --
the user ought to know that the binary was built with this proprietary
compiler in case the user wishes to procure a copy of it himself or
herself). Here too I can see how this language can be improved so as not
to be read as burdensome for the free software distribution case. 

Another way of looking at this is that the definition of Corresponding
Source isn't really meant to expand (much) upon what ought to be
required under GPLv2 and GPLv3 on a reasonable but non-narrow reading
of those licenses by those persons engaged in community enforcement of
the GPL. So I would say that if compliance with part (iii) were
problematic for Debian it would suggest that compliance with the GPL
would also be problematic for Debian, which can't be right, and so it
ought to be straightforward for Debian to be in compliance through its
normal efforts of complying with the GPL for GPL-licensed packages. 

I hope that is at least somewhat helpful but if not let me know.

Richard








> 
> Ben.
> 
> [1]
> https://gitorious.org/copyleft-next/copyleft-next/raw/3baab310f662811ba48d8a86bfe7f9ef7ef612dc:Releases/copyleft-next-0.3.0
> [2] https://www.debian.org/social_contract#guidelines [3]
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps
> 



More information about the copyleft-next mailing list