Re: What to do when DD considers policy to be optional? [kubernetes]

[Marc Haber]

On Thu, 26 Mar 2020 09:39:56 +1100, Dmitry Smirnov
 wrote:
>On Thursday, 26 March 2020 3:45:21 AM AEDT Marc Haber wrote:
>> Software packages like kubernetes, docker, and many of the other "hip
>> tools of the day" are moving way too fast for our release scheme.
>
>It is worth remembering that Debian is not only a stable release.
>Statically built Golang apps are easy to install from testing/unstable into 
>stable and packaging still provides certain benefits.

I still wouldn't dare pulling testing or unstable packages to
production systems. It's like a worst-of-all-worlds approach.

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: What to do when DD considers policy to be optional? [kubernetes]

[Dmitry Smirnov]

On Thursday, 26 March 2020 7:27:33 PM AEDT Marc Haber wrote:
> I still wouldn't dare pulling testing or unstable packages to
> production systems. It's like a worst-of-all-worlds approach.

Not at all. Packaging is an extra layer of safety. Upstream release may be 
outright broken, unusable or buggy with critical regressions. Presumably 
maintainer at least tested the packages maybe even by using.

Therefore I consider packages to be a better alternative than direct use of 
upstream software, even when you need to use a package from "testing".

Also all "stable" packages were once in "testing" and one can never be sure 
if any package was tested enough before it become "stable".

Careful use of canary pre-production systems where you roll updates first, 
before deploying to production, allows to mitigate risks of regressions due 
to software upgrades.

-- 
All the best,
 Dmitry Smirnov.

---

Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
-- H. L. Mencken


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

Bug#954987: ITP: locker -- Container

[Amit]

Package: wnpp
Severity: wishlist
Owner: Amit 

* Package name: locker
  Version : 0.0~git20200313.1210f0e-1
  Upstream Author : amit
* URL : https://www.gitlab.com/amit-yuval/locker
* License : Apache-2.0
  Programming Lang: Go
  Description : Container

Bug#954986: ITP: locker -- Container

[Amit]

Package: wnpp
Severity: wishlist
Owner: Amit 

* Package name: locker
  Version : 0.0~git20200313.1210f0e-1
  Upstream Author : amit
* URL : www.gitlab.com/amit-yuval/locker
* License : Apache-2.0
  Programming Lang: Go
  Description : Container

Re: What to do when DD considers policy to be optional? [kubernetes]

[Christian Kastner]

On 25.03.20 15:50, Scott Kitterman wrote:
> The FTP Team review of debian/copyright is about DFSG and upstream license 
> compliance.  Most licenses require things like copyright statement 
> preservation in binary distribution and debian/copyright is how we do that.  
> Occasionally, in the process of evaluating if Debian would be in compliance 
> with the upstream license and if the license meets our DFSG requirements, we 
> detect larger issues.  
> 
> When I'm reviewing something for New I take upstream's copyright/license 
> statements at face value unless there's something too obvious to be ignored.  
> I certainly don't go hunting for reasons not to like upstream licensing 
> statements, but sometimes they slap you in the face.
> 
> By far the most common case for rejections is incomplete debian/copyright and 
> that's unrelated to trusting upstream.  Personally, I don't think the problem 
> is that the bar is too high.  Almost all debian/copyright issue I find could 
> have been located before upload if the maintainer had simply grep -ir 
> copyright * | less and checked the results before uploading.

It's just that this last step frequently turns out to be a very draining
rabbit hole. [1]

Frustratingly, the smaller the contribution, the deeper the hole. Larger
contributions tend to have explicit copyright information, so it's
easier to determine and document. Smaller ones sometimes just document
only the author. [2]

I find the analysis of this to be totally draining work. And while I
could see a point to this in the past, I no longer do.

FOSS began as a movement where legal and political aspects were on the
front line, and distributions like Debian were the primary channel to
access FOSS, so it's easy to understand why debian/copyright was
initially given so much importance.

Today, (IMO most of) "FOSS" is people creating, sharing and contributing
stuff on GitHub and similar platforms. GitHub et al. have made hosting
and contributing for/to projects so trivial that people /just do it/. It
comes naturally. The legal and political aspects are no longer the front
line. In many cases, they even have become overhead.

