Question about section 11. Termination

[Joshua Gay]

Let's say I lose my rights under §11 to the Covered Work. Could I ask a
friend to give me a copy of the same Covered Work under the GNU GPL
version 3 (via section 10) and then redistribute the covered work under
the GNU GPL version 3?

Maybe §11 could be explicit about what "new licenses" means, perhaps
something along the lines of: "Termination of Your rights disqualifies
You from receiving new licenses covering the Received Work (including
any future version of this license or those listed in section 10 of this
license)."

Josh

[Richard Fontana]

On 01/27/2013 01:52 AM, Joshua Gay wrote:
>  Let's say I lose my rights under §11 to the Covered Work. Could I
> ask a
>  friend to give me a copy of the same Covered Work under the GNU GPL
>  version 3 (via section 10) and then redistribute the covered work under
>  the GNU GPL version 3? 
This is a *very* interesting question. It raises a problem that arises
much more generally in free software. It is what I call the "magic
relicensing problem". The general approach has been to sweep this
under the rug.

It also relates closely to a question @vanden was raising on identi.ca
- he asked whether the basic copyleft requirement in section 5
conflicted with section 10.

The "right answer" to your question has to be 'no'; the question is
how to get there. One approach is to do nothing since (a) your
hypothetical isn't realistic, after all, and (b) the solution I'm
thinking of might destroy the nice, simple signal section 10 gives
about GPL/AGPL compatibility and put us in GPLv3 (or Creative
Commonsish) stylistic territory.

The solution I'm thinking of is that section 10 should be limited to
'Derived Works'. After all, why would one ever need to distribute
copyleft-next under GPL/AGPL other than in what the FSF, certainly,
would consider a 'Derived Work' scenario (using the terminology of
copyleft-next -- a 'work based on the Program' or 'modified version'
in GPLv3 parlance). Going further, maybe section 10 should be folded
into section 5. You can Distribute a Derived Work under one of the
following licenses:
i) this License
ii) a Later Version (unless We have explicitly said you can't)
iii) GPLv2, AGPLv3, or later versions

If that were the case, then (let's say I'm the copyleft-next upstream
licensor) your friend can't give you an unmodified version of the same
work under GPLv3. He or she can give you a 'Derived Work' licensed
under GPLv3. However, I don't think this means I am giving *you* a
GPLv3 license as to what I wrote.

(Think of similar facts, except my code is BSD-licensed -- and suppose
violaton of the BSD license has results approximately as harsh as
under copyleft-next and GPLv3.)

>  Maybe §11 could be explicit about what "new licenses"
> means, perhaps
>  something along the lines of: "Termination of Your rights disqualifies
>  You from receiving new licenses covering the Received Work (including
>  any future version of this license or those listed in section 10 of this
>  license)." 
That's kind of like another way to get at the solution I'm suggesting.

This definitely goes into the Nonexistent Issue Tracker. I think
whether to do something about this depends mainly on how ugly the
result is.

 - RF

[Richard Fontana]

On 01/27/2013 02:50 AM, Richard Fontana wrote:
>  On 01/27/2013 01:52 AM, Joshua Gay wrote:
> > Let's say I lose my rights under §11 to the Covered Work. Could I ask a
> > friend to give me a copy of the same Covered Work under the GNU GPL
> > version 3 (via section 10) and then redistribute the covered work under
> > the GNU GPL version 3?
>  
>  This is a *very* interesting question. It raises a problem that arises
>  much more generally in free software. It is what I call the "magic
>  relicensing problem". The general approach has been to sweep this
>  under the rug.
>  
>  It also relates closely to a question @vanden was raising on identi.ca
>  - he asked whether the basic copyleft requirement in section 5
>  conflicted with section 10. 
[...]
>  The solution I'm thinking of is that section 10 should be limited
> to
>  'Derived Works'. After all, why would one ever need to distribute
>  copyleft-next under GPL/AGPL other than in what the FSF, certainly,
>  would consider a 'Derived Work' scenario (using the terminology of
>  copyleft-next -- a 'work based on the Program' or 'modified version'
>  in GPLv3 parlance). Going further, maybe section 10 should be folded
>  into section 5. You can Distribute a Derived Work under one of the
>  following licenses:
>  i) this License
>  ii) a Later Version (unless We have explicitly said you can't)
>  iii) GPLv2, AGPLv3, or later versions
>  
>  If that were the case, then (let's say I'm the copyleft-next upstream
>  licensor) your friend can't give you an unmodified version of the same
>  work under GPLv3. He or she can give you a 'Derived Work' licensed
>  under GPLv3. However, I don't think this means I am giving *you* a
>  GPLv3 license as to what I wrote. 
Pam Chestek raised a related issue in a github pull request:
"Based on paragraph 6, the Received Work is licensed to the
distributee under copyleft-next, so it's only the Derived Work that
would be under an alternative license. And maybe not even really that;
it might be just the delta between the Received Work and the Derived
Work that would be under the new license. But I concede that my
change, although I believe more accurate, might create confusion."

