Re: FWD: Copyright in LGPL projects
Thanks you for the confirmation. Really appreciate it! They have added a copyright file; so it should be all good. I was likely being overly cautious and they might have been too. It tripped me up when they indicated (L)GPL might have to be treated differently, and when I looked up projects that used LGPL, they seemed to follow a different style from say, BSD/MIT licensed ones. On 3/5/24 11:32, Andrey Rahmatullin wrote: There are no special formats for copyright files and the license shouldn't matter so I'm still not sure what's the actual question they have. In most software the top-level copyright is simply stated as one line in the top-level LICENSE or whatever file or even in the top-level README, and separate per-file copyrights are stated in the files themselves. The calibre one you linked is very unusual
Re: FWD: Copyright in LGPL projects
On Tue, Mar 05, 2024 at 03:50:27AM +0530, Alan M Varghese wrote: > What I meant was that upstream does not know where to put the copyright > information or > how it should be formatted. Or, to rephrase, is there a preferred format for > a COPYRIGHT file > in a project that uses LGPL? There are no special formats for copyright files and the license shouldn't matter so I'm still not sure what's the actual question they have. In most software the top-level copyright is simply stated as one line in the top-level LICENSE or whatever file or even in the top-level README, and separate per-file copyrights are stated in the files themselves. The calibre one you linked is very unusual. -- WBR, wRAR signature.asc Description: PGP signature
Re: FWD: Copyright in LGPL projects
What I meant was that upstream does not know where to put the copyright information or how it should be formatted. Or, to rephrase, is there a preferred format for a COPYRIGHT file in a project that uses LGPL? This is the issue I opened upstream: https://github.com/hyprwm/hyprlang/issues/28 On 3/5/24 01:38, Andrey Rahmatullin wrote: On Tue, Mar 05, 2024 at 12:38:00AM +0530, Alan M Varghese wrote: Hello Soren, Thank you for answering my queries. I will share this with the upstream project. The project authors are unsure how to do this for an LGPL project. I will see tomorrow if I can find an example of an LGPL project that includes the copyright information in the root of the project. (I found a project that does this for GPL[1], but not for LGPL). Why would that make a difference?
Bug#1065442: RFS: shaderc/2023.8-1 [RC] -- Library API for accessing glslc functionality - shared libraries
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "shaderc": * Package name : shaderc Version : 2023.8-1 Upstream contact : David Neto * URL : https://github.com/google/shaderc/ * License : Apache-2.0, BSD-3-clause * Vcs : https://salsa.debian.org/debian/shaderc Section : libs The source builds the following binary packages: glslc - Command line compiler for GLSL/HLSL to SPIR-V libshaderc-dev - Library API for accessing glslc functionality - static libraries and headers libshaderc1 - Library API for accessing glslc functionality - shared libraries To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shaderc/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shaderc/shaderc_2023.8-1.dsc Changes since the last upload: shaderc (2023.8-1) unstable; urgency=medium . * New upstream release - Refresh patches - Add patch to fix name of Python interpreter - Fix FTBFS (Closes: #1058397) - Refresh d/glslc.lintian-overrides * Fix linking of libshaderc.so, add autopkgtest (Closes: #1029939) * Add obj-x86_64-linux-gnu to d/clean * Use printf instead of echo to generate build-version.inc. Thanks to Vagrant Cascadian! (Closes: #1035324) * Build-Depends on pkgconf instead of pkg-config * d/copyright: update copyright year Regards, -- Philippe
Re: FWD: Copyright in LGPL projects
On Tue, Mar 05, 2024 at 12:38:00AM +0530, Alan M Varghese wrote: > Hello Soren, > > Thank you for answering my queries. > > I will share this with the upstream project. The project authors are unsure > how > to do this for an LGPL project. I will see tomorrow if I can find an example > of > an LGPL project that includes the copyright information in the root of the > project. > (I found a project that does this for GPL[1], but not for LGPL). Why would that make a difference? -- WBR, wRAR signature.asc Description: PGP signature
Re: FWD: Copyright in LGPL projects
Hello Soren, Thank you for answering my queries. I will share this with the upstream project. The project authors are unsure how to do this for an LGPL project. I will see tomorrow if I can find an example of an LGPL project that includes the copyright information in the root of the project. (I found a project that does this for GPL[1], but not for LGPL). [1] https://github.com/kovidgoyal/calibre/blob/master/COPYRIGHT Regards, Alan On 3/4/24 23:49, Soren Stoutner wrote: Alan, These are good questions. 1. Yes, there must be a copyright statement. Only the person, people, group, or organization that holds the copyright can issue a license for other people to use the work. So, you must have someone claiming a copyright or they do not have the legal ability to release the work to others under the LGPL. 2. No, it is not required that each individual file contain a copyright statement or the header of the LGPL at the top. The FSF recommends such as a best practice, and I would agree that it is desirable, but it is not required. My recommendation would be that you communicate to the upstream project that they need to include the copyright and licensing information in the root of their repository, preferably all in one file, as a minimum requirement for you to be willing to package their project in Debian. Soren On Sunday, March 3, 2024 11:06:30 PM MST Alan M Varghese wrote: Sent message incorrectly to debian-mentors-request instead of debian- mentors. Correcting. Forwarded Message Subject: Copyright in LGPL projects Date: Mon, 4 Mar 2024 11:10:58 +0530 From: Alan M Varghese To: 1065...@bugs.debian.org CC: Matthias Geiger , SmartList Hello Mentors, I have been working on packaging Hyprland window manager. hyprlang[0] (with a 'g') is a new dependency for this project. This project (hyprlang) is licensed under LGPL. But, the project authors haven't included a copyright notice anywhere in the project. It turns out that the authors are not sure if this is required for an LGPL project[1]. From a Debian perspective, what is the recommendation regarding this? Do we require projects to include the copyright information along with LGPL? If the copyright *has* to be included, is it enough to include it in a COPYRIGHT file? I couldn't find an example of a project that does this. Most projects seem to include a copyright line along with a short form of LGPL in each file. (I think it may be more appealing to upstream authors if we don't have to include the copyright in every file). For example, libplacebo[2] is a library I found installed on my system that uses LGPL. This project does not have a common copyright file, but there are copyright notices in some source files[3]. While some other source files in this project do not have a copyright notice[4][5][6]. Note: my doubts are specifically regarding the LGPL license. For other licenses like BSD, I see both practices of including a COPYRIGHT file as well as a short copyright notice in each file, or a combination of the two. Thanks, Alan M Varghese [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065352 [1] https://github.com/hyprwm/hyprlang/issues/28 [2] https://code.videolan.org/videolan/libplacebo [3] https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dither.c? ref_ type=heads [4] https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dummy.c? ref_t ype=heads [5] https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c? ref_t ype=heads [6] https://code.videolan.org/videolan/libplacebo/-/blob/master/src/ colorspace.c? ref_type=heads
Re: Bug#1065078: Question about the debian group on Salsa
On Sunday, March 3, 2024 12:08:00 PM MST Loren M. Lang wrote: > > There is certainly nothing wrong with keeping your project under your own > > namespace, but if you would like to move it to the debian namespace, grant > > me > > full access to it (my Salsa username is soren) and I can then move it to the > > debian namespace and grant you full access to the project there. > > Thanks! I've granted you full access to > > https://salsa.debian.org/penguin359/tiv > > -Loren Done. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: FWD: Copyright in LGPL projects
Alan, These are good questions. 1. Yes, there must be a copyright statement. Only the person, people, group, or organization that holds the copyright can issue a license for other people to use the work. So, you must have someone claiming a copyright or they do not have the legal ability to release the work to others under the LGPL. 2. No, it is not required that each individual file contain a copyright statement or the header of the LGPL at the top. The FSF recommends such as a best practice, and I would agree that it is desirable, but it is not required. My recommendation would be that you communicate to the upstream project that they need to include the copyright and licensing information in the root of their repository, preferably all in one file, as a minimum requirement for you to be willing to package their project in Debian. Soren On Sunday, March 3, 2024 11:06:30 PM MST Alan M Varghese wrote: > Sent message incorrectly to debian-mentors-request instead of debian- mentors. > Correcting. > > > Forwarded Message > Subject: Copyright in LGPL projects > Date: Mon, 4 Mar 2024 11:10:58 +0530 > From: Alan M Varghese > To: 1065...@bugs.debian.org > CC: Matthias Geiger , SmartList > > > Hello Mentors, > > I have been working on packaging Hyprland window manager. > hyprlang[0] (with a 'g') is a new dependency for this project. This project > (hyprlang) is licensed under LGPL. > > But, the project authors haven't included a copyright notice anywhere in the > project. It turns out that the authors are not sure if this is required for > an LGPL project[1]. > > From a Debian perspective, what is the recommendation regarding this? Do we > require projects to include the copyright information along with LGPL? > > If the copyright *has* to be included, is it enough to include it in a > COPYRIGHT file? I couldn't find an example of a project that does this. Most > projects seem to include a copyright line along with a short form of LGPL in > each file. (I think it may be more appealing to upstream authors if we don't > have to include the copyright in every file). > > For example, libplacebo[2] is a library I found installed on my system that > uses LGPL. This project does not have a common copyright file, but there are > copyright notices in some source files[3]. While some other source files in > this project do not have a copyright notice[4][5][6]. > > Note: my doubts are specifically regarding the LGPL license. For other > licenses like BSD, I see both practices of including a COPYRIGHT file as well > as a short copyright notice in each file, or a combination of the two. > > Thanks, > Alan M Varghese > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065352 > [1] https://github.com/hyprwm/hyprlang/issues/28 > [2] https://code.videolan.org/videolan/libplacebo > [3] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dither.c? ref_ > type=heads [4] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/dummy.c? ref_t > ype=heads [5] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/cache.c? ref_t > ype=heads [6] > https://code.videolan.org/videolan/libplacebo/-/blob/master/src/ colorspace.c? > ref_type=heads -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#1065389: marked as done (RFS: python-click/8.1.7-1 [ITA] -- Wrapper around optparse for command line utilities - documentation)
Your message dated Mon, 4 Mar 2024 22:58:38 +0530 with message-id and subject line Close RFS bug for python-click has caused the Debian Bug report #1065389, regarding RFS: python-click/8.1.7-1 [ITA] -- Wrapper around optparse for command line utilities - documentation to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1065389: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065389 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-click": * Package name : python-click Version : 8.1.7-1 Upstream contact : cont...@palletsprojects.com * URL : https://github.com/pallets/click * License : BSD-3-clause * Vcs : https://salsa.debian.org/python-team/packages/python-click Section : python The source builds the following binary packages: python3-click - Wrapper around optparse for command line utilities - Python 3.x python-click-doc - Wrapper around optparse for command line utilities - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-click/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-click/python-click_8.1.7-1.dsc Changes since the last upload: python-click (8.1.7-1) unstable; urgency=medium . * New upstream version 8.1.7 * New Maintainer (Closes: #1065251) * d/control: - Change Maintainer name - Add python-click-doc in Suggests for python3-click * d/copyright: - Add new maintainer name in copyright stanza Regards, -- Akash Doppalapudi OpenPGP_0xBCBCAE31ECE05007.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Decided to close this RFS bug since I packaged python-click not knowing that someone else already submitted an ITA on the package. OpenPGP_0xBCBCAE31ECE05007.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#1065389: RFS: python-click/8.1.7-1 [ITA] -- Wrapper around optparse for command line utilities - documentation
Hi, Thank you for pointing this out. I had a discussion with Peter Pentchev off-list and we decided it would be better if I take it down from mentors so that Peter can package it from Python Team. I am deleting python-click package from mentors and closing the RFS bug. Thanks, Akash Doppalapudi On 3/4/24 07:32, Bo YU wrote: Hi! On Mon, Mar 4, 2024 at 1:51 AM Akash Doppalapudi wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-click": * Package name : python-click Version : 8.1.7-1 Upstream contact : cont...@palletsprojects.com * URL : https://github.com/pallets/click * License : BSD-3-clause * Vcs : https://salsa.debian.org/python-team/packages/python-click Section : python The source builds the following binary packages: python3-click - Wrapper around optparse for command line utilities - Python 3.x python-click-doc - Wrapper around optparse for command line utilities - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-click/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-click/python-click_8.1.7-1.dsc Changes since the last upload: python-click (8.1.7-1) unstable; urgency=medium . * New upstream version 8.1.7 * New Maintainer (Closes: #1065251) I would like to suggest you contact Peter Pentchev as he/she has reported ITA earlier than your ITA. And would you really want to maintain these packages without Debian Python Team? No other meaning, just considering these packages should be maintained under DPT sounds more reasonable. BR, Bo * d/control: - Change Maintainer name - Add python-click-doc in Suggests for python3-click * d/copyright: - Add new maintainer name in copyright stanza Regards, -- Akash Doppalapudi OpenPGP_0xBCBCAE31ECE05007.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "ocaml-linenoise": * Package name : ocaml-linenoise Version : 1.5-1 Upstream contact : Edgar Aroutiounian * URL : https://github.com/ocaml-community/ocaml-linenoise * License : BSD-2-Clause * Vcs : https://salsa.debian.org/vimerbf-guest/ocaml-linenoise Section : ocaml The source builds the following binary packages: liblinenoise-ocaml - Lightweight readline alternative with OCaml (runtime) liblinenoise-ocaml-dev - Lightweight readline alternative with OCaml (development) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ocaml-linenoise/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/o/ocaml-linenoise/ocaml-linenoise_1.5-1.dsc Changes for the initial release: ocaml-linenoise (1.5-1) UNRELEASED; urgency=low . * Initial release. (Closes: #1064586) -- Regards, -- Bo YU signature.asc Description: PGP signature