There's this expression in German for when one takes a policy too far:
"Don't try to be holier than the Pope".

But that's how maintaining debian/copyright has come to feel to me. We
still apply a level of detail that seems out of place in today's world.
It's such an odd position to be in to sit between upstream and
contributor and discuss with them the legalities of one contribution
you've hunted down, when it is evident that it was just "a
contribution", and neither could understand why I have to make such a
big deal out of it. [3]

So, I ask: what for? Policy for policy's sake?

Why not just begin with a simple debian/copyright that documents, in
very short form, what upstream documents in LICENSE and COPYING, and
only refer to AUTHORS, etc., and only begin to look at further details
once somebody actually /complains/ about them.

In any case, let's keep in mind that we are just one of the
distributors. Now that it has become so easy to file complaints with
upstream (again, thanks to GitHub et al.), I'm all but certain that any
legal issues with the original source would first be filed upstream,
rather than for all downstreams individually.

I think we investing far too much time in a problem that no longer
exists, and probably wasn't even that big of a problem in the past
(unless anyone can provide an example where a detailed debian/copyright
has ever paid off the effort it cost).

Christian


[1] It only starts with 'grep -ir copyright *'. In many jurisdictions,
copyright applies regardless of where it is expressly claimed or not, so
'grep -ir author *' is probably just as important as a signal, and
people tend to add that a lot.

[2] Because why would anyone (who is not Oracle) actually care about a
few dozen lines of code.

[3] Except, of course, where contributions are legally formalized, for
example with a CLA.

PS: This is my personal view of the the matter as I originally
experienced it when becoming a maintainer, and over time when fixing RC
bugs related to policy, resp. observing other bugs. It's quite possible
that it is my personal view that is completely off, and that the
ftp-master view isn't that strict, at all.

Re: What to do when DD considers policy to be optional? [kubernetes]

[Scott Kitterman]

On Thursday, March 26, 2020 7:40:42 AM EDT Christian Kastner wrote:
> On 25.03.20 15:50, Scott Kitterman wrote:
> > The FTP Team review of debian/copyright is about DFSG and upstream license
> > compliance.  Most licenses require things like copyright statement
> > preservation in binary distribution and debian/copyright is how we do
> > that.  Occasionally, in the process of evaluating if Debian would be in
> > compliance with the upstream license and if the license meets our DFSG
> > requirements, we detect larger issues.
> > 
> > When I'm reviewing something for New I take upstream's copyright/license
> > statements at face value unless there's something too obvious to be
> > ignored.  I certainly don't go hunting for reasons not to like upstream
> > licensing statements, but sometimes they slap you in the face.
> > 
> > By far the most common case for rejections is incomplete debian/copyright
> > and that's unrelated to trusting upstream.  Personally, I don't think the
> > problem is that the bar is too high.  Almost all debian/copyright issue I
> > find could have been located before upload if the maintainer had simply
> > grep -ir copyright * | less and checked the results before uploading.
> It's just that this last step frequently turns out to be a very draining
> rabbit hole. [1]
> 
> Frustratingly, the smaller the contribution, the deeper the hole. Larger
> contributions tend to have explicit copyright information, so it's
> easier to determine and document. Smaller ones sometimes just document
> only the author. [2]
> 
> I find the analysis of this to be totally draining work. And while I
> could see a point to this in the past, I no longer do.
> 
> FOSS began as a movement where legal and political aspects were on the
> front line, and distributions like Debian were the primary channel to
> access FOSS, so it's easy to understand why debian/copyright was
> initially given so much importance.
> 
> Today, (IMO most of) "FOSS" is people creating, sharing and contributing
> stuff on GitHub and similar platforms. GitHub et al. have made hosting
> and contributing for/to projects so trivial that people /just do it/. It
> comes naturally. The legal and political aspects are no longer the front
> line. In many cases, they even have become overhead.
> 
> There's this expression in German for when one takes a policy too far:
> "Don't try to be holier than the Pope".
> 
> But that's how maintaining debian/copyright has come to feel to me. We
> still apply a level of detail that seems out of place in today's world.
> It's such an odd position to be in to sit between upstream and
> contributor and discuss with them the legalities of one contribution
> you've hunted down, when it is evident that it was just "a
> contribution", and neither could understand why I have to make such a
> big deal out of it. [3]
> 
> So, I ask: what for? Policy for policy's sake?
> 
> Why not just begin with a simple debian/copyright that documents, in
> very short form, what upstream documents in LICENSE and COPYING, and
> only refer to AUTHORS, etc., and only begin to look at further details
> once somebody actually /complains/ about them.
> 
> In any case, let's keep in mind that we are just one of the
> distributors. Now that it has become so easy to file complaints with
> upstream (again, thanks to GitHub et al.), I'm all but certain that any
> legal issues with the original source would first be filed upstream,
> rather than for all downstreams individually.
> 
> I think we investing far too much time in a problem that no longer
> exists, and probably wasn't even that big of a problem in the past
> (unless anyone can provide an example where a detailed debian/copyright
> has ever paid off the effort it cost).
> 
> Christian
> 
> 
> [1] It only starts with 'grep -ir copyright *'. In many jurisdictions,
> copyright applies regardless of where it is expressly claimed or not, so
> 'grep -ir author *' is probably just as important as a signal, and
> people tend to add that a lot.
> 
> [2] Because why would anyone (who is not Oracle) actually care about a
> few dozen lines of code.
> 
> [3] Except, of course, where contributions are legally formalized, for
> example with a CLA.
> 
> PS: This is my personal view of the the matter as I originally
> experienced it when becoming a maintainer, and over time when fixing RC
> bugs related to policy, resp. observing other bugs. It's quite possible
> that it is my personal view that is completely off, and that the
> ftp-master view isn't that strict, at all.