I am tracking the underlying issue here on github at
https://github.com/richardfontana/copyleft-next/issues/30

- RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Bradley M. Kuhn]

I apologize that my job at Conservancy and volunteer work at FSF has made it
impossible for me to fit in volunteer work to help copyleft-next.  However, I
find it quite disturbing that the project is returning to GitHub.  I've
submitted this merge request to prevent the slippery slope toward proprietary
solutions that copyleft-next appears to be on.  HBR should stand up for the
software freedom of users.

Please merge:

  https://gitorious.org/copyleft-next/copyleft-next/merge_requests/29

   -- bkuhn

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Stephen Michael Kellat]

On 02/07/2013 09:28 PM, Bradley M. Kuhn wrote:
>  I apologize that my job at Conservancy and volunteer work at FSF has
> made it
>  impossible for me to fit in volunteer work to help copyleft-next.  However, I
>  find it quite disturbing that the project is returning to GitHub.  I've
>  submitted this merge request to prevent the slippery slope toward proprietary
>  solutions that copyleft-next appears to be on.  HBR should stand up for the
>  software freedom of users.
>
>  Please merge:
>
>    https://gitorious.org/copyleft-next/copyleft-next/merge_requests/29
>
>     -- bkuhn
>  _______________________________________________
>  copyleft-next mailing list
>  copyleft-next(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/copyleft-next 
Bradley,

Please do also disclose a summary of your sidebar discussion with
Richard Fontana as well as Claes Wallin that appears to be happening on
Identica and other federated StatusNet sites.  That appears to be
germane to this merge request and yet not necessarily represented
on-list.  This e-mail list remains our primary means of record
communications relative to the project.

I am minded at this point to ask that the folks who find the need to use
GitHub please make themselves heard on list within our primary record of
communications.  The mailing list has functioned quite well as a de
facto issue tracker thus far and I do not enjoy the notion of having to
chase down discussion across multiple fora.

Stephen Michael Kellat

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Thu, Feb 07, 2013 at 10:14:17PM -0500, Stephen Michael Kellat wrote:
>  I am minded at this point to ask that the folks who find the need to
> use
>  GitHub please make themselves heard on list within our primary record of
>  communications.  The mailing list has functioned quite well as a de
>  facto issue tracker thus far and I do not enjoy the notion of having to
>  chase down discussion across multiple fora. 
This is a good point. I am the one at fault here. 

I have assumed from the get-go that some people would wish to
contribute via GitHub, hence my faithful mirroring of the Gitorious
repository there. Yesterday I made convenience use of the GitHub issue
tracker. This was in response to a rather unique situation, in which
one GitHub contributor put a large set of useful changes, with a large
set of useful comments, in one pull request. (The contributor first
attempted to use Gitorious and found it too difficult.) For
issue-management purposes I began to record individual issues from
this pull request in the GitHub issue tracker. What I'll do from now
on, and until some 'real' issue tracking solution is adopted, is avoid
any temptation to use the GitHub issue tracker and instead use the
mailing list.

- RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Bradley M. Kuhn]

Stephen Michael Kellat wrote at 22:14 (EST) on Thursday:
>  Please do also disclose a summary of your sidebar discussion with
>  Richard Fontana as well as Claes Wallin that appears to be happening
>  on Identica and other federated StatusNet sites. 
Stephen, since that discussion is public, I am pretty sure it's not an
HBR violation to discuss copyleft-next on identi.ca, since it's a public
forum.  But I see your point (more on that below).

