Bug#1033096: ITP: python-sepaxml -- python library to generate SEP XML files
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, Debian Python Team , matthias.geiger1...@tutanota.de * Package name: python-sepaxml Version : 2.6.1 Upstream Contact: Raphael Michel * URL : https://github.com/raphaelm/python-sepaxml * License : MIT Programming Lang: Python Description : python library to generate SEP XML files I inted to package python-sepaxml. It is a dependency for banking (#1013317) and python-mt940 (#1024494). The packaging is already done and can be viewed at https://salsa.debian.org/python-team/packages/python-sepaxml. I intend to maintain this package within the debian python team. For the initial upload I'd need a sponsor. thanks, Matthias Geiger signature.asc Description: application/pgp-keys
Consultation on license documents
Hello, I have the following questions to consult and look forward to your authoritative answers. 1. Must various software packages in the Debian community contain a license file "license.txt"? Without this file, how does the users know about the license usage of the package? 2. I found that each software package has a "Copyleft" document, and a lot of license information is also listed in this document. Therefore, I would like to ask, when the two documents "license.txt" and "Copyleft" exist in the software package at the same time, which one should the user take as the basis, and how to deal with the situation where the declared license information of the two documents is inconsistent, Which shall prevail? 3. If the software package only contains "Copyleft" documents, can users refer to the license information declared in this document?
Bug#1033120: ITP: obs-color-monitor -- plugin for OBS Studio to monitor color balances
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-devel@lists.debian.org, Norihiro Kamae * Package name: obs-color-monitor Version : 0.4.4+git20230317.dda570c Upstream Contact: Norihiro Kamae * URL : https://obsproject.com/forum/resources/color-monitor.1277/ * License : GPL-2+ Programming Lang: C, C++ Description : plugin for OBS Studio to monitor color balances This plugin provides some sources to monitor color balances, like vectorscope, waveform, histogram, zebra and false color. These tools are useful especially for streaming with multiple cameras. Color conditions can be checked in real time and it is possible to adjust the color correction settings from these monitors. In addition, a dock widget to show sources is available.
Re: Consultation on license documents
On Fri, Mar 17, 2023 at 09:09:22PM +0800, 刘涛 wrote: > Hello, I have the following questions to consult and look forward to your > authoritative answers. > > 1. Must various software packages in the Debian community contain a > license file "license.txt"? Without this file, how does the users > know about the license usage of the package? Debian packages have licensing information in /usr/share/doc//copygright. There is not consensus in the global, upstream open source movement about where the licensing information should be found in the source distribution for a open source package. I will typically look at the COPYING file, and the README file, and I'd say that most of the time, I can find the licensing information there. However, we (the Debian community) do not have the authority to mandate a standard place for upstream software packages to place the licensing information. It is the responsibility of the Debian maintainer when they are packaging a software package for Debian to find the copyright and licensing information and then arrange to make sure that when the package is installed, the licensing information is installed in /usr/share/doc//copyright, and in the debian/copyright file in the Debian source package. There is a proposed standard being promulgated by the Linux foundation called SPDX[1], which has been standardized by the Internet Organization for Standardization (ISO), as ISO/IEC 5962:2021. This is a scheme for tagging source files, which is important because very often lincensing information is very often much more fine-grained that at the level of a single package. This is why the Debian copyright format[2], DEP-5, can also provide copyright information on a per-source-file basis. [1] https://spdx.dev/ [2] https://dep-team.pages.debian.net/deps/dep5/ For companies are interested in license compliance, they may find this particular article, "Open-Source License Compliance in Software Supply Chains"[3] useful. It was published in the book Towards Engineering Free/Libre Open Source Software (FLOSS) Ecosystems for Impact and Sustainability. [3] https://dirkriehle.com/publications/2017-selected/license-clearance-in-software-product-governance/ These days, there is a lot of work in people interested in Open Source supply chains who are now worrying about being able to track libraries used in products and companies' production code, not just from the perspective of copyright license compliance, but for security reasons as well. For example, at the 2022 Linux Foundation Member Summit[4], there were four sessions, including two keynotes, on this subject. Slides and Video for the keynote talks are available; slides are linked off of the sessions descriptions. The video of the keynotes are available here[5]. [4] https://events.linuxfoundation.org/archive/2022/lf-member-summit/program/schedule/ [5] https://www.youtube.com/watch?v=BltvpGfqz14 > 2. I found that each software package has a "Copyleft" document, and > a lot of license information is also listed in this > document. Therefore, I would like to ask, when the two documents > "license.txt" and "Copyleft" exist in the software package at the > same time, which one should the user take as the basis, and how to > deal with the situation where the declared license information of > the two documents is inconsistent, Which shall prevail? I am not a lawyer, and even if I were a lawyer, I am not *your* lawyer, so I am not in a position to give legal advice. If you want an authoratative opinion, you will need to find a lawyer who is willing to give you formal legal advice, and they will very ask to be paid in order to give you that opinion. Best regards, - Ted
Re: An email address for drive-by bug reports?
> On 2023-03-01 16:30:01 +0100, Sam Hartman wrote: > Honestly, if there is not currently a submitter behind a bug---someone > who cares about it and is willing to look into requests for more > information or to help confirm a fix---I'm not particularly interested > in working on such a bug. We’re all volunteers here. If someone doesn’t want to work on a particular issue, they’re IMO at full liberty to not do any such work. (There are exceptions, but ultimately, it boils down to whether the person does or doesn’t want to put effort into a particular issue / package / etc., possibly to the detriment of their other commitments.) > To me, that's often a sign the bug should be closed until someone > comes along who cares about the issue enough to interact with it. > There are exceptions. > So I'd be fine with a nosubmitter command or similar, but also with > the understanding that it's entirely reasonable for maintainers > to close nosubmitter bugs as wontfix-until-some-specific-person-cares. > Socially and culturally I do want to emphasize the idea that if you > aren't willing (any more) to put energy behind your problem report, > it's entirely fine if no one is going to put energy behind fixing it. > Having a bunch of problem reports that no one is interested in > cluttering up package pages has a cost. Just for the same reasons > you don't want these reports cluttering up your bugs from page, > I perhaps don't want them cluttering up my bugs on my package > pages if you no longer care. My long-time opinion is that so long as the bug is reproducible, and does affect Debian users, it’s ought to be in the BTS, open. The maintainer(s) can of course indicate their lack of desire to invest effort into solving the issue via the wontfix tag; no opposition to that. For an example, I’ve once spent hours trying to determine the cause of a particular problem I was having. Turns out tinysshd(8) from Bullseye has an interoperability issue with openssh-client from the same. It would’ve likely helped me if #1006801 were listed on http://bugs.debian.org/src:tinysshd . (I’m not entirely sure as to /why/ it got archived, TBH: it’s found in 20190101-1, which is still in the archive, and fixed in 20220305-1; as such, I’d expect it to remain open until Bullseye itself is archived.) The problem with the logic quoted above is that a bug that the original submitter isn’t interested in can still be affecting those who use Debian now; and, unless fixed, can still affect those who will use Debian at some later point. The absence of a /record/ of a person interested in the issue is not the same as the absence of such a /person/ themselves. Personally, I find Debian BTS to be a valuable source of what issues there /are./ On occasion, I’d choose between two packages based on what bugs are filed for each. Othertimes, I’ll find workarounds there. Or I might find why a particular issue is infeasible to fix in a given package, and start searching for another option for the task at hand. It’d be sad to see Debian BTS devolve into a bunch of maintainers’ personal TODO lists. -- FSF associate member #7257 http://am-1.org/~ivan/