I think you assume we're looking for more than we are.  We aren't asking 
anyone to research and document undocumented but technically legally 
assertable copyright claims.  From an FTP perspective we're after license 
compliance.  

If debian/copyright includes all the copyright notices that upstream does (or 
an equivalent), then that's all that's needed (there are exceptions, I have 
reviewed packages where upstream literally wrote

Re: What to do when DD considers policy to be optional? [kubernetes]

[Simon Richter]

Hi,

On 25.03.20 23:39, Dmitry Smirnov wrote:

>> Software packages like kubernetes, docker, and many of the other "hip
>> tools of the day" are moving way too fast for our release scheme.

> It is worth remembering that Debian is not only a stable release.
> Statically built Golang apps are easy to install from testing/unstable into 
> stable and packaging still provides certain benefits.

That, and in theory we also have a "volatile" archive for things that
move too fast.

> Stable Debian release protects users from sudden unexpected and disruptive 
> changes but some prefer to run their systems from "testing".

I'd expect people running container hosts to prefer stable, but if
upstream doesn't provide a "long term support" version (or anything that
actually has a version number instead of a commit ID) and at the same
time the software is too complex to branch off and maintain ourselves,
then our hands are kind of tied.

FWIW, I used to maintain software like this, and filed a "this software
is unstable and should not be part of a stable release" RC bug against
it, that's a completely valid state for a package to be in. For anything
but container host software, the existence of containers even makes this
somewhat manageable.

We have an awful lot of packages with version numbers of the forms
"0+git...", "0.0.2019..." or just a single large number, because
upstream does not believe in traditional releases, but the processes
Debian was built around expect software to be released and supported for
a while and expect maintainers to be able to forward bug reports
upstream and get a better reply than "tell your users to upgrade".

Getting Firefox and Thunderbird as ESR versions into Debian was a
massive amount of pain, but in the end it seems to have paid off,
because we managed to convince upstream that there is demand for stable
releases from users who do not want to roll out updates constantly and
deal with the resulting stability issues.

As a distribution, it is our job to communicate users' expectations to
upstream, not just to facilitate an unidirectional flow of packages.
Many upstreams already distribute .deb files from a robust mirror
infrastructure, our value proposition should be a bit stronger than "you
don't need to configure an additional source".

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#955005: Relax requirements to copy copyright notices into d/copyright

[Sean Whitton]