Meanwhile, my understanding of the identi.ca conversation is this:

 * Pam Chestek got copyleft-next off GitHub, and nothing there told her
   GitHub wasn't the canonical location for participation (this should
   be fixed immediately, IMO.  I realize the README says it, but there
   should be something in big bold letters on GitHub: THIS IS A MIRROR
   ONLY.  DO NOT SUBMIT PULL REQUESTS AND ISSUES HERE.  USE MAILING LIST
   AND GITORIOUS [or whatever solution Fontana decides].
   Ideally, the pull request/issue tracker should be turned off.

 * Pam realized, probably after getting the checkout and seeing the
   readme, that Gitorious was preferred.

 * Pam couldn't submit changes via Gitorious (at that point, presumably
   her tracking branches were all pointed at GitHub, which was probably
   part of the problem).

 * Fontana opened an issue on GitHub to collaborate with Pam on the
   issue she raised.

 * I theorized that this marked a distributing occurrence, since GitHub
   instance of copyleft-next seemed to be active again instead of just being a
   mirror.  I complained heavily to Fontana about it, and Fontana
   countered with what I believed were incorrect analogies to GPLv3
   drafting process (i.e.,  I thought copyleft-next was trying to avoid
   those, anyway!)


Pam and Fontana, is that summary accurate from your point of view?

>  I am minded at this point to ask that the folks who find the need to
>  use GitHub please make themselves heard on list within our primary
>  record of communications.  The mailing list has functioned quite well
>  as a de facto issue tracker thus far and I do not enjoy the notion of
>  having to chase down discussion across multiple fora. 
This is a good point.  I'll try to avoid using identi.ca to discuss
copyleft-next in future.

I do agree that having to follow GitHub, identi.ca, Gitorious, and this
mailing list is annoying.  While HBR doesn't prohibit it, I suggest we
all work to restrain ourselves to use *only* the mailing list and
Gitorious and nothing else for now, to avoid people having to track so
many fora.

I have *so* little time for copyleft-next, thus I really am swayed by
Stephen's point here.  I had assumed that checking the git log from
Gitorious and reading mailing list traffic would be adequate any time I
had a moment to check in with copyleft-next.  If that's not true:
because of use of GitHub, identi.ca, or any other fora being used, we
may want to nip it -- not because it's an HBR violation or even because
one of those solutions is proprietary  (identi.ca isn't after all), but
because it makes it difficult to follow a conversation across so many
fora.

I hadn't realized how big of a problem that is for people who have
limited time for the project until Stephen raised it.  Thanks for
raising that point.
-- 
   -- bkuhn

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Pamela Chestek]

The summary is accurate from my viewpoint. I knew months ago that Richard
had put the repository on Github, but the knowledge was old and I didn't
realize bad. So after FOSDEM I went straight to Github. It would have taken
really big red flags for me to wake up and realize that I was in the wrong
place. I ultimately figured it out because of the reference to Gitorious in
the license itself.

I was wrong in my dent when I said I downloaded from Github; I didn't, I
edited right on Github. Upon realizing my error, I then dutifully
downloaded from Gitorious and started over. As explained when I submitted
to Github, the problem was that I couldn't figure out how to get the
changes from my computer to Gitorious to ask for a merge, and I also
suspect I probably also have it all configured wrong on my computer anyway.
At that point I just gave up. I figured it was going to take me yet several
more hours to figure it out, and while I considered it a worthwhile effort,
I didn't have that time at the moment and wanted to wrap up my task and
provide feedback after FOSDEM in a timely manner. Therefore the fateful
decision to submit on Github.


Pam


On Fri, Feb 8, 2013 at 8:36 AM, Bradley M. Kuhn <bkuhn(a)ebb.org&gt; wrote:

>  Stephen Michael Kellat wrote at 22:14 (EST) on Thursday:
>  > Please do also disclose a summary of your sidebar discussion with
>  > Richard Fontana as well as Claes Wallin that appears to be happening
>  > on Identica and other federated StatusNet sites.
>
>  Stephen, since that discussion is public, I am pretty sure it's not an
>  HBR violation to discuss copyleft-next on identi.ca, since it's a public
>  forum.  But I see your point (more on that below).
>
>  Meanwhile, my understanding of the identi.ca conversation is this:
>
>   * Pam Chestek got copyleft-next off GitHub, and nothing there told her
>     GitHub wasn't the canonical location for participation (this should
>     be fixed immediately, IMO.  I realize the README says it, but there
>     should be something in big bold letters on GitHub: THIS IS A MIRROR
>     ONLY.  DO NOT SUBMIT PULL REQUESTS AND ISSUES HERE.  USE MAILING LIST
>     AND GITORIOUS [or whatever solution Fontana decides].
>     Ideally, the pull request/issue tracker should be turned off.
>
>   * Pam realized, probably after getting the checkout and seeing the
>     readme, that Gitorious was preferred.
>
>   * Pam couldn't submit changes via Gitorious (at that point, presumably
>     her tracking branches were all pointed at GitHub, which was probably
>     part of the problem).
>
>   * Fontana opened an issue on GitHub to collaborate with Pam on the
>     issue she raised.
>
>   * I theorized that this marked a distributing occurrence, since GitHub
>     instance of copyleft-next seemed to be active again instead of just
>  being a
>     mirror.  I complained heavily to Fontana about it, and Fontana
>     countered with what I believed were incorrect analogies to GPLv3
>     drafting process (i.e.,  I thought copyleft-next was trying to avoid
>     those, anyway!)
>
>
>  Pam and Fontana, is that summary accurate from your point of view?
>
>  > I am minded at this point to ask that the folks who find the need to
>  > use GitHub please make themselves heard on list within our primary
>  > record of communications.  The mailing list has functioned quite well
>  > as a de facto issue tracker thus far and I do not enjoy the notion of
>  > having to chase down discussion across multiple fora.
>
>  This is a good point.  I'll try to avoid using identi.ca to discuss
>  copyleft-next in future.
>
>  I do agree that having to follow GitHub, identi.ca, Gitorious, and this
>  mailing list is annoying.  While HBR doesn't prohibit it, I suggest we
>  all work to restrain ourselves to use *only* the mailing list and
>  Gitorious and nothing else for now, to avoid people having to track so
>  many fora.
>
>  I have *so* little time for copyleft-next, thus I really am swayed by
>  Stephen's point here.  I had assumed that checking the git log from
>  Gitorious and reading mailing list traffic would be adequate any time I
>  had a moment to check in with copyleft-next.  If that's not true:
>  because of use of GitHub, identi.ca, or any other fora being used, we
>  may want to nip it -- not because it's an HBR violation or even because
>  one of those solutions is proprietary  (identi.ca isn't after all), but
>  because it makes it difficult to follow a conversation across so many
>  fora.
>
>  I hadn't realized how big of a problem that is for people who have
>  limited time for the project until Stephen raised it.  Thanks for
>  raising that point.
>  --
>     -- bkuhn
>  _______________________________________________
>  copyleft-next mailing list
>  copyleft-next(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
>

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Engel Nyst]

On Fri, Feb 8, 2013 at 3:36 PM, Bradley M. Kuhn <bkuhn(a)ebb.org&gt; wrote:
>  I'll try to avoid using identi.ca to discuss
>  copyleft-next in future.
>
>  I do agree that having to follow GitHub, identi.ca, Gitorious, and this
>  mailing list is annoying.  While HBR doesn't prohibit it, I suggest we
>  all work to restrain ourselves to use *only* the mailing list and
>  Gitorious and nothing else for now, to avoid people having to track so
>  many fora.
>  
I'd suggest a tweak to this, if I may: discussions happen, on other media,
and they may contain proposals or raise issues. Before they result in
any kind of changes in copyleft-next, they could/should be referenced
and discussed on this mailing list. Would that work, to address the too
many fora?

Regarding import of existing github issues content, I'll be happy to make
the import, when the project chooses its wanted tracker.
There are about thirty issues so far, maybe not critical, but for
traceability in the future it still makes sense, at least to me, to keep the
data.

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Fri, Feb 08, 2013 at 11:37:00PM +0200, Engel Nyst wrote:
>  I'd suggest a tweak to this, if I may: discussions happen, on
> other media,
>  and they may contain proposals or raise issues. Before they result in
>  any kind of changes in copyleft-next, they could/should be referenced
>  and discussed on this mailing list. Would that work, to address the too
>  many fora? 
I think that is probably workable. 

The future issue tracker ought to be as acceptable as the mailing list
IMO.
 
>  Regarding import of existing github issues content, I'll be happy
> to make
>  the import, when the project chooses its wanted tracker.
>  There are about thirty issues so far, maybe not critical, but for
>  traceability in the future it still makes sense, at least to me, to keep the
>  data. 
Agreed. 

 - RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Fri, Feb 08, 2013 at 08:36:42AM -0500, Bradley M. Kuhn wrote:
>  Meanwhile, my understanding of the identi.ca conversation is this:
>  
>   * Pam Chestek got copyleft-next off GitHub, and nothing there told her
>     GitHub wasn't the canonical location for participation (this should
>     be fixed immediately, IMO.  I realize the README says it, but there
>     should be something in big bold letters on GitHub: THIS IS A MIRROR
>     ONLY.  DO NOT SUBMIT PULL REQUESTS AND ISSUES HERE.  USE MAILING LIST
>     AND GITORIOUS [or whatever solution Fontana decides].
>     Ideally, the pull request/issue tracker should be turned off.
>  
>   * Pam realized, probably after getting the checkout and seeing the
>     readme, that Gitorious was preferred.
>  
>   * Pam couldn't submit changes via Gitorious (at that point, presumably
>     her tracking branches were all pointed at GitHub, which was probably
>     part of the problem).
>  
>   * Fontana opened an issue on GitHub to collaborate with Pam on the
>     issue she raised.
>  
>   * I theorized that this marked a distributing occurrence, since GitHub
>     instance of copyleft-next seemed to be active again instead of just being a
>     mirror.  I complained heavily to Fontana about it, and Fontana
>     countered with what I believed were incorrect analogies to GPLv3
>     drafting process (i.e.,  I thought copyleft-next was trying to avoid
>     those, anyway!)
>  
>  
>  Pam and Fontana, is that summary accurate from your point of view? 
Except for the very last part, it's completely inaccurate, but Pam has
corrected the error.

