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