Package: debian-policy
Version: 4.5.0.0
User: debian-pol...@packages.debian.org
Usertags: normative discussion
X-debbugs-cc: debian-devel@lists.debian.org, ftpmas...@debian.org

Scott has provided a useful summary of what the FTP Team require when it
comes to copyright information, and as another FTP Team member, I concur
with his assessment of the consensus within the team:

On Thu 26 Mar 2020 at 10:32AM -04, Scott Kitterman wrote:

> I think you assume we're looking for more than we are.  We aren't asking
> anyone to research and document undocumented but technically legally
> assertable copyright claims.  From an FTP perspective we're after license
> compliance.
>
> If debian/copyright includes all the copyright notices that upstream does (or
> an equivalent), then that's all that's needed (there are exceptions, I have
> reviewed packages where upstream literally wrote that they had copied a bunch
> of code from some other location, changed the copyright owner to themselves,
> and changed the license - that we had a problem with, but it wasn't like we
> went looking for it).
>
> To pick one example, the Expat (MIT) license includes:
>
> The above copyright notice and this permission notice shall be
> included in all copies or substantial portions of the Software.
>
> When we ask for listing copyright holders in debian/copyright, that's what
> we're after.  I don't think complying with license requirements is an
> unreasonable thing to ask.
>
> That said, if we can make it easier for everyone, then we should investigate
> that.  As mentioned, policy does have a higher bar.  It says they all have to
> be listed regardless of license requirements.
>
> To pick another example, Apache-2.0 includes:
>
>   (c) You must retain, in the Source form of any Derivative Works
>   that You distribute, all copyright, patent, trademark, and
>   attribution notices from the Source form of the Work,
>   excluding those notices that do not pertain to any part of
>   the Derivative Works; and
>
> For something that we distribute based on our rights in the Apache-2.0 license
> and requirement to document all the copyright holders is strictly Debian
> specific based on policy.  Personally, I think the policy should be changed so
> we don't require everyone to go beyond the license requirements.  Currently I
> think there is consensus within the FTP Team not to reject packages for this.

Policy currently says:

Every package must be accompanied by a verbatim copy of its
copyright information, unless its distribution license explicitly
permits this information to be excluded from distributions of
binaries built from the source.  In such cases, a verbatim copy of
its copyright information should normally still be included, but
need not be if creating and maintaining a copy of that information
involves significant time and effort.

We wrote this based on [1], but I now believe it is too conservative,
and does not reflect what the FTP Team require, nor the project's
consensus on what should be in d/copyright.  I think we want something
like this:

The copyright information for files in a package must be copied
verbatim into d/copyright when (i) the distribution license for
those files requires that copyright information be included in all
binary distributions; (ii) the files are shipped in the binary
package, either in source or compiled form; and (iii) the form in
which the files are present in the binary package does not include a
plain text version of their copyright notices.

Thus, the copyright information for files in the source package
which are only part of its build process, such as autotools files,
need not be included in d/copyright, because those files do not get
installed into the binary package.  Similarly, plain text files
which include their own copyright information and are installed into
the binary package unmodified need not have that copyright
information copied into d/copyright.

However, the copyright notices for any files which are complied into
the object code shipped in the binary package must all be included
in d/copyright when the license requires that copyright information
be included in all binary distributions, as most do.

The point of separating (ii) and (iii) is because the source form of a
file need not be plain text, such as image files, and because even for
plain text files the copyright information may not be included in the
files themselves, but perhaps only in LICENSE.txt or similar.

This is, I believe, the minimum required for license compliance when it
comes to copyright notices.  It is significantly weaker than what Policy
currently requires, but I think we have a project consensus that we
should not be requiring more than what is required for license
compliance.  Of course, it is still open to maintainers to include more
information in d/copyrigh

Re: What to do when DD considers policy to be optional? [kubernetes]

[Bernd Zeimetz]

On 3/25/20 11:30 PM, Dmitry Smirnov wrote:
> Given that logic even re-compiling using different compiler would not be 
> trustworthy. And indeed some people make exactly that argument -- "use our 
> tested binary" as one can't be sure if re-compiling introduces any bugs.

Indeed I'd expect it that you'd at least compile it using the same
golang version.