>  I do agree that having to follow GitHub, identi.ca, Gitorious, and
> this
>  mailing list is annoying.   
I agree with that too. For a long time it wasn't a practical problem.

 - RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Sat, Feb 09, 2013 at 10:42:29AM -0500, Richard Fontana wrote:
>  Except for the very last part, it's completely inaccurate, but
> Pam has
>  corrected the error. 
Oops, Pam has said it is accurate, so my statement was completely
inaccurate except in saying that the last part of Bradley's statement
was accurate, since that part was clearly accurate.

 - RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Engel Nyst]

On Fri, Feb 8, 2013 at 5:14 AM, Stephen Michael Kellat <skellat(a)fastmail.net
>  wrote: 
>  Please do also disclose a summary of your sidebar discussion with
>  Richard Fontana as well as Claes Wallin that appears to be happening on
>  Identica and other federated StatusNet sites.  That appears to be
>  germane to this merge request and yet not necessarily represented
>  on-list.  This e-mail list remains our primary means of record
>  communications relative to the project.
>
>  I am minded at this point to ask that the folks who find the need to use
>  GitHub please make themselves heard on list within our primary record of
>  communications.  The mailing list has functioned quite well as a de
>  facto issue tracker thus far and I do not enjoy the notion of having to
>  chase down discussion across multiple fora.
>  
Point taken. Completely unrelated to yesterday's issue, I have done this as
well. I apologize. I can think of a couple circumstances when my random use
of different sites (all three mentioned here) to provide feedback or
potential issues, might pose problems from the perspective of the normal
communication through the project's primary medium.

