Bug#1031761: ITP: hipfort -- Fortran bindings for ROCm and HIP libraries

[Cordell Bloor]

Package: wnpp
Severity: wishlist
Owner: Cordell Bloor 
X-Debbugs-Cc: debian-devel@lists.debian.org, c...@slerp.xyz, 
debian...@lists.debian.org

* Package name: hipfort
  Version : 5.4.3
  Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/ROCmSoftwarePlatform/hipfort
* License : Expat
  Programming Lang: Fortran
  Description : Fortran bindings for ROCm and HIP libraries

 hipfort is a library that provides Fortran bindings the ROCm and HIP
 libraries, as well as tooling to help write portable code targeting both
 AMD and NVIDIA GPUs.
 .
 hipfort provides Fortran 2003 and Fortran 2008 bindings for the HIP
 runtime, rocBLAS, hipBLAS, rocSPARSE, hipSPARSE, rocFFT, hipFFT,
 rocRAND, hipRAND, rocSOLVER, and hipSOLVER. Additionally, it provides
 the hipfc compiler wrapper and a Makefile to support a set of standard
 flags and environment variables for building portable Fortran programs
 that use GPU compute.

Fortran remains a popular language for high-performance computing and
bindings for GPU math libraries are useful to enable Fortran users to
more fully utilize modern computing hardware.

This package is part of the AMD ROCm stack and would be maintained by
the Debian ROCm Team.

debian support veeam

[Nijam Deen]

debain os will support for veeam backup using network storage

regards,
nijamudeen

Yearless copyrights: what do people think?

[Peter Pentchev]

Hi,

So I've seen this idea floating around in the past couple of years
(and in some places even earlier), but I started doing it for
the couple of pieces of software that I am upstream for after reading
Daniel Stenberg's blog entry:
  https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/

And then, a couple of weeks ago, I quietly checked whether
the Debian FTP team would be okay with that by uploading two NEW
packages without any years mentioned in the debian/copyright file:
either upstream or for my Debian packaging. And, lo and behold,
they were both accepted (python-parse-stages and python-test-stages).

So how do people feel about this in general, would it be okay for
me to start doing it:
a) for other packages that I maintain personally, outside any team
b) for team-maintained packages (I guess this one might be a per-team
   decision, discussed separately on the appropriate lists)