> That questions the very usability of source code releases, whether you 
> understand it or not.
> 
> With this and your next arguments you are questioning the very usability of 
> packaging and I might agree that Kubernetes may not be worth packaged, 
> especially if we can't do it properly.


k8s is a way too fast moving target to be able to package it in a sane
way. It will be versions behind already when we release Debian.


>> What you suggest is a nice idea, but hard for go sources and impossible
>> for packages like k8s.
> 
> I don't know how to respond nicely when someone who did not maintain a 
> complex Golang application tells me that the way myself and others maintain 
> packages like docker,io, consul, nomad, vault, syncthing is "impossible"...

Not sure how I should respond nicely, but

A) you have no clue what I do (there is life outside of Debian, you know)

B) there are reasons why people recommend not to use the packaged
versions of docker.io. No opinion on the others, never touched them.



Applying the Debian "library" policy on go code is imho impossible -
there are no sonames, often no proper releases. The way how Debian
packages source code does not fit for go.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: What to do when DD considers policy to be optional? [kubernetes]

[Andrej Shadura]

Hi,

On Thu, 26 Mar 2020 at 12:40, Christian Kastner  wrote:
> There's this expression in German for when one takes a policy too far:
> "Don't try to be holier than the Pope".
>
> But that's how maintaining debian/copyright has come to feel to me. We
> still apply a level of detail that seems out of place in today's world.
> It's such an odd position to be in to sit between upstream and
> contributor and discuss with them the legalities of one contribution
> you've hunted down, when it is evident that it was just "a
> contribution", and neither could understand why I have to make such a
> big deal out of it. [3]
>
> So, I ask: what for? Policy for policy's sake?

I beg to disagree. We do this for our users. They, believe it or not,
often need it.

An example: commercial users. They need to know *exactly* what they
are running and under which licenses. They often want to be holier not
only than the Pope, but holier than the whole population of Poland,
Italy and Spanish-speaking countries altogether (I hope I don’t offend
anyone with this comparison, it’s meant as a joke). They are often
bound by regulations with heavy fines for violating them, and not only
fines, but a threat of your product being banned, and that often means
they want only specific licenses in their products.

And then there are Debian derivatives that cater to such commercial
users. And guess what? The users tell the makers of the derivatives
debian/copyright data that comes from Debian is not sufficiently
strict or precise, and for that they need to set up their own
processes to double-check and review the Debian copyright data.

So if anything, we need to pay *more* attention to copyrights, not less.

-- 
Cheers,
  Andrej

Re: What to do when DD considers policy to be optional? [kubernetes]

[Kyle Edwards]

On Thu, 2020-03-26 at 19:57 +0100, Andrej Shadura wrote:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses. They often want to be holier
> not
> only than the Pope, but holier than the whole population of Poland,
> Italy and Spanish-speaking countries altogether (I hope I don’t
> offend
> anyone with this comparison, it’s meant as a joke). They are often
> bound by regulations with heavy fines for violating them, and not
> only
> fines, but a threat of your product being banned, and that often
> means
> they want only specific licenses in their products.
> 
> And then there are Debian derivatives that cater to such commercial
> users. And guess what? The users tell the makers of the derivatives
> debian/copyright data that comes from Debian is not sufficiently
> strict or precise, and for that they need to set up their own
> processes to double-check and review the Debian copyright data.

Is it Debian's responsibility to cater to commercial users though?
Debian is not receiving commercial funding, or at least not directly.
It seems to me like the responsibility for this work falls on the
commercial users, not Debian.

Kyle

Re: Re: discrepancy in ISO 3166-1 country codes

[Erica Castro]

Sent from my iPhone

Re: What to do when DD considers policy to be optional? [kubernetes]

[Scott Kitterman]

