Re: suspending FSF contributor agreements with immediate effect

2020-01-15 Thread Daniel Pocock



On 15/01/2020 04:51, Mike Gerwitz wrote:
> On Tue, Jan 14, 2020 at 15:39:30 +0100, Daniel Pocock wrote:
>> I will continue contributing code to (names of projects) retaining all
>> intellectual property rights personally during this suspension of the
>> agreement.
> 
> Please note that the GNU Project and the FSF avoid use of the term
> "intellectual property":
> 
>   https://www.gnu.org/philosophy/words-to-avoid.en.html#IntellectualProperty
> 
>> I also wish to notify you that my contributor agreement will be
>> reinstated when FSF makes a satisfactory commitment about leadership and
>> governance issues.  I have not yet decided what will constitute a
>> satisfactory commitment, for now, I will review the proposals put
>> forward by FSF and I may contribute further criteria as the situation
>> evolves.
> 
> The FSF has no authority over the GNU Project, and so this isn't a
> useful statement.

The assignment is to the FSF though.

> GNU requires copyright assignments for all substantial changes from
> contributors to GNU packages with copyrights assigned to the FSF.  By

There is a big difference between

a) licensing work under the GPL
b) assinging copyright to another party (e.g. FSF)

People can still do (a), publish their work with a GPL license without
doing (b).  They can suspend (b), so the code is visible and ready to be
accepted.

People could also maintain a parallel repository with all the embargoed
code ready to merge.

> suspending that, your contributions will not be able to be accepted, and
> you're predicating the assignment on a condition that is not possible
> for the FSF to meet.
> 
> I understand there are frustrations all around, but attempting to force
> change raises tensions rather than resolving them.

The GPL itself attempts to force change on people.  People say the
impact of such a license is viral.

The suspension letter template aims to have a similar effect as the GPL,
but rather than impacting code, it impacts the organization structures.



Re: suspending FSF contributor agreements with immediate effect

2020-01-15 Thread Nathan Sidwell

On 1/14/20 7:37 PM, Daniel Pocock wrote:



On 15/01/2020 01:19, Joel Sherrill wrote:



On Tue, Jan 14, 2020 at 5:48 PM Daniel Pocock mailto:dan...@pocock.pro>> wrote:



 On 15/01/2020 00:42, Joel Sherrill wrote:
 > This will create a lot of paperwork which puts GNU project
 maintainers in a
 > very bad position. In practice, 
 this is the sad reality of an organization where volunteers have not
 been registered as equal members with equal votes in the corporate
 entity, FSF, Inc


You are missing the point entirely. This is not about representation or
voting,
this is about the burden of daily activities.



I agree those issues are important and burdensome for the project
maintainers.

Nonetheless, contributors have a right to decide who owns the
intellectual property.


*contributors* have already made that decision -- they filed the 
paperwork and *continue to* contribute.  It would be irresponsible for 
someone with an assignment, to revoke that assignment /and/ continue 
contributing patches.


You could decide you no longer wished to contribute to an FSF project, 
and no longer submit patches to it (in addition to any explicit 
public/private message you might send).


AFAICT there is no example of adding a revocation to the copyright.list 
file.  I never noticed one.  I noticed that my individual assignment, 
including an employer assignment, never had a note later when I changed 
employers and ended up covered by the employer's blanket assignment. 
The closest it gets are assignments that are explicitly time-limited 
from the get go -- they have a termination date when assigned.


Now, that's not to suggest your idea is inherently bad.  The thought had 
occurred to me too -- stop contributing.  But I decided things would 
have to be really dire to do that.


nathan

--
Nathan Sidwell



Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Ruben Safir
On 1/14/20 9:39 AM, Daniel Pocock wrote:
> 
> FSF will not change unless somebody gives them a strong reason to change.
> 
> For example, if GNU developers write the following email to FSF, that
> will bring change.
> 
> Each developer needs to make their own decision if they will send the
> email.  RMS has previously suggested he would not like people to
> completely abandon the agreements.  The email template below is only for
> a conditional suspension of the agreement.  Nobody can tell you to
> continue assigning[1] your rights to FSF if you want to wait for more
> clarity about FSF's future.
> 
> You can still keep coding during the suspension: if a significant
> quantity of code is published and virtually embargoed like this, it
> creates an incentive for FSF to satisfy those people and gain rights
> over that code.
> 
> Regards,
> 
> Daniel Pocock
> --
> Debian Developer
> https://danielpocock.com
> 
> 
> 
> To: John Sullivan 
> CC: (relevant project mailing lists)
> Subject: suspension of contributor agreement
> 
> Dear John,
> 
> I am writing to suspend my FSF / GNU project contributor agreement[1]
> signed __/__/
> 
> I will continue contributing code to (names of projects) retaining all
> intellectual property rights personally during this suspension of the
> agreement.
> 


Laughable.

That would just get you locked out of all GNU projects, probably
permanently.  If you retain your rights, you can not contribute.


