On Wed, 22 Jan 2025 01:03:23 +0000
Simon Quigley <simon@tsimonq2.net> wrote:
> Hello,
>
> I have been working on a general effort to improve the new packaging
> guide[1]. As a general note, please consider joining me.
>
> As part of this effort, with the help of Aaron Rainbolt[2], I have
> written an initial, rough draft of best practices for licensing
> packages in Ubuntu. This is based on our *de facto* copyright
> practices in Lubuntu.
>
> You can also find a changelog and Git history here[3], with a
> rendered copy of the draft pull request here[4].
>
> I would like to open this up for general comment from the Ubuntu
> Archive Admins and other Ubuntu Developers, then ask the Ubuntu
> Archive Admins to officially ratify it before it is merged into the
> packaging guide.
>
> The Ubuntu Archive Admins may consider escalating this to the
> Technical Board for approval, at their discretion. That being said, I
> would like all relevant parties to participate, and come to an
> agreement before it is merged.
>
> If something like this already exists, which parts need to be
> included? Is there anything factually incorrect or misleading in the
> text below? Do you know of good examples that should be included as a
> reference?
>
> Most importantly, I am unsure about the specific requirements for a
> package to be moved to Multiverse or Restricted. I have never
> uploaded a brand new source package to either, to my recollection.
>
> Lastly, the intent of this is to clarify existing procedures around
> licensing in Ubuntu. Could we please save discussion on actually
> changing those standards for another thread?
>
> The full text, as it currently stands:
>
> ===== START RST-FORMATTED TEXT =====
>
> Copyright and Licensing
> =======================
>
> Ubuntu is a collection of free and open source software. As such, it
> is critical to ensure the licensing of our packages is reviewed
> carefully.
>
> It is important to verify a package's :file:`debian/copyright` file
> when creating patches, updating to new upstream releases, and
> creating new packages altogether. Understanding copyright can be a
> time-consuming task, but being conscious of licensing standards
> broadens your perspective on how software may interact.
>
> DEP-5 and Copyright Files
> -------------------------
>
> Ubuntu and Debian use the `DEP-5 standard
> <https://dep-team.pages.debian.net/deps/dep5/>`_ for tracking
> copyright references in packages. Per Debian Policy `4.5
> <https://www.debian.org/doc/debian-policy/ch-source.html#copyright-debian-copyright>`_,
> `12.5
> <https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile>`_,
> and `2.3
> <https://www.debian.org/doc/debian-policy/ch-archive.html#s-pkgcopyright>`_
> (which should be considered as the Single Source Of Truth for policy
> regarding copyright files), every package must have a copyright file.
> While DEP-5 is technically not a hard requirement, it is best
> practice to use DEP-5 when creating or updating packages.
>
> When you should (not) rewrite a copyright file to use DEP-5
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> You **should** rewrite a copyright file to use DEP-5 if:
>
> * you are updating to a new upstream version in an Ubuntu-only
> package.
> * you are updating to a new upstream version in a package that is in
> both Debian and Ubuntu, and you are sending the delta upstream to
> Debian.
> * a package you maintain in Debian does not use DEP-5.
>
> You **should not** rewrite a copyright file to use DEP-5 if:
>
> * you are performing a Stable Release Update, except in the case of
> documented Microrelease Exceptions.
> * a package does not have an extensive Ubuntu delta and you do not
> plan on sending the change to Debian.
> * there is general disagreement with the team claiming maintenance of
> the package in Ubuntu (this should be discussed on the ubuntu-devel
> mailing list).
> * the package contains an extremely large number of files under
> different copyrights, and the maintenance of an accurate DEP-5
> copyright file for the package would render further maintenance
> effectively impossible. This exception is not to be used lightly, and
> should be fallen back on only for the largest and most extremely
> complicated packages in Debian and Ubuntu, such as the Linux kernel.
>
> Unclear Licensing and Special Cases
> +++++++++++++++++++++++++++++++++++
>
> There are several cases in which the licensing of source files is
> questionable. Below you will find several examples; when in doubt
> about a specific license, please review the DFSG FAQ linked in the
> Resources section:
>
> * A source package which contains no licensing information is
> considered to be proprietary, and thus not eligible for inclusion in
> Ubuntu.
> * Files licensed in the public domain still must be listed in the
> copyright file. Some jurisdictions allow copyright for software to be
> changed posthumously, so it is important to still credit authors in
> this case.
>
> Copyright of Image Files
> ++++++++++++++++++++++++
>
> When including image files in a source package, you should also
> verify there are no embedded licenses within the `Exif data
> <https://en.wikipedia.org/wiki/Exif>`_ for the image. Additionally,
> you should also ensure the color profile is free. (Examples of
> non-free color profiles include the `Adobe formats
> <https://www.adobe.com/support/downloads/iccprofiles/icc_eula_win_end.html>`_.)
>
> You can use the following Bash script to determine whether an image
> file has such data:
>
> .. code-block:: bash
>
> for i in *; do
> if [[ "$(exiftool "$i")" =~
> (creator|copyright|license|description) ]]; then exiftool "$i"
> fi
> done
>
> A non-free image file may output something like:
>
> .. code-block:: ini
>
> Profile Creator : Hewlett-Packard
> Profile Copyright : Copyright (c) 1998
> Hewlett-Packard Company Profile Description : Adobe RGB
> 1998
>
> If there are no licensing details within the Exif data, it is assumed
> that it is licensed the same as the source package or specific
> directory it resides in.
>
> While this was later proved to be a false positive, you can find an
> example of a non-free image (and how to inform upstreams) `here
> <https://github.com/lxqt/lxqt-runner/issues/241>`_.
Some corrections on some of the stuff with image copyright:
* There are two separate issues here, the issue of copyrighted images
themselves, and the issue of copyrighted color profiles. The tl;dr:
is that both are stored in the same file but are separate "entities"
from a copyright perspective (images are, well, images, color
profiles are a form of code at least according to Adobe's ICC profile
EULA which Simon linked above).
* If you run into a copyrighted *image*, you'll probably see something
like this in the exiftool output:
Copyright : PAULO SILVA LANDSCAPE PHOTOGRAPHY
Copyright Notice : PAULO SILVA LANDSCAPE PHOTOGRAPHY
This came from a random "all rights reserved" image on Flickr[1]. Not
all such images have a notice like this, but some do. If you see
something like this and you *don't* see any licensing data, that's a
very large red flag that the image may not be acceptable in Ubuntu,
and you should probably report it as a bug. For an example of such a
bug report, see [2].
* If you run into a copyrighted *color profile* on the other hand,
you'll run into this sort of thing:
Profile Copyright : Copyright Apple Inc., 2022
When you hit this, you should investigate the exiftool output more
closely, determine the color profile name, look it up, and try to
find the copyright info. For the image that gave me this particular
copyright notice[3], exiftool showed me that the profile was named
"Display P3" which led me to a page on the International Color
Consortium's website for that profile[4], where I could download it
as a ZIP. Upon opening the ZIP, I found a License.txt file containing
a very permissive and DFSG-compliant license within. So this
particular profile is fine. On the other hand, another random photo I
found[5] gave me this:
Profile CMM Type : Unknown (UCCM)
Profile Version : 2.4.0
Profile Class : Display Device Profile
Profile Connection Space : XYZ
Profile Date Time : 2003:04:04 00:00:00
Profile File Signature : acsp
Profile Creator : Canon, Inc. (Canon Development
Americas, Inc.)
Profile ID : 0
Profile Copyright : Copyright (c) 2003, Canon Inc.
All rights reserved.
Profile Description : sRGB v1.31 (Canon)
Now I can't imagine that this "All rights reserved" really means
there isn't any license for this profile since otherwise why would
Canon be letting people distribute pictures taken with the profile,
but actually trying to *find* that license is... well, if you want to
try to find it, be my guest, I tried and failed miserably. In this
instance it's safest to say that the profile is DFSG-noncompliant.
* If you find a copyrighted *image* that isn't licensed under a
DFSG-compliant license, the image can't come into Ubuntu or Debian,
and you should remove the image entirely. If you find a copyrighted
*color profile*, you can strip the profile from the image without
removing the image entirely. GIMP can be used for this in a pinch,
preferably upstream should strip the profile as well.
Finally, don't just strip the image metadata from the image to make it
look "kosher". That would be equivalent to deleting the copyright and
license headers from a source code file. I only mention this since
sarnold on IRC mentioned that the wording in Simon's email could be
misunderstood as "just strip the metadata and you'll be fine :D" Don't
do that, it will NOT be Simon's fault when you're found out.
Whew, that ended up being a bit of a rabbit hole. Maybe image copyright
auditing needs its own documentation page?
[1] https://www.flickr.com/photos/pauloprinter/54275750879
[2] https://bugreports.qt.io/browse/QTBUG-126255
[3] https://www.flickr.com/photos/46484616@N04/54274387103
[4] https://www.color.org/chardata/rgb/DisplayP3.xalter
[5] https://www.flickr.com/photos/141175700@N02/54273195717
> Tools for Copyright File Verification
> -------------------------------------
>
> Many tools exist to verify the licenses in a package. You can find a
> current list on the `CopyrightReviewTools Debian Wiki page
> <https://wiki.debian.org/CopyrightReviewTools>`_.
>
> The most commonly used tool for this is :manpage:`licensecheck(1)`.
> Here is an example of how you may use it:
>
> .. code-block:: bash
>
> licensecheck --check '.*' --recursive --deb-machine --lines 0 --
> *
>
> If all else fails, you will need to manually open each file and make a
> determination based on its copyright header (if there is one).
>
> Resources
> ---------
>
> * `Debian Free Software Guidelines
> <https://www.debian.org/social_contract.html#guidelines>`_
> * `DFSG and Software License FAQ (Draft)
> <https://people.debian.org/~bap/dfsg-faq.html>`_
> * `Licensing exercises from the Debian Developer process
> <https://salsa.debian.org/nm-team/nm-templates/-/blob/master/nm_pp1.txt?ref_type=heads#L48>`_
>
> - It can be incredibly helpful to answer these questions in your
> own notes, and ask a Debian Developer to verify your answers.
> Alternatively, you may politely ask a Debian Developer for their own
> answers to those questions.
>
> * `Ubuntu open-source licenses
> <https://ubuntu.com/legal/open-source-licences>`_
> * `Debian license information
> <https://www.debian.org/legal/licenses/>`_
> * `DFSGLicenses on the Debian Wiki
> <https://wiki.debian.org/DFSGLicenses>`_
> * `The Open Source Definition from OSI <https://opensource.org/osd>`_
> * `debian-legal mailing list archives
> <https://lists.debian.org/debian-legal/>`_
>
> ===== END RST-FORMATTED TEXT =====
>
> [1] https://github.com/canonical/ubuntu-packaging-guide
> [2] Erich Eickmeyer also pointed me to some of the specific public
> domain topics based on past rejects.
> [3] https://github.com/tsimonq2/ubuntu-packaging-guide/tree/tsimonq2/copyright-and-licensing [4] https://canonical-ubuntu-packaging-guide--88.com.readthedocs.build/en/88/how-to/copyright-and-licensing/
>
> Thanks,