On Thursday, March 26, 2020 3:27:18 PM EDT Kyle Edwards wrote:
> On Thu, 2020-03-26 at 19:57 +0100, Andrej Shadura wrote:
> > An example: commercial users. They need to know *exactly* what they
> > are running and under which licenses. They often want to be holier
> > not
> > only than the Pope, but holier than the whole population of Poland,
> > Italy and Spanish-speaking countries altogether (I hope I don’t
> > offend
> > anyone with this comparison, it’s meant as a joke). They are often
> > bound by regulations with heavy fines for violating them, and not
> > only
> > fines, but a threat of your product being banned, and that often
> > means
> > they want only specific licenses in their products.
> > 
> > And then there are Debian derivatives that cater to such commercial
> > users. And guess what? The users tell the makers of the derivatives
> > debian/copyright data that comes from Debian is not sufficiently
> > strict or precise, and for that they need to set up their own
> > processes to double-check and review the Debian copyright data.
> 
> Is it Debian's responsibility to cater to commercial users though?
> Debian is not receiving commercial funding, or at least not directly.
> It seems to me like the responsibility for this work falls on the
> commercial users, not Debian.
> 
> Kyle

Debian claims its users are its priority.  Not a specific sub-set of them.

Scott K

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

Re: What to do when DD considers policy to be optional? [kubernetes]

[Russ Allbery]

Andrej Shadura  writes:

> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses. They often want to be holier not
> only than the Pope, but holier than the whole population of Poland,
> Italy and Spanish-speaking countries altogether (I hope I don’t offend
> anyone with this comparison, it’s meant as a joke).

Could you provide some more details about this?  Statements from those
companies about what they care about exactly, or open source policies that
you can point at?  I ask because this is contrary to my own personal
experience where commercial users care about the top-line license
(including not wanting to use licenses that we consider free) but do not
care about the work that Debian does beyond that and routinely use
software based on the declared upstream license on GitHub without giving
it a second though.  However, my personal experience is limited, and I'd
be happy to be educated!

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

Re: What to do when DD considers policy to be optional? [kubernetes]

[Christian Kastner]

On 26.03.20 19:57, Andrej Shadura wrote:
> An example: commercial users. They need to know *exactly* what they
> are running and under which licenses.

The only way to know that is by performing your own due diligence.

> They are often bound by regulations with heavy fines for violating
> them, and not only fines, but a threat of your product being banned,
> and that often means they want only specific licenses in their
> products.

There is no way whatsoever that a regulator, or a court, will accept
checking a single third-party file (debian/copyright), created by an
unpaid volunteer one has never even met, much less have a business
relation with, as proper due diligence in a copyright infringement case.

