[copyleft-next] copyleft-next compliance for Debian

Ben Hutchings ben at decadent.org.uk
Sat Aug 23 04:25:11 UTC 2014


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.

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?

> 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.

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

-- 
Ben Hutchings
Lowery's Law:
             If it jams, force it. If it breaks, it needed replacing anyway.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/copyleft-next/attachments/20140822/5cd531e2/attachment.sig>


More information about the copyleft-next mailing list