Watch who you give the middle finger too, it might be the mirror


-- 
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com
DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

http://www.nylxs.com - Leadership Development in Free Software
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013



Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Daniel Pocock



On 15/01/2020 01:19, Joel Sherrill wrote:
> 
> 
> On Tue, Jan 14, 2020 at 5:48 PM Daniel Pocock  > wrote:
> 
> 
> 
> On 15/01/2020 00:42, Joel Sherrill wrote:
> > This will create a lot of paperwork which puts GNU project
> maintainers in a 
> > very bad position. In practice, 
> this is the sad reality of an organization where volunteers have not
> been registered as equal members with equal votes in the corporate
> entity, FSF, Inc
> 
> 
> You are missing the point entirely. This is not about representation or
> voting,
> this is about the burden of daily activities.


I agree those issues are important and burdensome for the project
maintainers.

Nonetheless, contributors have a right to decide who owns the
intellectual property.

The decision of the contributor/developer comes first as they are the
one contributing their time and skill without any payment whatsoever.
Everything else has to be secondary to that.

Regards,

Daniel



Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Daniel Pocock



On 15/01/2020 00:42, Joel Sherrill wrote:
> This will create a lot of paperwork which puts GNU project maintainers in a 
> very bad position. In practice, 
this is the sad reality of an organization where volunteers have not
been registered as equal members with equal votes in the corporate
entity, FSF, Inc




Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Daniel Pocock



On 14/01/2020 22:31, Carlos O'Donell wrote:
> On Tue, Jan 14, 2020 at 10:39 AM Daniel Pocock  wrote:
>> FSF will not change unless somebody gives them a strong reason to change.
>>
>> For example, if GNU developers write the following email to FSF, that
>> will bring change.
>>
>> Each developer needs to make their own decision if they will send the
>> email.  RMS has previously suggested he would not like people to
>> completely abandon the agreements.  The email template below is only for
>> a conditional suspension of the agreement.  Nobody can tell you to
>> continue assigning[1] your rights to FSF if you want to wait for more
>> clarity about FSF's future.
>>
>> You can still keep coding during the suspension: if a significant
>> quantity of code is published and virtually embargoed like this, it
>> creates an incentive for FSF to satisfy those people and gain rights
>> over that code.
> 
> I can empathize with your frustration over the current state of
> affairs and the lack of transparency (including timely updates to
> members of the FSF).
> 
> However, what you propose is seems like a measure of last resort.
> 

That is a matter of perspective

In France, la grève is the go-to solution


> May I encourage you to help the current GNU Project volunteers working
> to define a governance model that is organized from the bottom-up? A
> governance model that rallies around the community to engage them in
> the goals of the GNU Project, not just the outcomes.

My proposal is not intended to distract from that. Rather, it is
intended to help focus people's minds.

> We absolutely need people like you to promote the goals of the GNU Project.
> 

Thanks, I really appreciate your positive attitude.



Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Mike Gerwitz
On Tue, Jan 14, 2020 at 15:39:30 +0100, Daniel Pocock wrote:
> I will continue contributing code to (names of projects) retaining all
> intellectual property rights personally during this suspension of the
> agreement.

Please note that the GNU Project and the FSF avoid use of the term
"intellectual property":

  https://www.gnu.org/philosophy/words-to-avoid.en.html#IntellectualProperty

> I also wish to notify you that my contributor agreement will be
> reinstated when FSF makes a satisfactory commitment about leadership and
> governance issues.  I have not yet decided what will constitute a
> satisfactory commitment, for now, I will review the proposals put
> forward by FSF and I may contribute further criteria as the situation
> evolves.

The FSF has no authority over the GNU Project, and so this isn't a
useful statement.

GNU requires copyright assignments for all substantial changes from
contributors to GNU packages with copyrights assigned to the FSF.  By
suspending that, your contributions will not be able to be accepted, and
you're predicating the assignment on a condition that is not possible
for the FSF to meet.

I understand there are frustrations all around, but attempting to force
change raises tensions rather than resolving them.

-- 
Mike Gerwitz


signature.asc
Description: PGP signature


Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Joel Sherrill
On Tue, Jan 14, 2020 at 5:48 PM Daniel Pocock  wrote:

>
>
> On 15/01/2020 00:42, Joel Sherrill wrote:
> > This will create a lot of paperwork which puts GNU project maintainers
> in a
> > very bad position. In practice, 
> this is the sad reality of an organization where volunteers have not
> been registered as equal members with equal votes in the corporate
> entity, FSF, Inc
>

You are missing the point entirely. This is not about representation or
voting,
this is about the burden of daily activities.

Before work can be submitted to any project (GNU or otherwise) which has
a contribution form, there must be a check before merging to ensure the
submitter has active paperwork. AFAIK for Apache, Eclipse, GNU, CLANG,
Go, etc, this is a simple "Is person X on the list? Yes/No". Once a
maintainer
sees yes, that is a constant Yes for in the future.