I believe many were unbaked comments or random ideas exchanges, due more to
lack of expertise (or arguably even attention), and not intended as actual
proposals. However, I have also submitted a couple issues, intended as
proposals for copyleft-next, on github, or as comment to existing github
issues. The first has been on github by mistake/inertia: I have initially
missed the project's policy, thus I have submitted a pull request on
github. I have immediately afterwards switched to gitorious, for subsequent
merge requests.

In general, personally I use github, as a matter of randomness and
convenience, however I do not support its use.

Re: github issues tracker.
To my knowledge, it doesn't allow directly backing up the issues database.
(though email notifications work). If this is still the case, I believe it
to be one more reason not to settle for it, not for anything of real
relevance to the project.

I apologize for not bringing issues of potential relevance to everyone's
attention on the mailing list. I will fix that.

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Fri, Feb 08, 2013 at 04:58:20PM +0200, Engel Nyst wrote:
>  Point taken. Completely unrelated to yesterday's issue, I have
> done this as
>  well. I apologize. I can think of a couple circumstances when my random use of
>  different sites (all three mentioned here) to provide feedback or potential
>  issues, might pose problems from the perspective of the normal communication
>  through the project's primary medium.
>  
>  I believe many were unbaked comments or random ideas exchanges, due more to
>  lack of expertise (or arguably even attention), and not intended as actual
>  proposals. However, I have also submitted a couple issues, intended as
>  proposals for copyleft-next, on github, or as comment to existing github
>  issues. The first has been on github by mistake/inertia: I have initially
>  missed the project's policy, thus I have submitted a pull request on github. I
>  have immediately afterwards switched to gitorious, for subsequent merge
>  requests. 
As for me, I was happy to receive such comments and ideas, regardless
of medium. The only problem from my perspective was the practical one
of having too many things to keep track of. I didn't say anything
because I didn't want to discourage such participation. Same goes with
pchestek. So I suppose the one mistake I made was active use of the
GitHub issue tracker, yet this was not really a mistake because a few
days earlier I had a presentation slide that said that the GitHub
issue tracker was appropriate for use for the time being. Nevertheless
I do not anticipate making further active use of the GitHub issue
tracker at this time.

 - RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Thu, Feb 07, 2013 at 09:28:42PM -0500, Bradley M. Kuhn wrote:
>  I apologize that my job at Conservancy and volunteer work at FSF has
> made it
>  impossible for me to fit in volunteer work to help copyleft-next.  However, I
>  find it quite disturbing that the project is returning to GitHub. 
The project is not 'returning to GitHub' (I'm not even sure what that
would mean). Rather, a few people have recently been using GitHub to
make contributions.

>  I've
>  submitted this merge request to prevent the slippery slope toward proprietary
>  solutions that copyleft-next appears to be on.  HBR should stand up for the
>  software freedom of users.
>  
>  Please merge:
>  
>    https://gitorious.org/copyleft-next/copyleft-next/merge_requests/29 
I have rejected this merge request because it is outside the scope of
the HBR. That is not in itself a rejection of the policy position you
are advancing. 

> From the moment Gitorious began to be used as the canonical public
source repository, it was understood that the GitHub mirror would
remain operative and even that continued use of the GitHub issue
tracker for the GitHub repository was tolerable pending the adoption
of some better option. Thus, I am just preserving the status quo.

I am thinking of ceasing use of Gitorious because I've had one too
many problems with the service. But the solution won't be substitution
of GitHub for Gitorious.

 - RF

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Bradley M. Kuhn]

Richard Fontana wrote at 22:55 (EST) on Thursday:
>  The project is not 'returning to GitHub' (I'm not even
> sure what that
>  would mean). Rather, a few people have recently been using GitHub to
>  make contributions. 
I'm not objecting to what other participants might do.  The maintainer's
use of GitHub, though, would make it official.  Consider, for example,
if Linus Torvalds started using GitHub as the location to accept merge
requests.
  
>  I have rejected this merge request because it is outside the scope
> of
>  the HBR. That is not in itself a rejection of the policy position you
>  are advancing. 
That makes sense.  You are probably correct that it is outside HBR's
scope.

Can we discuss institution of a rule that only Free Software and network
services that share their code will be used to develop copyleft-next?
Are you willing to consider such a rule (outside the scope of HBR, of
course)?

