Re: Can Debian packaging changes require a CLA?

2020-02-17 Thread Wouter Verhelst
On Mon, Feb 17, 2020 at 09:45:32AM +0100, Florian Weimer wrote:
> * Wouter Verhelst:
> 
> > On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
> >> It would also make the package unmaintainable if the original packer
> >> loses interest, so the package would not be suitable for inclusion in
> >> a stable release.
> >
> > Eh, it doesn't?
> >
> > A CLA is "you're allowed to change this, but if you want us to accept it
> > then you have to give us these rights, otherwise we'll reject your
> > contribution".
> 
> Ordinarily, yes.
> 
> But I think here the request was that Debian would only make changes
> (“packaging changes”) if they were made by someone who has been
> subjected to a CLA.

I didn't interpret it this way. And even if that is what the question
was, I don't think it's a valid question in Debian's context :-)

There is no ownership of a package in Debian other than "X is currently
the maintainer, and we don't usually take packages away without cause".
But if "X" doesn't actually continue maintaining a package properly,
then NMUs (in most cases) and/or package hijacks (in more extreme
circumstances) are part of our procedures and "not maintaining" would be
plenty of cause for such an action.

The package as part of Debian will remain, and can be modified by anyone
in Debian, as per the license applied to it if it is in main. Without a
signed CLA, such changes just won't be applied to the *current*
maintainer's git repository, but that doesn't matter as far as Debian is
concerned; if the original maintainer loses interest, then the
CLA-requiring git repository becomes utterly irrelevant to Debian.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



Re: Can Debian packaging changes require a CLA?

2020-02-17 Thread Florian Weimer
* Wouter Verhelst:

> On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
>> It would also make the package unmaintainable if the original packer
>> loses interest, so the package would not be suitable for inclusion in
>> a stable release.
>
> Eh, it doesn't?
>
> A CLA is "you're allowed to change this, but if you want us to accept it
> then you have to give us these rights, otherwise we'll reject your
> contribution".

Ordinarily, yes.

But I think here the request was that Debian would only make changes
(“packaging changes”) if they were made by someone who has been
subjected to a CLA.



Re: Can Debian packaging changes require a CLA?

2020-02-17 Thread Wouter Verhelst
On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
> It would also make the package unmaintainable if the original packer
> loses interest, so the package would not be suitable for inclusion in
> a stable release.

Eh, it doesn't?

A CLA is "you're allowed to change this, but if you want us to accept it
then you have to give us these rights, otherwise we'll reject your
contribution".

If the original packager loses interest, that becomes moot, because he's
not going to accept *any* patches anymore, anyway. You can fork, and you
can do whatever you want from then on.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22



Re: Can Debian packaging changes require a CLA?