[Well, technically, you could use your own lawyer to perform the due
diligence and have them submit any necessary changes to the BTS, but I
think it's safe to assume that that is a theoretical example.]

Don't get me wrong, debian/copyright is certainly useful in general, but
the only value in a legal conflict I can see is for Debian, namely to
demonstrate our own compliance when distributing binaries (see Scott's
and Sean's replies).

Re: What to do when DD considers policy to be optional? [kubernetes]

[Johannes Schauer]

Hi,

Quoting Russ Allbery (2020-03-25 03:25:49)
> Michael Lustfield  writes:
> > One last thing to consider... NEW reviews are already an intense process.
> > If this package hit NEW /and/ we allowed vendored libs, you could safely
> > expect me to never complete that particular review. I doubt I'm the only
> > one; that's essentially ~200 package reviews wrapped into 1.
> I'll repeat a point that I made earlier but put a bit of a sharper point on
> it: We should thoughtfully question whether the current approach to license
> review that we as a project ask ftpmasters to do is a correct investment of
> project resources.
> 
> The current approach to NEW license review is not a law of nature.  It's a
> choice.  Other choices are possible, such as trusting license declarations
> by upstream and then handling upstream mistakes that are later discovered
> as RC bugs.  The project is much better at sharing the load of handling RC
> bugs than it is at sharing the load of NEW license reviews.

the sub-thread as started by this mail only explores the option of reducing how
thoroughly we have to document copyright of the source code we put into Debian.
I wanted to point out that the original problem that started this was the
burden this status-quo puts on the FTP masters and how long packages remain in
NEW due to the required review effort.

So while we are contemplating our choices I wanted to point out that reducing
the quality of d/copyright is not the only possible option to tackle these
issues. The following ideas are not new but I wanted to just list them because
this thread seems to suggest that reducing our d/copyright thoroughness was the
only option we have.

For example it is also our choice that only FTP master are allowed to do the
copyright review and that the uploaded source must not leave the machine it was
uploaded to (even though it probably also lives on salsa at the same time). The
review process could be spread across more people or it could be open to the
public or to DD eyes only.  Yes, this introduces risks but taking this risk is
again a choice that we can make. It could be such that it needs X DDs to agree
and then a package clears the NEW queue or automated scripts could do a
plausibility check upfront. Especially teams that already know how the typical
layout of their domain best could work together to allow quick introduction of
new packages without reducing their quality.

What I'm saying is, that "reduce how good our d/copyright files have to be" is
not the only way to reduce burden on FTP master or to reduce the amount of time
packages spend in NEW. I'm also all in for reducing both but I would dislike it
very much if the quality of d/changelog would suffer as a result.

Thanks!

cheers, josch

signature.asc
Description: signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Andrej Shadura]

Hi,

On Thu, 26 Mar 2020 at 21:01, Russ Allbery  wrote:
> > An example: commercial users. They need to know *exactly* what they
> > are running and under which licenses. They often want to be holier not
> > only than the Pope, but holier than the whole population of Poland,
> > Italy and Spanish-speaking countries altogether (I hope I don’t offend
> > anyone with this comparison, it’s meant as a joke).

> Could you provide some more details about this?  Statements from those
> companies about what they care about exactly, or open source policies that
> you can point at?  I ask because this is contrary to my own personal
> experience where commercial users care about the top-line license
> (including not wanting to use licenses that we consider free) but do not
> care about the work that Debian does beyond that and routinely use
> software based on the declared upstream license on GitHub without giving
> it a second though.  However, my personal experience is limited, and I'd
> be happy to be educated!

Car industry. They prefer to have nothing to do with GPL-3 and related
licenses. They also want to know for sure when there’s something with
undeclared or unknown license or something completely non-free that
flew under the radar. As it is now, they cannot rely on
debian/copyright files because often they’re out of date, sometimes up
to ten years old. For Apertis, we had to build our own machinery based
on scan-copyright and, in future, on Fossology, to attempt to mitigate
that to some degree.

-- 
Cheers,
  Andrej

Re: What to do when DD considers policy to be optional? [kubernetes]

[Johannes Schauer]

Quoting Andrej Shadura (2020-03-26 22:24:41)
> On Thu, 26 Mar 2020 at 21:01, Russ Allbery  wrote:
> > > An example: commercial users. They need to know *exactly* what they
> > > are running and under which licenses. They often want to be holier not
> > > only than the Pope, but holier than the whole population of Poland,
> > > Italy and Spanish-speaking countries altogether (I hope I don’t offend
> > > anyone with this comparison, it’s meant as a joke).
> > Could you provide some more details about this?  Statements from those
> > companies about what they care about exactly, or open source policies that
> > you can point at?  I ask because this is contrary to my own personal
> > experience where commercial users care about the top-line license
> > (including not wanting to use licenses that we consider free) but do not
> > care about the work that Debian does beyond that and routinely use software
> > based on the declared upstream license on GitHub without giving it a second
> > though.  However, my personal experience is limited, and I'd be happy to be
> > educated!
> Car industry. They prefer to have nothing to do with GPL-3 and related
> licenses. They also want to know for sure when there’s something with
> undeclared or unknown license or something completely non-free that flew
> under the radar. As it is now, they cannot rely on debian/copyright files
> because often they’re out of date, sometimes up to ten years old. For
> Apertis, we had to build our own machinery based on scan-copyright and, in
> future, on Fossology, to attempt to mitigate that to some degree.

University. We maintain a GPL software of which we are also selling proprietary
licenses to companies. For this purpose our software must not link against any
GPL code. Recently we found by accident that a single file from an otherwise
BSD licensed 3rd party library we use was licensed under GPL. It was only a few
days before we had to hand our software to our customer so it would've spared
us a lot of headaches if that 3rd party library had a well documented
d/copyright file where we could've easily spotted that one GPL file.

signature.asc
Description: signature

Re: What to do when DD considers policy to be optional? [kubernetes]

[Dmitry Smirnov]

On Friday, 27 March 2020 5:42:47 AM AEDT Bernd Zeimetz wrote:
> B) there are reasons why people recommend not to use the packaged
> versions of docker.io. No opinion on the others, never touched them.