(obviously, I'm not asking for permission or anything; apparently
 at least one member of the FTP team is okay with me doing it at
 least for some packages. This is more of a "float the idea, see
 what people think about doing this more widely, not just me")

Thanks for reading this far, and keep up the great work!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1031769: ITP: oauth2-oidc-sdk -- OAuth 2.0 SDK for Java

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-devel@lists.debian.org, j...@nahmias.net, 
debian-j...@lists.debian.org, supp...@connect2id.com, v...@connect2id.com

* Package name: oauth2-oidc-sdk
  Version : 9.43.1
  Upstream Author : Connect2id Ltd 
  Upstream Author : Vladimir Dzhuvinov 
* URL : 
https://connect2id.com/products/nimbus-oauth-openid-connect-sdk
* URL : 
https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/master/
* License : Apache-2
  Programming Lang: Java
  Description : OAuth 2.0 SDK for Java


This library is your starting point for developing OAuth 2.0 / 2.1 and OpenID 
Connect applications in Java. It provides ready and simple to use classes for 
dealing with tokens and representing the protocol messages, ensuring standards 
compliance and thus interoperability.

 *  Comprehensive Java library for developing OAuth 2.0 and OpenID Connect 
clients and servers
 *  Standards compliant, robust and extensible
 *  Open source (Apache 2.0 licence)

The OAuth 2.0 and OpenID Connect standards permit application-specific profiles 
and extensions, and this library also caters for that, with suitable interfaces 
and base classes where required.

Re: Yearless copyrights: what do people think?

[Jonas Smedegaard]

Quoting Peter Pentchev (2023-02-22 10:49:30)
> So I've seen this idea floating around in the past couple of years
> (and in some places even earlier), but I started doing it for
> the couple of pieces of software that I am upstream for after reading
> Daniel Stenberg's blog entry:
>   https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
> 
> And then, a couple of weeks ago, I quietly checked whether
> the Debian FTP team would be okay with that by uploading two NEW
> packages without any years mentioned in the debian/copyright file:
> either upstream or for my Debian packaging. And, lo and behold,
> they were both accepted (python-parse-stages and python-test-stages).
> 
> So how do people feel about this in general, would it be okay for
> me to start doing it:
> a) for other packages that I maintain personally, outside any team
> b) for team-maintained packages (I guess this one might be a per-team
>decision, discussed separately on the appropriate lists)
> 
> (obviously, I'm not asking for permission or anything; apparently
>  at least one member of the FTP team is okay with me doing it at
>  least for some packages. This is more of a "float the idea, see
>  what people think about doing this more widely, not just me")

Copyright statements are legally optional (for all juristiction
acknowledging the Bern-convention - which USA does since 1989 and
western european countries did since many years prior).

Reason authors include copyright statements anyway is, as I see it, as a
courtesy for others - i.e. signal who claims ownership in the work.

As an author, you are free to not say anything (which means anyone
wanting e.g. change or redistribute the work will have a hard time
validating if some licensing statement granting such permission is
legally valid, because only rights holders can grant others rights.

Makes sense to me that ftpmaster approves redistribution of works where
the author reveal who claims copyright but omits *when* that copyright
apply: The copyright year is useful to know when a copyright expire and
the work enters the public domain, but since Debian redistribution
already require free licensing which is sufficient even beyond eventual
expiration of copyright.  It is not ideal, however, because our users
might want to e.g. avoid copyleft licensing, and for those it would be
helpful to know at which point in time a certain work would get released
into the public domain and thereby allow more liberal use.

As a redistributor I find it a good practice to include most possible
copyright and licensing information provided by upstream authors,
exactly because we are doing a service for our users, and it is a slight
disservice to omit information that upstream put effort into tracking
and publishing.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Re: Yearless copyrights: what do people think?

[Marco d'Itri]

On Feb 22, Peter Pentchev  wrote:

> So I've seen this idea floating around in the past couple of years
> (and in some places even earlier), but I started doing it for
> the couple of pieces of software that I am upstream for after reading
> Daniel Stenberg's blog entry:
>   https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
Good idea, I planned to do it myself too in the future.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Yearless copyrights: what do people think?

[Peter Pentchev]

On Wed, Feb 22, 2023 at 01:55:02PM +0100, Jonas Smedegaard wrote:
> Quoting Peter Pentchev (2023-02-22 10:49:30)
> > So I've seen this idea floating around in the past couple of years
> > (and in some places even earlier), but I started doing it for
> > the couple of pieces of software that I am upstream for after reading
> > Daniel Stenberg's blog entry:
> >   https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
> > 
> > And then, a couple of weeks ago, I quietly checked whether
> > the Debian FTP team would be okay with that by uploading two NEW
> > packages without any years mentioned in the debian/copyright file:
> > either upstream or for my Debian packaging. And, lo and behold,
> > they were both accepted (python-parse-stages and python-test-stages).
> > 
> > So how do people feel about this in general, would it be okay for
> > me to start doing it:
> > a) for other packages that I maintain personally, outside any team
> > b) for team-maintained packages (I guess this one might be a per-team
> >decision, discussed separately on the appropriate lists)
> > 
> > (obviously, I'm not asking for permission or anything; apparently
> >  at least one member of the FTP team is okay with me doing it at
> >  least for some packages. This is more of a "float the idea, see
> >  what people think about doing this more widely, not just me")
[snip useful information]
> As a redistributor I find it a good practice to include most possible
> copyright and licensing information provided by upstream authors,
> exactly because we are doing a service for our users, and it is a slight
> disservice to omit information that upstream put effort into tracking
> and publishing.

Wait, I may have been unclear. I did not mean that I want to omit
the upstream copyright years *when they are there*. And, of course,
if upstream does not specify any copyright years, we cannot invent
any out of thin air. So I guess my question was mainly what people
think about dropping the years in the debian/* copyright notice
(packaging files, patches, etc).

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Yearless copyrights: what do people think?

[Daniel Baumann]

On 2/22/23 13:55, Jonas Smedegaard wrote:
> As a redistributor I find it a good practice to include most possible
> copyright and licensing information provided by upstream authors,
> exactly because we are doing a service for our users

while having copyright information centrally available per package in
d/copyright is definitly a usefull service, is providing the *years*
really a service worth providing?

personally I don't think so: for packages with non-trivial d/copyright,
it's a significant effort to keep the years in sync with the upstream
sources.

(and I doubt that all our source packages have accurate d/copyright,
even less so when it comes to the year-information.)

> and it is a slight disservice to omit information that upstream put effort 
> into tracking
> and publishing.

If years would be omited in d/copyright, it's not that the information
is hidden/nowhere else.

Also if I would want to know the copyright information of a certain
file, I'd check d/copyright for a first glance, but then always check
the individual source file, even if it's just to be sure/double check.

I don't think that the "niche" use-case of wanting to know the
year-information (everything else should be in d/copyright anyway) is
worth the (continued) maintenance costs in d/copyright.

Regards,
Daniel

Re: Yearless copyrights: what do people think?

[Daniel Baumann]

On 2/22/23 14:26, Peter Pentchev wrote:
> Wait, I may have been unclear. I did not mean that I want to omit
> the upstream copyright years *when they are there*.

I know you didn't mean that, nevertheless, it's imho good idea. I'd be
in favour of dropping them from d/copyright an let people have a look at
the "full sources" for the "year detail"-information.

I recently saw that this has been done in knot-resolver for the
"wildcard"-stanza of d/copyright and I like it:
https://tracker.debian.org/media/packages/k/knot-resolver/copyright-5.6.0-1

Regards,
Daniel

Re: Yearless copyrights: what do people think?

[Stephan Verbücheln]

It is also not required to put an author name or any other information,
either. Copyright will still apply.

But it makes it really a lot easier for anyone who wants to re-use the
work or parts of it if they know who to contact. This matters even more
for computer programs than for fiction novels or paintings.

Regards

Re: Yearless copyrights: what do people think?

[Scott Kitterman]

On February 22, 2023 9:49:30 AM UTC, Peter Pentchev  wrote:
>Hi,
>
>So I've seen this idea floating around in the past couple of years
>(and in some places even earlier), but I started doing it for
>the couple of pieces of software that I am upstream for after reading
>Daniel Stenberg's blog entry:
>  https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
>
>And then, a couple of weeks ago, I quietly checked whether
>the Debian FTP team would be okay with that by uploading two NEW
>packages without any years mentioned in the debian/copyright file:
>either upstream or for my Debian packaging. And, lo and behold,
>they were both accepted (python-parse-stages and python-test-stages).
>
>So how do people feel about this in general, would it be okay for
>me to start doing it:
>a) for other packages that I maintain personally, outside any team
>b) for team-maintained packages (I guess this one might be a per-team
>   decision, discussed separately on the appropriate lists)
>
>(obviously, I'm not asking for permission or anything; apparently
> at least one member of the FTP team is okay with me doing it at
> least for some packages. This is more of a "float the idea, see
> what people think about doing this more widely, not just me")
>
>Thanks for reading this far, and keep up the great work!

You may be conflating two separate things here.  The job of debian/copyright is 
to document the copyright and license claims.  Although there are exceptional 
cases, FTP Team doesn't normally review the correctness of the claims (an 
example of an exception is a copyright claim that includes the source that the 
code was copied from before the copyright claim was changed - yes, this 
happens).  I don't think you should assume acceptance of a package without 
years implies any particular judgement about if the practice is good or bad.

Scott K
P.S. Please don't turn this into yet another thread about how annoying having 
to spend time on debian/copyright is.  We know.

Re: Yearless copyrights: what do people think?

[Jonas Smedegaard]

Quoting Peter Pentchev (2023-02-22 14:26:47)
> On Wed, Feb 22, 2023 at 01:55:02PM +0100, Jonas Smedegaard wrote:
> > Quoting Peter Pentchev (2023-02-22 10:49:30)
> > > So I've seen this idea floating around in the past couple of years
> > > (and in some places even earlier), but I started doing it for
> > > the couple of pieces of software that I am upstream for after reading
> > > Daniel Stenberg's blog entry:
> > >   https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
> > > 
> > > And then, a couple of weeks ago, I quietly checked whether
> > > the Debian FTP team would be okay with that by uploading two NEW
> > > packages without any years mentioned in the debian/copyright file:
> > > either upstream or for my Debian packaging. And, lo and behold,
> > > they were both accepted (python-parse-stages and python-test-stages).
> > > 
> > > So how do people feel about this in general, would it be okay for
> > > me to start doing it:
> > > a) for other packages that I maintain personally, outside any team
> > > b) for team-maintained packages (I guess this one might be a per-team
> > >decision, discussed separately on the appropriate lists)
> > > 
> > > (obviously, I'm not asking for permission or anything; apparently
> > >  at least one member of the FTP team is okay with me doing it at
> > >  least for some packages. This is more of a "float the idea, see
> > >  what people think about doing this more widely, not just me")
> [snip useful information]
> > As a redistributor I find it a good practice to include most possible
> > copyright and licensing information provided by upstream authors,
> > exactly because we are doing a service for our users, and it is a slight
> > disservice to omit information that upstream put effort into tracking
> > and publishing.
> 
> Wait, I may have been unclear. I did not mean that I want to omit
> the upstream copyright years *when they are there*. And, of course,
> if upstream does not specify any copyright years, we cannot invent
> any out of thin air. So I guess my question was mainly what people
> think about dropping the years in the debian/* copyright notice
> (packaging files, patches, etc).

Your rephrased question seems the same to me - so perhaps I was
unclear...

It is my inderstanding that when copyright years are missing from
upstream source then that is acceptable for Debian redistribution (i.e.
not a surprise to me that ftpmaster approves it).

It is my opinion that when copyright years do exist in upstream source,
then we should list those known-to-us years in debian/copyright (a.k.a.
not omit them a.k.a. not drop them), even though we are legally not
required¹ to do so (for the same reason as upstream above is not legally
required to state copyright at all).

 - Jonas

¹ Unless some licensing requires listing copyright *years* which from
the top of my head I do not recall having seen, but am too lazy to check
- also because my interest is not to cut corners most possible but to be
as helpful to our users as possible, and copyright years serve a real
(albeit cornercase) purpose.

-- 
* Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Yearless copyrights: what do people think?

[Sam Hartman]

> "Peter" == Peter Pentchev  writes:

Peter> Hi, So I've seen this idea floating around in the past couple
Peter> of years (and in some places even earlier), but I started
Peter> doing it for the couple of pieces of software that I am
Peter> upstream for after reading Daniel Stenberg's blog entry:
Peter> https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/

Peter> And then, a couple of weeks ago, I quietly checked whether
Peter> the Debian FTP team would be okay with that by uploading two
Peter> NEW packages without any years mentioned in the
Peter> debian/copyright file: either upstream or for my Debian

As Jonas mentions, including the years allows people to know when works
enter the public domain and the license becomes more liberal.
I think our users are better served by knowing when the Debian packaging
would enter the public domain.

--Sam

Re: Yearless copyrights: what do people think?

[Jonas Smedegaard]

Quoting Daniel Baumann (2023-02-22 14:30:11)
> On 2/22/23 13:55, Jonas Smedegaard wrote:
> > As a redistributor I find it a good practice to include most possible
> > copyright and licensing information provided by upstream authors,
> > exactly because we are doing a service for our users
> 
> while having copyright information centrally available per package in
> d/copyright is definitly a usefull service, is providing the *years*
> really a service worth providing?
> 
> personally I don't think so: for packages with non-trivial d/copyright,
> it's a significant effort to keep the years in sync with the upstream
> sources.

Ensuring that debian/copyright stays correct take some effort, but that
is required to re-examine anyway for each new upstream release.

I dare question that examining copyright *years* in particular is
noticably larger effort than the general required examination.

> (and I doubt that all our source packages have accurate d/copyright,
> even less so when it comes to the year-information.)

I agree, but is not really relevant for this discussion (which I guess
is also the reason you put that in paranthesis). :-)


> > and it is a slight disservice to omit information that upstream put
> > effort into tracking and publishing.
> 
> If years would be omited in d/copyright, it's not that the information
> is hidden/nowhere else.
> 
> Also if I would want to know the copyright information of a certain
> file, I'd check d/copyright for a first glance, but then always check
> the individual source file, even if it's just to be sure/double check.
> 
> I don't think that the "niche" use-case of wanting to know the
> year-information (everything else should be in d/copyright anyway) is
> worth the (continued) maintenance costs in d/copyright.

I am genuinely interested in understanding what trouble you experience
collecting that information.  Is it perhaps because you for some reason
cannot or will not use licensecheck?  While ertainly not perfect but,
licensecheck in my experience currently adequately identifies, collects,
and merges copyright years.

If you prefer moving such conversation to a smaller audience, then I
encourage filing bugreports against licensecheck (or pointing at
bugreports already covering your points that I might have missed).

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Yearless copyrights: what do people think?

[Scott Kitterman]

On February 22, 2023 2:29:08 PM UTC, Jonas Smedegaard  wrote:
>Quoting Peter Pentchev (2023-02-22 14:26:47)
>> On Wed, Feb 22, 2023 at 01:55:02PM +0100, Jonas Smedegaard wrote:
>> > Quoting Peter Pentchev (2023-02-22 10:49:30)
>> > > So I've seen this idea floating around in the past couple of years
>> > > (and in some places even earlier), but I started doing it for
>> > > the couple of pieces of software that I am upstream for after reading
>> > > Daniel Stenberg's blog entry:
>> > >   https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
>> > > 
>> > > And then, a couple of weeks ago, I quietly checked whether
>> > > the Debian FTP team would be okay with that by uploading two NEW
>> > > packages without any years mentioned in the debian/copyright file:
>> > > either upstream or for my Debian packaging. And, lo and behold,
>> > > they were both accepted (python-parse-stages and python-test-stages).
>> > > 
>> > > So how do people feel about this in general, would it be okay for
>> > > me to start doing it:
>> > > a) for other packages that I maintain personally, outside any team
>> > > b) for team-maintained packages (I guess this one might be a per-team
>> > >decision, discussed separately on the appropriate lists)
>> > > 
>> > > (obviously, I'm not asking for permission or anything; apparently
>> > >  at least one member of the FTP team is okay with me doing it at
>> > >  least for some packages. This is more of a "float the idea, see
>> > >  what people think about doing this more widely, not just me")
>> [snip useful information]
>> > As a redistributor I find it a good practice to include most possible
>> > copyright and licensing information provided by upstream authors,
>> > exactly because we are doing a service for our users, and it is a slight
>> > disservice to omit information that upstream put effort into tracking
>> > and publishing.
>> 
>> Wait, I may have been unclear. I did not mean that I want to omit
>> the upstream copyright years *when they are there*. And, of course,
>> if upstream does not specify any copyright years, we cannot invent
>> any out of thin air. So I guess my question was mainly what people
>> think about dropping the years in the debian/* copyright notice
>> (packaging files, patches, etc).
>
>Your rephrased question seems the same to me - so perhaps I was
>unclear...
>
>It is my inderstanding that when copyright years are missing from
>upstream source then that is acceptable for Debian redistribution (i.e.
>not a surprise to me that ftpmaster approves it).
>
>It is my opinion that when copyright years do exist in upstream source,
>then we should list those known-to-us years in debian/copyright (a.k.a.
>not omit them a.k.a. not drop them), even though we are legally not
>required¹ to do so (for the same reason as upstream above is not legally
>required to state copyright at all).
>
> - Jonas
>
>¹ Unless some licensing requires listing copyright *years* which from
>the top of my head I do not recall having seen, but am too lazy to check
>- also because my interest is not to cut corners most possible but to be
>as helpful to our users as possible, and copyright years serve a real
>(albeit cornercase) purpose.

You won't encounter it in license texts this way.  Many licenses require 
complete/verbatim inclusion of the copyright claims.  If you remove the years, 
you aren't doing that.

Scott K

Re: Yearless copyrights: what do people think?

[Marc Haber]

On Wed, 22 Feb 2023 15:40:49 +0100, Jonas Smedegaard 
wrote:
>Quoting Daniel Baumann (2023-02-22 14:30:11)
>> while having copyright information centrally available per package in
>> d/copyright is definitly a usefull service, is providing the *years*
>> really a service worth providing?
>> 
>> personally I don't think so: for packages with non-trivial d/copyright,
>> it's a significant effort to keep the years in sync with the upstream
>> sources.
>
>Ensuring that debian/copyright stays correct take some effort, but that
>is required to re-examine anyway for each new upstream release.
>
>I dare question that examining copyright *years* in particular is
>noticably larger effort than the general required examination.

If copyright inspection is like three quarters of the effort necessary
to get, for example, a new sudo into Debian, then we are doing things
wrong and setting our priorities wrong. This is indrecibly frustrating
and time consuming busy work that doesn't require my qualification at
all, and I REALLY have other things to do than that.

It is especially frustrating when we're obviously being holier than
the pope, when for example translators submit translations for very
obviously non-FSF software with "Copyright Free Software Foundation"
or with boilerplate copypaste headers stating a license that is
totally different from the package that is being translated etc.

Strictly, as a maintainer I MUST reject such translations because a po
file also contains work by the original author which a translator
cannot arbitrarily relicense, not even accidentally by just not paying
proper attention.

>> (and I doubt that all our source packages have accurate d/copyright,
>> even less so when it comes to the year-information.)

Amen.

While I understand that having debian/copyright is vitally important,
we NEED to relax our rules to reduce the effort necessary since it's
demotivating busy work that I feel noone cares about.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Yearless copyrights: what do people think?

[Jérémy Lal]

Le mer. 22 févr. 2023 à 15:39, Sam Hartman  a écrit :

> > "Peter" == Peter Pentchev  writes:
>
> Peter> Hi, So I've seen this idea floating around in the past couple
> Peter> of years (and in some places even earlier), but I started
> Peter> doing it for the couple of pieces of software that I am
> Peter> upstream for after reading Daniel Stenberg's blog entry:
> Peter> https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
>
> Peter> And then, a couple of weeks ago, I quietly checked whether
> Peter> the Debian FTP team would be okay with that by uploading two
> Peter> NEW packages without any years mentioned in the
> Peter> debian/copyright file: either upstream or for my Debian
>
> As Jonas mentions, including the years allows people to know when works
> enter the public domain and the license becomes more liberal.
> I think our users are better served by knowing when the Debian packaging
> would enter the public domain.
>

Maybe only the first year the copyright was applied is important ?

Jérémy

Re: Yearless copyrights: what do people think?

[Russ Allbery]

Daniel Baumann  writes:
> On 2/22/23 14:26, Peter Pentchev wrote:

>> Wait, I may have been unclear. I did not mean that I want to omit the
>> upstream copyright years *when they are there*.

> I know you didn't mean that, nevertheless, it's imho good idea.

Unfortunately, it's often against the upstream license.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
   notice, this list of conditions and the following disclaimer.

and:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

The Apache 2.0 license only requires the copyright notices be preserved in
"Source form," so debian/copyright probably doesn't count.  (It instead
requires inclusion of the NOTICE file, but allows you to distribute it
"within the Source form or documentation, if provided along with the
Derivative Works," which we probably qualify for.)

The GPL doesn't seem to care about the notice in non-source forms.

In practice, I doubt anyone will care, and it's of course fine to omit the
year from your own copyright notices as long as you realize that means you
cannot take advantage of the damage provisions of US copyright law that
require you to publish a valid copyright notice (which I suspect no one
cares about).  But dropping the copyright dates from the upstream notices
I think would often technically violate the upstream license depending on
its wording.

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Scarlett Moore]

On 2/21/23 15:03, Ryan Kavanagh wrote:

On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:

   Description : A tool for glamourous shell scripts

A tool for glamorous shell scripts. Leverage the power of Bubbles and
Lip Gloss in your scripts and aliases without writing any Go code!

This long description does not provide users with enough information to
understand what the package does. What are "Bubbles" and "Lip Gloss" in
a shell script? What is a "glamourous shell script"?

It would be helpful if the package's long description satisfied §3.4.2
of the Debian Policy Manual [0]:

 The description field needs to make sense to anyone, even people who
 have no idea about any of the things the package deals with. [3]

 [...]

 [3] The blurb that comes with a program in its announcements and/or
 README files is rarely suitable for use in a description. It is
 usually aimed at people who are already in the community where the
 package is used.

Best wishes,
Ryan

[0] 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description



The package description will be this or close to it:


 A tool for glamorous shell scripts. Leverage the power of Bubbles
 (https://github.com/charmbracelet/bubbles) and Lip Gloss
 (https://github.com/charmbracelet/lipgloss) in your scripts and aliases
 without writing any Go code!
 .
 Tutorial
 .
 Gum provides highly configurable, ready-to-use utilities to help you write
 useful shell scripts and dotfiles aliases with just a few lines of code.
 .
 Let's build a simple script to help you write Conventional Commits
 (https://www.conventionalcommits.org/en/v1.0.0/#summary) for your
 dotfiles.
 .
 Start with a #!/bin/sh.
 .
   #!/bin/sh
 .
 Ask for the commit type with gum choose:
 .
   gum choose "fix" "feat" "docs" "style" "refactor" "test" "chore"
 "revert"
 .
  | Tip: this command itself will print to stdout which is not all that
  | useful.
  | To make use of the command later on you can save the stdout to a
  | $VARIABLE or
  | file.txt.
 .
 Prompt for an (optional) scope for the commit:
 .
   gum input --placeholder "scope"
 .
 Prompt for a commit message:
 .
   gum input --placeholder "Summary of this change"
 .
 Prompt for a detailed (multi-line) explanation of the changes:
 .
   gum write --placeholder "Details of this change (CTRL+D to finish)"
 .
 Prompt for a confirmation before committing:
 .
  | gum confirm exits with status 0 if confirmed and status 1 if
 cancelled.
 .
   gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m
 "$DESCRIPTION"
 .
 Putting it all together...
 .
   #!/bin/sh
   TYPE=$(gum choose "fix" "feat" "docs" "style" "refactor" "test"
 "chore" "revert")
   SCOPE=$(gum input --placeholder "scope")
 .
   # Since the scope is optional, wrap it in parentheses if it has a
 value.
   test -n "$SCOPE" && SCOPE="($SCOPE)"
 .
   # Pre-populate the input with the type(scope): so that the user may
 change it
   SUMMARY=$(gum input --value "$TYPE$SCOPE: " --placeholder "Summary 
of this

 change")
   DESCRIPTION=$(gum write --placeholder "Details of this change (CTRL+D to
 finish)")
 .
   # Commit these changes
   gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m
 "$DESCRIPTION"
 .
 Customization
 .
 gum is designed to be embedded in scripts and supports all sorts of use
 cases. Components are configurable and customizable to fit your theme
 and use case.
 .
 You can customize with --flags. See gum  --help for a full 
view of

 each command's customization and configuration options.
 .
 For example, let's use an input and change the cursor color, prompt
 color, prompt indicator, placeholder text, width, and pre-populate the
 value:
 .
   gum input --cursor.foreground "#FF0" --prompt.foreground "#0FF" 
--prompt "*

 " \
   --placeholder "What's up?" --width 80 --value "Not much, hby?"
 .
 You can also use ENVIRONMENT_VARIABLES to customize gum by default, this
 is useful to keep a consistent theme for all your gum commands.
 .
   export GUM_INPUT_CURSOR_FOREGROUND="#FF0"
   export GUM_INPUT_PROMPT_FOREGROUND="#0FF"
   export GUM_INPUT_PLACEHOLDER="What's up?"
   export GUM_INPUT_PROMPT="* "
   export GUM_INPUT_WIDTH=80
 .
   # Uses values configured through environment variables above but can
 still be
   # overridden with flags.
   gum input
 .
 Input
 .
 Prompt for input with a simple command.
 .
   gum input > answer.txt
 .
 Prompt for sensitive input with the --password flag.
 .
   gum input --password > password.txt
 .
 Write
 .
 Prompt for some multi-line text.
 .
 Note: CTRL+D and esc are used to complete text entry. CTRL+C will
 cancel.
 .
   gum write > story.txt
 .
 Filter
 .
 Use fuzzy matching to filter a list of values:
 .
   echo Strawberry >> flavors.txt
   echo Banana >> flavors.txt
   echo Cherry >> flavors.txt
   cat flavors.txt | gum filter > selection.txt
 .
 .
 You can also select multiple items with the --limit flag, which determines
 the maximum number of it

Re: Yearless copyrights: what do people think?

[Peter Pentchev]

On Wed, Feb 22, 2023 at 03:26:47PM +0200, Peter Pentchev wrote:
> On Wed, Feb 22, 2023 at 01:55:02PM +0100, Jonas Smedegaard wrote:
> > Quoting Peter Pentchev (2023-02-22 10:49:30)
> > > So I've seen this idea floating around in the past couple of years
> > > (and in some places even earlier), but I started doing it for
> > > the couple of pieces of software that I am upstream for after reading
> > > Daniel Stenberg's blog entry:
> > >   https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
[snip my original message]
> [snip useful information]
> > As a redistributor I find it a good practice to include most possible
> > copyright and licensing information provided by upstream authors,
> > exactly because we are doing a service for our users, and it is a slight
> > disservice to omit information that upstream put effort into tracking
> > and publishing.
> 
> Wait, I may have been unclear. I did not mean that I want to omit
> the upstream copyright years *when they are there*. And, of course,
> if upstream does not specify any copyright years, we cannot invent
> any out of thin air. So I guess my question was mainly what people
> think about dropping the years in the debian/* copyright notice
> (packaging files, patches, etc).

OK, so it seems I did it again: I sent out my original message before
really knowing myself what exactly the questions are that I mean
to ask :) So now that I have thought about it a little, here they are:

1. Does the Debian Project consider it okay for an upstream package to
   include one or more (or all) files with clear license grants (either
   included or referred to in the files), and with clear copyright
   notices (again, either in the files or in a central file) that
   contain the authors' names, but no years? Does such a package
   comply with the DFSG? I believe the answer ought to be "yes", but
   I thought it wouldn't hurt to ask.

2. If an upstream project does that, the debian/copyright file should
   reflect that and have a `Files: *` (or whatever pattern) notice that
   has a copyright notice without any years... right? And if an upstream
   project does that between releases, the debian/copyright file should
   change (drop the years) in the next "new upstream release" upload...
   right?

3. Now, what about the `Files: debian/*` section of the debian/copyright
   file? The common wisdom seems to be that, if only to make it easier to
   submit patches to the upstream project, the debian/* files ought to be
   licensed under the same terms as the upstream source. Now I know that
   licensing and copyright are different things :) So would the Debian
   Project consider it okay for a Debian package to have
   a `Files: debian/*` section in its copyright file that does not
   mention any years? This question is both from a DFSG point of view and
   from a "what would be best for our users" one. And does the answer
   depend on whether the upstream project's copyright notices include
   years or not? (as in, should we follow upstream's lead in that, too)

Note that none of that comes from any "it's so difficult" positions;
I am actually one of the people who would include file-by-file stanzas
in the debian/copyright files for upstream files with different
copyright years :)

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Antonio Terceiro]

On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
> 
> On 2/21/23 15:03, Ryan Kavanagh wrote:
> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
> > >Description : A tool for glamourous shell scripts
> > > 
> > > A tool for glamorous shell scripts. Leverage the power of Bubbles and
> > > Lip Gloss in your scripts and aliases without writing any Go code!
> > This long description does not provide users with enough information to
> > understand what the package does. What are "Bubbles" and "Lip Gloss" in
> > a shell script? What is a "glamourous shell script"?
> > 
> > It would be helpful if the package's long description satisfied §3.4.2
> > of the Debian Policy Manual [0]:
> > 
> >  The description field needs to make sense to anyone, even people who
> >  have no idea about any of the things the package deals with. [3]
> > 
> >  [...]
> > 
> >  [3] The blurb that comes with a program in its announcements and/or
> >  README files is rarely suitable for use in a description. It is
> >  usually aimed at people who are already in the community where the
> >  package is used.
> > 
> > Best wishes,
> > Ryan
> > 
> > [0] 
> > https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
> > 
> 
> The package description will be this or close to it:

That is just too long, please don't.

>  A tool for glamorous shell scripts. Leverage the power of Bubbles
>  (https://github.com/charmbracelet/bubbles) and Lip Gloss
>  (https://github.com/charmbracelet/lipgloss) in your scripts and aliases
>  without writing any Go code!
>  .
>  Tutorial
>  .
>  Gum provides highly configurable, ready-to-use utilities to help you write
>  useful shell scripts and dotfiles aliases with just a few lines of code.

This last paragraph above looks like a good enough package description.
Save everything else for an upstream README installed on
/usr/share/doc/gum/, or some other type of documentation.

https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions


signature.asc
Description: PGP signature

Re: Yearless copyrights: what do people think?

[Russ Allbery]

Not an ftp team member or anything, so this is just my personal opinion.

Peter Pentchev  writes:

> 1. Does the Debian Project consider it okay for an upstream package to
>include one or more (or all) files with clear license grants (either
>included or referred to in the files), and with clear copyright
>notices (again, either in the files or in a central file) that
>contain the authors' names, but no years? Does such a package
>comply with the DFSG? I believe the answer ought to be "yes", but
>I thought it wouldn't hurt to ask.

Yes, I can't see any reason why this would be a problem.  Copyright
notices are optional.  I suppose it's conceivable someone could put
wording in a license that requires the years, but I've never seen
something like that unless one takes an extremely aggressive
interpretation of "copyright notice" that I wouldn't take.

> 2. If an upstream project does that, the debian/copyright file should
>reflect that and have a `Files: *` (or whatever pattern) notice that
>has a copyright notice without any years... right? And if an upstream
>project does that between releases, the debian/copyright file should
>change (drop the years) in the next "new upstream release" upload...
>right?

Yes, that seems to logically follow.  For licenses like BSD and Expat
where including the copyright notices is a license condition, we should
just copy the license notices that upstream uses (I believe it's fine to
consolidate years), so if there are no years, we shouldn't put in years.

> 3. Now, what about the `Files: debian/*` section of the debian/copyright
>file? The common wisdom seems to be that, if only to make it easier to
>submit patches to the upstream project, the debian/* files ought to be
>licensed under the same terms as the upstream source. Now I know that
>licensing and copyright are different things :) So would the Debian
>Project consider it okay for a Debian package to have
>a `Files: debian/*` section in its copyright file that does not
>mention any years? This question is both from a DFSG point of view and
>from a "what would be best for our users" one. And does the answer
>depend on whether the upstream project's copyright notices include
>years or not? (as in, should we follow upstream's lead in that, too)

I think it's fine to omit the year from copyright notices in debian/*.  It
certainly seems clear to me that it's fine from a DFSG perspective; a lot
of packages don't even have any separate stanza or copyright notices for
debian/* at all and copyright notices are optional.  (Not saying this is
ideal, just that it's not a DFSG violation.)

Sam made the point that including the year communicates when the Debian
packaging would enter the public domain.  This is true, but I can't bring
myself to care that much about it since (sadly in my opinion) that point
is so far into the future that I'm dubious of the effort to reward ratio
of curating years for all those decades.  Not to mention that the debian/*
packaging is continuously updated so additional copyright may attach and
that gets into a murky mess in terms of copyright expiration, which
decreases the value of that information.

People doing this should be aware that you're probably waiving certain
damage provisions in US copyright law should you ever sue someone in the
US for violating the license on the Debian packaging, at least so far as I
understand US copyright law.  (I am not a lawyer and this is not legal
advice for your specific situation.)

-- 
Russ Allbery (r...@debian.org)  

Re: Yearless copyrights: what do people think?

[Ansgar]

On Wed, 2023-02-22 at 07:39 -0700, Sam Hartman wrote:
> > > > > 
> As Jonas mentions, including the years allows people to know when works
> enter the public domain and the license becomes more liberal.
> I think our users are better served by knowing when the Debian packaging
> would enter the public domain.

As far as I know for works from a known author, copyright expires X
years after the death of the author. The year of creation or
publication isn't useful. Nor are individual years for every year where
a change was done (as I think the FSF suggests to document).

It is different for anonymous or pseudonymous works where the author is
not known, but the author can name himself later (which is fun to find
out about: you need to follow the national register for such
publications which only exists on paper in Germany[1]).

Ansgar

  [1]: 
https://www.dpma.de/dpma/wir_ueber_uns/weitere_aufgaben/verwertungsges_urheberrecht/anonyme_werke/index.html

Re: Yearless copyrights: what do people think?

[Richard Laager]

I maintain a package where upstream has dropped the years. I was told 
that multiple big tech companies with serious lawyers looked at this and 
felt it was fine.


I fully support:
  - upstreams dropping years from copyright notices
  - Debian not requiring maintainers to preserve years in
debian/copyright files.

On 2/22/23 08:39, Sam Hartman wrote:

I think our users are better served by knowing when the Debian packaging
would enter the public domain.


In theory, I agree with you. In practice, copyright lengths are so long 
in many countries that software effectively never enters the public 
domain (at least not while it is still of useful/non-historical value).


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

Re: Yearless copyrights: what do people think?

[Sam Hartman]

> "Peter" == Peter Pentchev  writes:

Peter> 3. Now, what about the `Files: debian/*` section of the
Peter> debian/copyright file? The common wisdom seems to be that, if
Peter> only to make it easier to submit patches to the upstream
Peter> project, the debian/* files ought to be licensed under the
Peter> same terms as the upstream source. Now I know that licensing
Peter> and copyright are different things :) So would the Debian
Peter> Project consider it okay for a Debian package to have a
Peter> `Files: debian/*` section in its copyright file that does not
Peter> mention any years? This question is both from a DFSG point of
Peter> view and from a "what would be best for our users" one. And
Peter> does the answer depend on whether the upstream project's
Peter> copyright notices include years or not? (as in, should we
Peter> follow upstream's lead in that, too)

Peter> Note that none of that comes from any "it's so difficult"
Peter> positions; I am actually one of the people who would include
Peter> file-by-file stanzas in the debian/copyright files for
Peter> upstream files with different copyright years :)

I think it is acceptable, but would urge you to include the years
because it is better for our users.

I think two things apply.

1) it helps our users know when something goes out of copyright.

2) As Russ points out, while your copyright is valid in the US even
without notice, certain damage provisions only apply if you have valid
notice including years.

Neither of these are huge deals.

I'd say years should be recommended but not required.

I don't think parity with upstream matters.
I don't think you would have any trouble submitting patches if the only
difference is one notice included years and one did not.

Re: Yearless copyrights: what do people think?

[Scott Kitterman]

On February 22, 2023 9:38:48 PM UTC, Sam Hartman  wrote:
>> "Peter" == Peter Pentchev  writes:
>
>Peter> 3. Now, what about the `Files: debian/*` section of the
>Peter> debian/copyright file? The common wisdom seems to be that, if
>Peter> only to make it easier to submit patches to the upstream
>Peter> project, the debian/* files ought to be licensed under the
>Peter> same terms as the upstream source. Now I know that licensing
>Peter> and copyright are different things :) So would the Debian
>Peter> Project consider it okay for a Debian package to have a
>Peter> `Files: debian/*` section in its copyright file that does not
>Peter> mention any years? This question is both from a DFSG point of
>Peter> view and from a "what would be best for our users" one. And
>Peter> does the answer depend on whether the upstream project's
>Peter> copyright notices include years or not? (as in, should we
>Peter> follow upstream's lead in that, too)
>
>Peter> Note that none of that comes from any "it's so difficult"
>Peter> positions; I am actually one of the people who would include
>Peter> file-by-file stanzas in the debian/copyright files for
>Peter> upstream files with different copyright years :)
>
>I think it is acceptable, but would urge you to include the years
>because it is better for our users.
>
>I think two things apply.
>
>1) it helps our users know when something goes out of copyright.
>
>2) As Russ points out, while your copyright is valid in the US even
>without notice, certain damage provisions only apply if you have valid
>notice including years.
>
>Neither of these are huge deals.
>
>I'd say years should be recommended but not required.
>
>I don't think parity with upstream matters.
>I don't think you would have any trouble submitting patches if the only
>difference is one notice included years and one did not.
>

I would add, that it's absolutely a requirement for license compliance in some 
cases.  For those cases, please continue to include it.  I don't think Debian 
should have a view that failing to comply with a license is okay if we think we 
can get away with it.

Scott K

Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Sam Hartman]

> "Antonio" == Antonio Terceiro  writes:

Antonio> On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
>> 
>> On 2/21/23 15:03, Ryan Kavanagh wrote:
>> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>> > > Description : A tool for glamourous shell scripts
>> > > 
>> > > A tool for glamorous shell scripts. Leverage the power of
>> Bubbles and > > Lip Gloss in your scripts and aliases without
>> writing any Go code!  > This long description does not provide
>> users with enough information to > understand what the package
>> does. What are "Bubbles" and "Lip Gloss" in > a shell script?
>> What is a "glamourous shell script"?
>> > 
>> > It would be helpful if the package's long description satisfied
>> §3.4.2 > of the Debian Policy Manual [0]:
>> > 
>> > The description field needs to make sense to anyone, even
>> people who > have no idea about any of the things the package
>> deals with. [3]
>> > 
>> > [...]
>> > 
>> > [3] The blurb that comes with a program in its announcements
>> and/or > README files is rarely suitable for use in a
>> description. It is > usually aimed at people who are already in
>> the community where the > package is used.
>> > 
>> > Best wishes, > Ryan
>> > 
>> > [0]
>> 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
>> > 
>> 
>> The package description will be this or close to it:

Antonio> That is just too long, please don't.

>>  A tool for glamorous shell scripts. Leverage the power of
>> Bubbles  (https://github.com/charmbracelet/bubbles) and Lip Gloss
>>  (https://github.com/charmbracelet/lipgloss) in your scripts and
>> aliases  without writing any Go code!   .   Tutorial  .   Gum
>> provides highly configurable, ready-to-use utilities to help you
>> write  useful shell scripts and dotfiles aliases with just a few
>> lines of code.

Antonio> This last paragraph above looks like a good enough package
Antonio> description.  Save everything else for an upstream README
Antonio> installed on /usr/share/doc/gum/, or some other type of
Antonio> documentation.

I disagree.
I should not have to chase down links to  websites to understand a
description
Please include a phrase or two describing each of bubbles and gloss.

Re: Yearless copyrights: what do people think?

[Jonas Smedegaard]

Quoting Jérémy Lal (2023-02-22 17:04:01)
> Le mer. 22 févr. 2023 à 15:39, Sam Hartman  a écrit :
> 
> > > "Peter" == Peter Pentchev  writes:
> >
> > Peter> Hi, So I've seen this idea floating around in the past couple
> > Peter> of years (and in some places even earlier), but I started
> > Peter> doing it for the couple of pieces of software that I am
> > Peter> upstream for after reading Daniel Stenberg's blog entry:
> > Peter> https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/
> >
> > Peter> And then, a couple of weeks ago, I quietly checked whether
> > Peter> the Debian FTP team would be okay with that by uploading two
> > Peter> NEW packages without any years mentioned in the
> > Peter> debian/copyright file: either upstream or for my Debian
> >
> > As Jonas mentions, including the years allows people to know when works
> > enter the public domain and the license becomes more liberal.
> > I think our users are better served by knowing when the Debian packaging
> > would enter the public domain.
> >
> 
> Maybe only the first year the copyright was applied is important ?

Possibly, yes.  My advice is to include upstream stated sane¹ years.

Reason for that is that several licenses require verbatim copy of
copyright statements.  Requirement² is not literal, only verbatim, which
I interpret as it's ok to e.g. translate "2001, 2002, 2003" into
"2001-2003" but not ok to translate it into "2001" since that is clearly
removing some "words".

 - Jonas

¹ When upstream says 2001-now then only include 2001, because "now" is
an insane expression in the context of copyright statements.

² Yeah, requirement is aguably only commonly relevant for source, not
for debian/copyright files, but that's a somewhat different topic.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[FC Stegerman]

* Sam Hartman  [2023-02-22 23:33]:
[...]
> >> A tool for glamorous shell scripts. Leverage the power of
> >> Bubbles (https://github.com/charmbracelet/bubbles) and Lip
> >> Gloss (https://github.com/charmbracelet/lipgloss) in your
> >> scripts and aliases without writing any Go code!
[...]
> >> Gum provides highly configurable, ready-to-use utilities to
> >> help you write  useful shell scripts and dotfiles aliases
> >> with just a few lines of code.
> 
> Antonio> This last paragraph above looks like a good enough package
> Antonio> description.  Save everything else for an upstream README
> Antonio> installed on /usr/share/doc/gum/, or some other type of
> Antonio> documentation.
> 
> I disagree.

With what?  Antonio said "last paragraph".  The links to Bubbles and
Lip Gloss are not in the last paragraph.  The last paragraph does look
alright to me, if a bit vague on what kind of utilities, so a brief
description of Bubbles and Lip Gloss does seem useful to add.

> I should not have to chase down links to  websites to understand a
> description

No disagreement there.

> Please include a phrase or two describing each of bubbles and gloss.

No disagreement there -- if they are mentioned in the description.

- FC

Re: Yearless copyrights: what do people think?

[Jonas Smedegaard]

Quoting Richard Laager (2023-02-22 21:47:49)
> I maintain a package where upstream has dropped the years. I was told 
> that multiple big tech companies with serious lawyers looked at this and 
> felt it was fine.

Big tech companies typically don't use free software licensing for the
same reasons as (some) of our users: As I mentioned earlier, for most
legal jurisdictions there is no (or little) legal benefit for the
copyright holders in expressing copyright statements, the benefit is for
others doing derived works which big tech companies typically care less
about.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Yearless copyrights: what do people think?

[Paul Wise]

On Wed, 2023-02-22 at 09:47 -0800, Russ Allbery wrote:

> People doing this should be aware that you're probably waiving certain
> damage provisions in US copyright law should you ever sue someone in the
> US for violating the license on the Debian packaging, at least so far as I
> understand US copyright law.  (I am not a lawyer and this is not legal
> advice for your specific situation.)

Could you give some more details about this? I hadn't heard of it yet.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: debian support veeam

[Paul Wise]

On Wed, 2023-02-22 at 12:16 +0300, Nijam Deen wrote:

> debain os will support for veeam backup using network storage

Since Veeam is proprietary software, please ask their support team:

https://www.veeam.com/support.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Yearless copyrights: what do people think?

[Russ Allbery]

Paul Wise  writes:
> On Wed, 2023-02-22 at 09:47 -0800, Russ Allbery wrote:

>> People doing this should be aware that you're probably waiving certain
>> damage provisions in US copyright law should you ever sue someone in
>> the US for violating the license on the Debian packaging, at least so
>> far as I understand US copyright law.  (I am not a lawyer and this is
>> not legal advice for your specific situation.)

> Could you give some more details about this? I hadn't heard of it yet.

https://www.law.cornell.edu/uscode/text/17/401:

(d) Evidentiary Weight of Notice.—

If a notice of copyright in the form and position specified by this
section appears on the published copy or copies to which a defendant
in a copyright infringement suit had access, then no weight shall be
given to such a defendant’s interposition of a defense based on
innocent infringement in mitigation of actual or statutory damages,
except as provided in the last sentence of section 504(c)(2).

Also see https://www.copyright.gov/circs/circ03.pdf, specifically
"Advantages to Using a Copyright Notice" starting on page 3.

-- 
Russ Allbery (r...@debian.org)  

Bug#1031807: ITP: java-opensaml -- Shibboleth Project's OpenSAML java libraries

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-j...@lists.debian.org, 
debian-security-to...@lists.debian.org, j...@nahmias.net, d...@shibboleth.net
Control: block 1031769 by -1

* Package name: java-opensaml
  Version : 4.3.0
  Upstream Author : Shibboleth 
* URL : https://shibboleth.atlassian.net/wiki/spaces/OS30/overview
* License : Apache 2
  Programming Lang: Java
  Description : Shibboleth Project's OpenSAML java libraries

 OpenSAML is a set of open source C++ & Java libraries used in support
 of the Shibboleth Project's implementation of the Security Assertion
 Markup Language (SAML).

 OpenSAML 4, the current Java library version, is based on Java 11, and
 supports SAML 1.0, 1.1, and 2.0. Additionally, various development groups
 have found the framework created to support OpenSAML useful for their own
 work and the Java codebase includes some code supporting WS-Addressing,
 WS-Security, WS-Trust and XACML.

 The OpenSAML libraries do not provide a complete SAML identity or service
 provider. If you are looking for such software you should check out the
 Shibboleth project instead. Also, these libraries will not teach you any
 of the specifications listed above. The libraries are meant solely to
 support individuals who have taken the time to read and understand the
 specifications and are not in general a good solution for those looking
 for a quick way to implement SAML.

Updating python3-xlrd for pandas 1.5 compatibility

[Diane Trout]

Hi,

the version of python3-xlrd 1.2.0-3 in unstable/testing is too old to
be used with pandas 1.5.3. (See Bug #1031701). As it is a really common
workflow to use pandas to read excel files, it'd be nice if the version
of xlrd in bookworm was compatible.

Because of the freeze I wanted to check if it was appropriate to upload
the new version, and what kind of warning I should give to the other
developers.

THe xlrd changelog says the biggest change in going from 1.2 to 2.0 was
they removed the ability to read the newer XML excel files .xslx from
xlrd in favor of using openpyxl

I updated the source package python-xlrd to 2.0.1 and sent it through
experimental, where there were no issues detected by packages that had
CI tests.

Unfortunately there's packages without tests.

Here's the list of packages I found that have any relationship to
python-xlrd, if it looked like the autopkgtests actually tested using
the xlrd library and what the level of declared dependency is. (none
means the package lacks autopackage tests)

| nemo | none | Recommends|
| odoo-14  | none | Depends   |
| ofxstatement-plugins | none | Depends   |
| psychopy | unlikely | Depends   |
| python3-agateexcel   | yes  | Depends   |
| python3-canmatrix| no   | Recommends|
| python3-drslib   | no   | Recommends|
| python3-glue | yes  | Depends   |
| python3-pyspectral   | probably | Suggests  |
| python3-rows | unlikely | Recommends|
| python3-tablib   | unlikely | Depends   |
| visidata | none | Build-Depends |
| vistrails| none | Build-Depends |
| python-xrt   | none | Build-Depends |
| pyutilib | none | Build-Depends |

Thanks
Diane