1. Forum
  2. Usenet
  3. LINUX.DEBIAN.LEGAL

  • Declaring license for autogenerated file (W3C)

    From Diego M. Rodriguez@21:1/5 to All on Thu Jun 17 14:50:01 2021
    Hello,

    as part of packaging "pylatexenc" [1], I'm unsure on how to properly
    declare the license attribution of one of the files in the upstream package.

    Upstream mentions that the file
    ("pylatexenc/latexencode/_uni2latexmap_xml.py" [2]) is:
    # Automatically generated from unicode.xml by gen_xml_dic.py

    although the "unicode.xml" file itself it is not included in the release tarball. It is present in their repository, along with its license [3]
    (and highlighted in the README, which seems to be W3C.

    My initial attempt to convey this information in d/copyright [4] tries
    to reflect:
    1. the "_uni2latexmap_xml.py" is a derivative of the "unicode.xml", and
    as a result is covered by the same W3C license.
    2. the "_uni2latexmap_xml.py" is also covered by the MIT license, as the
    rest of the files in the package.
    3. the "unicode.xml.LICENSE" needs to be copied verbatim in d/copyright
    in order to cover all the details.

    However, I'm not familiar with the W3C license (nor with d/copyright
    finer points). Would it be possible to have advise on whether the
    assumptions and the current d/copyright is suitable - and help on
    correcting otherwise?

    Best regards,

    [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950664
    [2] https://github.com/phfaist/pylatexenc/blob/v2.10/pylatexenc/latexencode/_uni2latexmap_xml.py
    [3]
    https://github.com/phfaist/pylatexenc/blob/v2.10/tools/unicode.xml.LICENSE
    [4] https://salsa.debian.org/python-team/packages/python-pylatexenc/-/blob/105ecb9bb8f96b8d253bf8244fd17617af6ea9d2/debian/copyright#L14
    --
    Diego M. Rodriguez

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sam Hartman@21:1/5 to All on Thu Jun 17 17:20:01 2021
    "Diego" == Diego M Rodriguez <[email protected]> writes:
    Diego> ("pylatexenc/latexencode/_uni2latexmap_xml.py" [2]) is: #
    Diego> Automatically generated from unicode.xml by gen_xml_dic.py

    Diego> although the "unicode.xml" file itself it is not included in
    Diego> the release tarball. It is present in their repository, along
    Diego> with its license [3] (and highlighted in the README, which
    Diego> seems to be W3C.

    This is probably obvious, but if you are targeting main, you'll need to
    include the unicode.xml in your source package or generate from a
    unicode.xml that is somewhere already in Debian.
    (I don't know if this unicode.xml is repackaging of Unicode Consortium
    data or something else already packaged).


    For specifying in debian/copyright you might be better off asking on debian-mentors.
    You seem to have the legal issues well in hand.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Lustfield@21:1/5 to Diego M. Rodriguez on Thu Jun 17 19:30:02 2021
    Please forgive any screwy formatting; I'm trying out evolution again...

    On Thu, 2021-06-17 at 14:28 +0200, Diego M. Rodriguez wrote:
    Hello,

    as part of packaging "pylatexenc" [1], I'm unsure on how to properly
    declare the license attribution of one of the files in the upstream package. [...]
    However, I'm not familiar with the W3C license (nor with d/copyright
    finer points). Would it be possible to have advise on whether the assumptions and the current d/copyright is suitable - and help on
    correcting otherwise?
    [...]
    [4] https://salsa.debian.org/python-team/packages/python-pylatexenc/-/blob/105ecb9bb8f96b8d253bf8244fd17617af6ea9d2/debian/copyright#L14

    From my perspective, you did a relatively adequate job documenting the oddity in
    d/copyright. It seems that this file rarely ever (never) changes, so dropping a copy into d/missing_sources/unicode.xml should definitely happen.

    Observations:
    - Phillipe might have a copyright on _uni2latexmap_xml.py, but I see no evidence
    they have one on unicode.xml.
    - I also don't see any evidence that Expat is a valid license for unicode.xml. - Trying to explain that all in one paragraph is messy, confusing, and difficult.


    Suggestion -->

    Files: pylatexenc/latexencode/_uni2latexmap_xml.py
    Copyright: 2015-2019 Philippe Faist
    2015 World Wide Web Consortium
    1999-2015 David Carlise
    License: Expat and W3C
    Comment: The file 'unicode.xml' (d/missing_sources/unicode.xml) is used to
    generate this file during release tarball creation.

    Files: debian/missing_sources/unicode.xml
    Copyright: 2015 World Wide Web Consortium
    1999-2015 David Carlise
    License: W3C
    Comment: This file was copied from w3.org, is used to generate source, and is
    then dropped from the final release tarball. The source header contains
    additional information about the origins and history of this file.

    --
    Michael Lustfield

    -----BEGIN PGP SIGNATURE-----

    iQJKBAABCgA0FiEEBs1j101ZjEpH5CyWA6iJGnZa0IUFAmDLhSQWHG1pY2hhZWxA bHVzdGZpZWxkLm5ldAAKCRADqIkadlrQhdgkEACwrzULudYCXBy2t4rJMAh0TAF8 Ubtwye3cWJm5aWbeQrwbjpeF4Mq7H8IF+OM4mGBXs+oWkB4LPweCVS9bnSNL03fG VoBlnSjoafwDFyrWjwJHRL+nblCFX8L15ZZdweQerUqEvzROuxhzeSBLq7kXe2SX lDyttDVEH+ft7h5alygTg3ysuz9IelNl+1TJnaY/BqTzvKo8q9naryKkH8/UMPer jvBzcliauWKq+xIFnxirIv6gYKD12FGx6+9XSXuaQ0Y+Mnzg7WUMA+aW2lkD9VNt M9aw7xH9EUxnCYzr6G5Ff1TzL4p2ifEY9jr3IPdHm4FW5zD9tBpPAGPl4rRjoXNk t/OJ3SSOikgIBjAiGCD5TfQiDKpvZRMoWeEvYQN8TL/SQbVBHusRedTssIvYHNyz 0h5wBtGZ8qMVS03tqTndluYlECIdBtqRJ3+iNn167Np/+QtD9FOiaPyo5sMKBgQp CZbCnUbsdmdIPlqPeBL7IaPnIQhfswBoRALtpjQESYsQzBSDoeXHj9Aw5a0pev0k Tn7WrMc+/1DeXE+vGPfuvPbbCqQZLtV0r7s4RLg7YtWTz3kNcrtPT3PRZ8EjxuCf i9VERtXtD7E+hu2Epp7PcqJMQG9OARzPwcgKuC/e2TCMqKGv5NpWRMtBZZ6rEuhe ZuSiAAh2UjtKcML/pQ==
    =qIE6
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diego M. Rodriguez@21:1/5 to Michael Lustfield on Fri Jun 18 13:10:02 2021
    Hello Michael and Sam,

    and many thanks for the quick and detailed feedback and observations.

    On 6/17/21 7:23 PM, Michael Lustfield wrote:
    From my perspective, you did a relatively adequate job documenting the oddity in
    d/copyright. It seems that this file rarely ever (never) changes, so dropping a
    copy into d/missing_sources/unicode.xml should definitely happen.

    Actually, while the upstream tarball (from PyPI) does not include the unicode.xml file, upon closer inspection upstream does include it in
    their GitHub releases. If using the release for packaging is technically
    viable (looks like it will be), would it be preferable from the legal side?

    Suggestion --> [...]
    Thanks for spelling it out!

    --
    Diego M. Rodriguez

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Lustfield@21:1/5 to Diego M. Rodriguez on Fri Jun 18 20:40:01 2021
    On Fri, 18 Jun 2021 12:53:37 +0200
    "Diego M. Rodriguez" <[email protected]> wrote:

    [...]
    Actually, while the upstream tarball (from PyPI) does not include the unicode.xml file, upon closer inspection upstream does include it in
    their GitHub releases. If using the release for packaging is technically viable (looks like it will be), would it be preferable from the legal side?

    Suggestion --> [...]

    In that case, you can just use the correct path for unicode.xml, drop the comment from the second paragraph, and simplify the paragraph in the first.

    Both still appear to have a unique copyright/license from each other, as well as
    the rest of the project, so they should still both be represented separately.

    :: would it be preferable from the legal side?

    I'm a bit confused by this. It's always preferable to follow upstream releases when generating packages. Building packages from projects that don't create releases (see golang...) is a bit of a headache and helps result in some truly horrific version numbers. [1] If the upstream project provides releases, then definitely use them.

    What matters from a legal perspective is that you follow what is spelled out in the license. (That's also the primary concern behind packages passing through the NEW queue.)


    [1] 1:0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782-1+deb8u1
    --
    Michael Lustfield

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Wise@21:1/5 to All on Sat Jun 19 03:50:01 2021
    On Fri, Jun 18, 2021 at 11:09 AM Diego M. Rodriguez wrote:

    Actually, while the upstream tarball (from PyPI) does not include the unicode.xml file, upon closer inspection upstream does include it in
    their GitHub releases. If using the release for packaging is technically viable (looks like it will be), would it be preferable from the legal side?

    The upstream source (from GitHub in your case) should always be
    preferred over the downstream packaging (on PyPI in your case).
    Missing files, generated files, extra cruft and other things are
    common problems with the downstream redistributions.

    --
    bye,
    pabs

    https://wiki.debian.org/PaulWise

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Diego M. Rodriguez@21:1/5 to Paul Wise on Mon Jun 21 19:40:02 2021
    Hi Paul and Michael,

    On 6/19/21 3:45 AM, Paul Wise wrote:
    The upstream source (from GitHub in your case) should always be
    preferred over the downstream packaging (on PyPI in your case).
    Missing files, generated files, extra cruft and other things are
    common problems with the downstream redistributions.

    Acknowledged - and thanks again. I have updated the package [1] in order
    to use the GitHub release as the upstream source successfully, and was
    able to apply the suggested changes to d/copyright from Michael.

    I still have some technical work and refinements to tackle outside the
    thread, but many thanks for the help on moving the package forward and
    for all the information.

    Best,

    [1] https://salsa.debian.org/python-team/packages/python-pylatexenc
    --
    Diego M. Rodriguez

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)