The are some valid reasons, for example version in "stable" is too old and 
the package (and more importantly, its dependency tree) was stabilized only 
recently. We did a big job fixing past design failures and mistakes by re-
factoring Docker packaging significantly. Now the package is in much better 
shape than it was.

I doubt that your "life outside Debian" argument is valid when we are 
discussing Debian packaging. The approach to build Golang applications 
against packaged reusable libraries is valid.


> Applying the Debian "library" policy on go code is imho impossible -
> there are no sonames, often no proper releases. The way how Debian
> packages source code does not fit for go.

The way how Golang community handled dependencies was insane for years, only 
being somewhat stabilized recently. There are no reasons to think that Goland 
is too special when it comes to life cycle and versioning of libraries.
More and more upstreams do the right thing and Debian approach mostly works  
when applied properly.

-- 
Best wishes,
 Dmitry Smirnov.

---

The further a society drifts from the truth, the more it will hate those
that speak it.
-- George Orwell


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

Work-needing packages report for Mar 27, 2020

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1223 (new: 1)
Total number of packages offered up for adoption: 232 (new: 0)
Total number of packages requested help for: 63 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   xstarfish (#954465), orphaned 4 days ago
 Description: X wallpaper generator
 Installations reported by Popcon: 44
 Bug Report URL: https://bugs.debian.org/954465

1222 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 232 packages
are awaiting adoption.  See https://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 530 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web
   dms-wsgi doc-central (136 more omitted)
 Installations reported by Popcon: 98862
 Bug Report URL: https://bugs.debian.org/910917

   autopkgtest (#846328), requested 1212 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker
 Installations reported by Popcon: 1172
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3105 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 700
 Bug Report URL: https://bugs.debian.org/642906

   broadcom-sta (#886599), requested 808 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1786
 Bug Report URL: https://bugs.debian.org/886599

   cargo (#860116), requested 1080 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 1659
 Bug Report URL: https://bugs.debian.org/860116

   cyrus-imapd (#921717), requested 412 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 439
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 1646 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (78 more omitted)
 Installations reported by Popcon: 204677
 Bug Report URL: https://bugs.debian.org/799864

   dee (#831388), requested 1350 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core
 Installations reported by Popcon: 34517
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 2035 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 7010
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#800413), requested 1640 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian buildd customdeb debci debian-builder debmake (32 more
   omitted)
 Installations reported by Popcon: 11944
 Bug Report URL: https://bugs.debian.org/800413

   docker.io (#908868), requested 558 days ago
 Description: Linux container runtime
 Reverse Depends: docker-clean golang-github-containers-buildah-dev
   golang-github-containers-image-dev
   golang-github-fsouza-go-dockerclient-dev
   golang-github-openshift-imagebuilder-dev
   golang-github-samalba-dockerclient-dev kubernetes-node subuser
   whalebuilder
 Installations reported by Popcon: 3262
 Bug Report URL: https://bugs.debian.org/908868

   ebib (#952810), requested 26 days ago
 Description: BibTeX database manager for Emacs
 Installations reported by Popcon: 36
 Bug Report URL: https://bugs.debian.org/952810

   ejabberd (#767874), requested 1970 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-default-contacts ejabberd-mod-default-rooms
   ejabberd-mod-deny-omemo ej

Re: What to do when DD considers policy to be optional? [kubernetes]

[Paul Wise]

On Thu, Mar 26, 2020 at 8:30 PM Christian Kastner wrote:

> [Well, technically, you could use your own lawyer to perform the due
> diligence and have them submit any necessary changes to the BTS, but I
> think it's safe to assume that that is a theoretical example.]

The OSI started ClearlyDefined, which aims to do just that (and more)
for both Debian and other communities, using automated tools
(scanCode) and human curation of the results.

https://clearlydefined.io/?type=debsrc&sort=releaseDate&sortDesc=true
https://clearlydefined.io/about
https://docs.clearlydefined.io/contributing-data
https://wiki.debian.org/CopyrightReviewTools
https://github.com/nexB/scancode-toolkit/
https://fosdem.org/2020/schedule/event/rust_license_clearlydefined/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise