12:52 a.m.
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
1:50 a.m.
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
12:05 a.m.
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
8:28 p.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
9:03 p.m.
New subject: Why was BE rejected as an issue tracker for copyleft-next?
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
9:14 p.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
9:16 p.m.
New subject: Why was BE rejected as an issue tracker for copyleft-next?
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
9:40 p.m.
New subject: Why was BE rejected as an issue tracker for copyleft-next?
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
9:55 p.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
10:18 p.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
10:59 p.m.
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
7:29 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
7:36 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
7:49 a.m.
New subject: Why was BE rejected as an issue tracker for copyleft-next?
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
8:13 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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> 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
8:58 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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.
3:37 p.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
On Fri, Feb 8, 2013 at 3:36 PM, Bradley M. Kuhn <bkuhn(a)ebb.org> 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.
9:40 p.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
9:22 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
9:42 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
9:48 a.m.
New subject: Why was BE rejected as an issue tracker for copyleft-next?
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
9:55 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
10:06 a.m.
New subject: [MERGE REQUEST] HBR should require the project stands up for software freedom of those who contribute to it
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
11:25 p.m.
New subject: Why was BE rejected as an issue tracker for copyleft-next?
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.
4118
days inactive
4132
days old
copyleft-next@lists.fedorahosted.org
23 comments
6 participants
participants (6)
-
Bradley M. Kuhn -
Engel Nyst -
Joshua Gay -
Pamela Chestek -
Richard Fontana -
Stephen Michael Kellat