>  even that continued use of the GitHub issue tracker for the GitHub
>  repository was tolerable pending the adoption of some better
>  option. Thus, I am just preserving the status quo. 
I'm willing to set up a bugs-everywhere area in the canonical Git
repository for copyleft-next and scrape all the content from there into
bugs-everywhere, but *only* if there could be agreement that it would
become canonical and use of the GitHub Issue Tracker would cease, with
a statement on the GitHub page that says not to use the Issue Tracker,
but to use bugs-everywhere instead.  Is that agreeable?

One of the reasons (although a minor one -- lack of time due to my
pre-existing highly demanding work and volunteer commitments is the
primary reason) I haven't helped with the Issue tracker is fear that I'd
put a lot of work in only to have it rejected by our dictator. :)

>  I am thinking of ceasing use of Gitorious because I've had one
> too
>  many problems with the service. But the solution won't be substitution
>  of GitHub for Gitorious. 
It's very good to know that yesterday's incident *does not* indicate
we're on a slippery slope back to GitHub.  Perhaps we're on a slippery
slope toward self-hosting, which is probably ok.

BTW, have you reported bugs to Gitorious?  Offered patches?

-- 
   -- bkuhn

[MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it

[Richard Fontana]

On Fri, Feb 08, 2013 at 08:29:31AM -0500, Bradley M. Kuhn wrote:
>  Can we discuss institution of a rule that only Free Software and
> network
>  services that share their code will be used to develop copyleft-next?
>  Are you willing to consider such a rule (outside the scope of HBR, of
>  course)? 
Sure, it should be considered. But defining what that means may not be
as easy as you are assuming. 

>  I'm willing to set up a bugs-everywhere area in the canonical
> Git
>  repository for copyleft-next and scrape all the content from there into
>  bugs-everywhere, but *only* if there could be agreement that it would
>  become canonical and use of the GitHub Issue Tracker would cease, with
>  a statement on the GitHub page that says not to use the Issue Tracker,
>  but to use bugs-everywhere instead.  Is that agreeable? 
I still want to investigate alternatives to bugs-everywhere. I'll try
to do that soon.
 
>  It's very good to know that yesterday's incident *does not*
> indicate
>  we're on a slippery slope back to GitHub.  Perhaps we're on a slippery
>  slope toward self-hosting, which is probably ok. 
I don't understand why self-hosting is considered worse than using
some gratis service that purports to offer its source code, which is
what I read into your phrase "probably OK". Isn't self-hosting always
*better* from a software freedom perspective?
 
>  BTW, have you reported bugs to Gitorious?  Offered patches? 
'Offering patches' doesn't make sense; even if a network service
purports to provide its source code, there's no reliable way to know
whether the source code is corresponding for immediate error-reporting
purposes, so it's not worth the effort to try to build an instance of
Gitorious myself, try to recreate the error, and then offer a patch
upstream. If I were to do that, from a conservation of effort
perspective I might as well just use Gitorious for self-hosting. 

I pointed out one of the problems I was experiencing a while back to
Gitorious, and it was corrected. As for the other mysterious glitches
and suboptimal behavior I claim to have experienced, I am in the usual
situation of not knowing what to report. To put it another way, it is
less effort to find a non-Gitorious solution than to figure out how to
usefully report the problems I've experienced. 

- RF

Why was BE rejected as an issue tracker for copyleft-next?

[Bradley M. Kuhn]

Richard Fontana wrote:
>  I am tracking the underlying issue here on github at 
BTW, could someone please state (or restate) the reasons that
http://bugseverywhere.org/ was rejected as an issue tracker for
copyleft-next?

   -- bkuhn

Why was BE rejected as an issue tracker for copyleft-next?

[Stephen Michael Kellat]

On 02/07/2013 10:03 PM, Bradley M. Kuhn wrote:
>  Richard Fontana wrote:
> > I am tracking the underlying issue here on github at
>  BTW, could someone please state (or restate) the reasons that
>  http://bugseverywhere.org/ was rejected as an issue tracker for
>  copyleft-next?
>
>     -- bkuhn
>  _______________________________________________
>  copyleft-next mailing list
>  copyleft-next(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/copyleft-next 
Bradley,

My logs lack reasoning in that regard.  If we were to utilize
BugsEverywhere, we could switch to Fossil SCM which is at least an
integrated distributed system.  See:
http://fossil-scm.org/index.html/doc/trunk/www/index.wiki

Stephen Michael Kellat

Why was BE rejected as an issue tracker for copyleft-next?

[Richard Fontana]

On Thu, Feb 07, 2013 at 10:16:17PM -0500, Stephen Michael Kellat wrote:
>  On 02/07/2013 10:03 PM, Bradley M. Kuhn wrote:
>  > Richard Fontana wrote:
>  >> I am tracking the underlying issue here on github at
>  > BTW, could someone please state (or restate) the reasons that
>  > http://bugseverywhere.org/ was rejected as an issue tracker for
>  > copyleft-next? 
>  Bradley,
>  
>  My logs lack reasoning in that regard.  If we were to utilize
>  BugsEverywhere, we could switch to Fossil SCM which is at least an
>  integrated distributed system.  See:
>  http://fossil-scm.org/index.html/doc/trunk/www/index.wiki 
I remember BugsEverywhere being suggested by someone somewhere
(possibly in a comment to a GitHub issue) but ISTR something about it
was considered suboptimal. In any case I never investigated it or
alternatives. 

- RF

Why was BE rejected as an issue tracker for copyleft-next?

[Bradley M. Kuhn]

Richard Fontana wrote at 22:40 (EST) on Thursday:
>  ISTR something about [BugsEverywhere] was considered suboptimal.
Could you investigate BugsEverywhere and either approve it as a solution
(in which case, I could help you set it up) or state clear reasons for
objecting it?

Note that IMO "suboptimal" isn't a reason not to use something.  GitHub
is suboptimal in many ways (and not only the proprietary reasons of my
concern).  So is a mailing list.  I hope you won't let the best be the
enemy of the good.
-- 
   -- bkuhn

Why was BE rejected as an issue tracker for copyleft-next?

[Richard Fontana]

On Fri, Feb 08, 2013 at 08:49:18AM -0500, Bradley M. Kuhn wrote:
>  I hope you won't let the best be the
>  enemy of the good. 
My basic criteria for an issue tracker are:

1) Not written in PHP
2) Doesn't use a database