With your on again/off again proposal, the project maintainer must check
EVERYTIME they merge a contribution from ANYONE.Anyone can change
their mind at any time and repeatedly.

The paperwork burden on FSF is bad but the impact on maintainers is worse.
[FWIW I

You seem to have missed the change from a simple Yes/No condition
that never changes after the No -> Yes transition to a condition which
must be evaluated EVERYTIME a submission is made.

This really complicates things for those doing the day to day work.

--joel
RTEMS


Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Joel Sherrill
This will create a lot of paperwork which puts GNU project maintainers in a
very bad position. In practice, once someone is known to have done
assignment paperwork, there is no reason to check if they have an active
assignment. This assumption would no longer be valid.

Worse, there could be multiple suspensions and reinstatements. This would
result in periods of "ok to merge" and "not ok to merge" of varying lengths
repeated.

Computationally, this means "OK to assignment" is not a boolean condition
that never changes after going true but a value that is dependent on some
point in
time. How would that precise range of time be managed by the FSF? a
maintainer would have to check that the submission occurred in an
"ok to merge" period. What would the timestamp be that needed to be
compared to the "valid assignment in place" method? How would the
maintainer know?

Assuming this happened, maintainers are burdened by checking that the
assignment is OK and if any mistake is made, there is a copyright assignment
issue which could submarine the project.

If you want to stop submitting code in protest, feel free to do so. Send a
letter
to the FSF telling you why you aren't submitting code. Post it anywhere you
want. But please, do not punish your fellow GNU project maintainers who
will be burdened by having the copyright assignment in force check process
changed forever.

Some of this discussion was about documenting the FSF and GNU Project
processes
and making them well-known. I'm all for that. but please don't burden
maintainers
forever just to make a point.

Thanks.

--joel sherrill
RTEMS, GCC, Binutils, GDB, Newlib

On Tue, Jan 14, 2020 at 9:39 AM Daniel Pocock  wrote:

>
> FSF will not change unless somebody gives them a strong reason to change.
>
> For example, if GNU developers write the following email to FSF, that
> will bring change.
>
> Each developer needs to make their own decision if they will send the
> email.  RMS has previously suggested he would not like people to
> completely abandon the agreements.  The email template below is only for
> a conditional suspension of the agreement.  Nobody can tell you to
> continue assigning[1] your rights to FSF if you want to wait for more
> clarity about FSF's future.
>
> You can still keep coding during the suspension: if a significant
> quantity of code is published and virtually embargoed like this, it
> creates an incentive for FSF to satisfy those people and gain rights
> over that code.
>
> Regards,
>
> Daniel Pocock
> --
> Debian Developer
> https://danielpocock.com
>
>
>
> To: John Sullivan 
> CC: (relevant project mailing lists)
> Subject: suspension of contributor agreement
>
> Dear John,
>
> I am writing to suspend my FSF / GNU project contributor agreement[1]
> signed __/__/
>
> I will continue contributing code to (names of projects) retaining all
> intellectual property rights personally during this suspension of the
> agreement.
>
> I also wish to notify you that my contributor agreement will be
> reinstated when FSF makes a satisfactory commitment about leadership and
> governance issues.  I have not yet decided what will constitute a
> satisfactory commitment, for now, I will review the proposals put
> forward by FSF and I may contribute further criteria as the situation
> evolves.
>
> All work completed during this suspension will be assigned
> retrospectively to FSF when the conditions of reinstatement are satisfied.
>
> Sincerely,
>
> Developer
>
>
> 1. https://www.gnu.org/prep/maintain/maintain.html#Legal-Matters
>
>


Re: suspending FSF contributor agreements with immediate effect

2020-01-14 Thread Carlos O'Donell
On Tue, Jan 14, 2020 at 10:39 AM Daniel Pocock  wrote:
> FSF will not change unless somebody gives them a strong reason to change.
>
> For example, if GNU developers write the following email to FSF, that
> will bring change.
>
> Each developer needs to make their own decision if they will send the
> email.  RMS has previously suggested he would not like people to
> completely abandon the agreements.  The email template below is only for
> a conditional suspension of the agreement.  Nobody can tell you to
> continue assigning[1] your rights to FSF if you want to wait for more
> clarity about FSF's future.
>
> You can still keep coding during the suspension: if a significant
> quantity of code is published and virtually embargoed like this, it
> creates an incentive for FSF to satisfy those people and gain rights
> over that code.

I can empathize with your frustration over the current state of
affairs and the lack of transparency (including timely updates to
members of the FSF).

However, what you propose is seems like a measure of last resort.

May I encourage you to help the current GNU Project volunteers working
to define a governance model that is organized from the bottom-up? A
governance model that rallies around the community to engage them in
the goals of the GNU Project, not just the outcomes.

We absolutely need people like you to promote the goals of the GNU Project.

Cheers,
Carlos.