2020-02-15 Thread Ben Hutchings
On Fri, 2020-02-14 at 15:46 +, Dimitri John Ledkov wrote:
> Can a Debian Package Maintainer require CLA for accepting packaging
> changes and distro patches to be uploaded into Debian itself?
> 
> (case in point, debian maintainer & upstream wear the same hat, and
> maintain upstream code & packaging on github.com, under a company org
> with a CLA bot, rejecting debian/* merge proposals until CLA is
> signed)
> 
> I didn't find things specifically about this in the policy and/or in
> the dfsg-faq and the three classic tests (desert island / dissident /
> tentacles of evil) do not fit the bill quite right.

The DFSG is about what rights owners allow downstream recipients to do,
and not about whether or how they accept contributions back.  And
generally maintainers can follow their own policies for accepting or
rejecting patches.  So I don't think there's anything explicit that
rules this out.

Since NMUs are allowed in some circumstances, there can be an implicit
conflict with such a policy, though as Matthew Garrett pointed out
there are different kinds of CLA.

The Developer's Certificate of Origin can be asserted by someone other
than the original author, and I would feel confident in representing to
upstream that a change made by another DD through an NMU was intended
to be released under the project's stated license.  But if an upstream
project requires a CLA to be executed by every original contributor, I
don't think it is viable to keep the Debian packaging in the upstream
project's repository.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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


Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Bernd Zeimetz
On 2/14/20 4:46 PM, Dimitri John Ledkov wrote:
> Can a Debian Package Maintainer require CLA for accepting packaging
> changes and distro patches to be uploaded into Debian itself?

you can always fork the current packaging and upload/NMU it.
Send patches to the BTS or open an issue in github, pointing to your fork.

Its up to the maintainer then to figure out on how to integrate your
patches and up to them to fight their CLA/lawyers to accept your
changes. Or they'll have to remove your changes and do the same work
again... whatever works.



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



Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Sam Hartman
In this instance, I'd submit a patch to the bts and see what happens.

--Sam



Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Florian Weimer
* Andrey Rahmatullin:

> On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
>> It would also make the package unmaintainable if the
>> original packer loses interest, so the package would not be suitable
>> for inclusion in a stable release.

> Can you explain why do you think so?
> If a new maintainer wants to use a git repo to mainatin it, they can make
> a new one.

Only if the CLA requirement does not bind the Debian project.



Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Andrey Rahmatullin
On Fri, Feb 14, 2020 at 06:38:00PM +0100, Florian Weimer wrote:
> It would also make the package unmaintainable if the
> original packer loses interest, so the package would not be suitable
> for inclusion in a stable release.
Can you explain why do you think so?
If a new maintainer wants to use a git repo to mainatin it, they can make
a new one.

-- 
WBR, wRAR


signature.asc
Description: PGP signature


Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Florian Weimer
* Scott Kitterman:

> On February 14, 2020 3:46:18 PM UTC, Dimitri John Ledkov  
> wrote:
>>Can a Debian Package Maintainer require CLA for accepting packaging
>>changes and distro patches to be uploaded into Debian itself?
>>
>>(case in point, debian maintainer & upstream wear the same hat, and
>>maintain upstream code & packaging on github.com, under a company org
>>with a CLA bot, rejecting debian/* merge proposals until CLA is
>>signed)

I don't see what's wrong with that.  Just because there's a debian/
directory doesn't make it Debian.

>>I didn't find things specifically about this in the policy and/or in
>>the dfsg-faq and the three classic tests (desert island / dissident /
>>tentacles of evil) do not fit the bill quite right.

> Maintainers have substantial discretion regarding what contributions
> they accept.  "I don't want a patch that's not upstreamable" is not
> uncommon.  Mostly your question seems to be a variant of that
> concern.

I tend to agree, but we do not have archive-level mechanisms to
enforce that and prevent NMUs.

Depending on the nature of the CLA, requiring it would border on a
DFSG violation.  It would also make the package unmaintainable if the
original packer loses interest, so the package would not be suitable
for inclusion in a stable release.

On the other hand, we have this in the request-tracker4 package:

# CONTRIBUTION SUBMISSION POLICY:
#
# (The following paragraph is not intended to limit the rights granted
# to you to modify and distribute this software under the terms of
# the GNU General Public License and is only of importance to you if
# you choose to contribute your changes and enhancements to the
# community by submitting them to Best Practical Solutions, LLC.)
#
# By intentionally submitting any modifications, corrections or
# derivatives to this work, or any other work intended for use with
# Request Tracker, to Best Practical Solutions, LLC, you confirm that
# you are the copyright holder for those contributions and you grant
# Best Practical Solutions,  LLC a nonexclusive, worldwide, irrevocable,
# royalty-free, perpetual, license to use, copy, create derivative
# works based on those contributions, and sublicense and distribute
# those contributions and any derivatives thereof.

I consider this an attempt at a CLA because of the asymmetric
licensing grant, but it's probably too weak for most people who care
about CLAs.



Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Scott Kitterman



On February 14, 2020 3:46:18 PM UTC, Dimitri John Ledkov  
wrote:
>Can a Debian Package Maintainer require CLA for accepting packaging
>changes and distro patches to be uploaded into Debian itself?
>
>(case in point, debian maintainer & upstream wear the same hat, and
>maintain upstream code & packaging on github.com, under a company org
>with a CLA bot, rejecting debian/* merge proposals until CLA is
>signed)
>
>I didn't find things specifically about this in the policy and/or in
>the dfsg-faq and the three classic tests (desert island / dissident /
>tentacles of evil) do not fit the bill quite right.

There's no requirement in Debian to use any VCS to upload a package, so 
policies related to accepting changes in any VCS are orthogonal to what's 
acceptable for the archive.

Maintainers have substantial discretion regarding what contributions they 
accept.  "I don't want a patch that's not upstreamable" is not uncommon.  
Mostly your question seems to be a variant of that concern.

For packaging changes I think it's not as clear, but I don't think there're any 
rules.

I have, in the past, resorted to providing upstream feedback along the lines of 
"On line 76 of file abc.py, change the value 256 to 255” to avoid providing a 
patch that would have triggered a CLA requirement.  If this is an actual 
problem in the archive and not merely theoretical, I'd suggest a work-around 
something like that.

That said, I think it's in poor taste at best.

Scott K



Re: Can Debian packaging changes require a CLA?

2020-02-14 Thread Roberto C . Sánchez
On Fri, Feb 14, 2020 at 03:46:18PM +, Dimitri John Ledkov wrote:
> Can a Debian Package Maintainer require CLA for accepting packaging
> changes and distro patches to be uploaded into Debian itself?
> 
> (case in point, debian maintainer & upstream wear the same hat, and
> maintain upstream code & packaging on github.com, under a company org
> with a CLA bot, rejecting debian/* merge proposals until CLA is
> signed)
> 
> I didn't find things specifically about this in the policy and/or in
> the dfsg-faq and the three classic tests (desert island / dissident /
> tentacles of evil) do not fit the bill quite right.
> 
Have you considered it this way?  As Debian maintainer of some package
you are able to decide whether or not you accept contributions to that
package based on your own criteria (or your employer's in this case)?

If the criteria are too onerous such that they discourage contributions
then there is a possibility that eventually someone may come along and
repackage it under a different name; essentially your criteria could
precipitate a fork.

In principle, there seems to be nothing that would prevent such a
requirement (i.e., a CLA), but in practice it is likely to irk potential
contributors.

Regards,

-Roberto

-- 
Roberto C. Sánchez