Why was BE rejected as an issue tracker for copyleft-next?

[Richard Fontana]

On Fri, Feb 08, 2013 at 08:49:18AM -0500, Bradley M. Kuhn wrote:
>  Richard Fontana wrote at 22:40 (EST) on Thursday:
>  > ISTR something about [BugsEverywhere] was considered suboptimal.
>  
>  Could you investigate BugsEverywhere and either approve it as a solution
>  (in which case, I could help you set it up) or state clear reasons for
>  objecting it? 
I have now investigated Bugs Everywhere. Unfortunately I object to
it. This saddens me because it seems to come *very* close to what I
have in mind for a perfect issue tracker.

My objections are that it appears to be poorly-documented and
poorly-maintained to the point where the annoyance of using it will
greatly exceed the benefits, and where the likelihood of future
versions of it or its dependencies causing everything to break seems
unusually high.

This is too bad, because I don't think there's anything better.

>  Note that IMO "suboptimal" isn't a reason not to use
> something.  GitHub
>  is suboptimal in many ways (and not only the proprietary reasons of my
>  concern).  So is a mailing list.  I hope you won't let the best be the
>  enemy of the good. 
The problem is that Bugs Everywhere doesn't even meet my standard of
'good'.[1] If I were sufficiently skilled at Python or *wanted* to be
(I *currently* don't), I'd consider helping out with or forking the
project. 

 - RF

[1] I tried using both the version packaged in Fedora 17 and the more
recent verson available from the project's Gitorious repository.

[Richard Fontana]

On Thu, Feb 07, 2013 at 01:05:26AM -0500, Richard Fontana wrote:
>  I am tracking the underlying issue here on github at
>  https://github.com/richardfontana/copyleft-next/issues/30 
In light of my response to Stephen, this can be ignored. Please use
the mailing list to discuss this issue.

 - RF