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 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.
We have a policy process and someone (I'll get to it eventually if no one
beats me to it) should start the process to change this.
There's an open policy bug about if the license grant should be required in
debian/copyright or not that we're (I know, we're late) finally looking into
establishing an FTP Team position on.
I don't think anyone is looking to make this harder than it has to be, but I
don't think the project taking the position that it's OK to willfully ignore
license requirements is a good plan.
Scott KAttachment:
signature.asc
Description: This is a digitally signed message part.