-----BEGIN PGP SIGNED MESSAGE-----
I took a stab at setting up a distributed issue tracker for us. I
decided to go with ditz  because I liked its feature set and it
seemed to be a reasonable state of maintenance. It meets Richard
Fontana's requirements of not being written in PHP (it's written in
Ruby) and not using a database (state is stored in yaml files). I have
published a version of the repository with some ditz issues here ,
look at the ditz-experiment branch.
I have created two issue so far. The first is to track to migration to
ditz and second is the start of importing a github issue. Between the
readme on the ditz website and the built-in help "ditz help" I felt
comfortable working with ditz in about 10 minutes.
Important things to note about ditz:
It has the ability to assign issues to releases. I have created two
releases (0.1.2. and 0.2.0), but did not assign the issues I created to
It has a concept of whether an issue is being worked on, governed by
ditz start and ditz stop. I started working on the migration ticket,
but not on the one imported from github.
After working with ditz changes need to be committed. ditz reminds you
ditz is packaged in Debian and a Gentoo ebuild is available from the
I look forward to hearing what you think about ditz.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
-----END PGP SIGNATURE-----
Recently Mike Linksvayer said:
> I have one meta-comment on copyleft-next-0.1.1 -- I wish the
> announcement came with brief description of changes.
Here's a belated description of the principal changes in 0.1.1
relative to 0.1.0.
i) Section 1 of 0.1.0 had the sentence:
This License does not exclude or limit any rights You have under
applicable copyright doctrines of fair use, fair dealing or other
Adopting a suggestion made by Pam Chestek, 0.1.1 changed this to the
This License does not exclude or limit any rights You have under
applicable copyright law.
More recent drafts have deleted 'copyright'. This change was recently
discussed on the mailing list.
ii) A few changes in sections 3 and 4 that clarify that the section
currently labeled 'Pass-Through' (the descendant of the GPL's
automatic licensing clause, though it is constructed a bit more like
the corresponding clause in the Creative Commons [at least 3.0 series]
licenses) is not a condition. Implements suggestions made by Pam
iii) The anti-badgeware-abuse language at the end of section 4 adds
"trademark legends" to the list of things that are not "Legal Notices"
that need to be preserved by the distributing licensee. Implements a
suggestion made by Pam Chestek.
iv) The titles of certain sections (in 0.1.1, 5-8) indicate explicitly
that the sections are 'conditions'. Implements a suggestion made by
v) In the definitions of 'Derived Work' and 'Distribute', the language
"such that copyright permission is required" (a holdover of sorts from
certain language in GPLv3) is deleted as unnecessary. Implements a
suggestion made by Pam Chestek.
vi) In the Apache License 2.0/MPL 2.0-derived subdefinition of
"control" contained in the definition of "You", the language "the
power, direct or indirect, to cause the direction or management of
such entity" was changed to "the power to direct the actions of such
entity", implementing a suggestion made by Pam Chestek. This is a bug
in the Apache License 2.0, however minor; it is at best unidiomatic
English to speak of "causing the direction or management" of
Here are some comments regarding version 0.1.1 and copyleft-next in
Richard mention his "lengthy" commit messages at FOSDEM and wondered
whether they're too long. I must say that I like the detailed
explanations for changes. This will come in handy in 5 or 10 years
when nobody can remember the rationale for a change.
Section 4 contains the following explanation:
| "Legal Notices" means copyright notices, license notices,
| license texts, and author attributions, but does not include logos,
| other graphical images or trademark legends.
While I find it useful to have the explanation in the paragraph,
it seems inconsistent because all other definitions are at the end
of the license. Is there a reason this one is different?
Section 11 says "unless You cure". I was going to propose a simpler
term than "cure" until I realized this is actually a legal term:
Given that you're looking for contributions from developers and hoping
that developers will read the license, would it make sense to maintain
a list of "special" words (e.g. in the FAQ). This way, people know
a) not to replace them in patches and b) can read about their precise
Definition of "Corresponding Source":
| provided under (i); and (iii) a list clearly identifying all Separate
| Works (other than those provided in compliance with (ii)) that were
When I read this, I was wondering whether this should say something like
"Separate Works (including a clear identification, such as version number)"
| specifically used in building and installing the Covered Work (for
| example, a specified proprietary compiler including its version
| number). Corresponding Source must be machine-readable.
And here I'm wondering whether the "for example, ..." should be removed
and moved to the FAQ instead. OTOH, it's nice to have a clear example
in the license itself.
I've also attached some patches that fix various formatting issues. I
didn't want to send a pull request as you probably disagree with some
of the changes. You can apply those you like with "git am", or I can
send a pull request.
Upon review of a recent release (0.1.1) I am wondering the following:
1. Will there be a FAQ?
If there were a "place" to put explanations it may facilitate concision.
There is precedent with the FSF FAQ's.
BFDL mentions a FAQ in slide 22 (see question 8 below).
2. Is the rationale for design decisions captured explicitly?
The mailing list has provided a great deal of clarification
regarding goals, approaches and thinking. However searching
the mailing list for thinking on a specific point may
be difficult. Is there a convention, for example,
that changesets should document the rationale for
changes on the affected lines? Short of having
a good memory on the "oral tradition" of the license
evolution would commit messages or any other approach
answer the question "what is the point *that* phrase?"
or "why did the BFDL choose this solution among alternates?"?
3. Why list in §10 specific license compatibility?
In fact this is is more license *morphing* than compatibility.
If, for example, copyleft-next is intended to plug
loopholes of AGPL then does not §11 preserve such
loopholes (through morphing)?
4. Is copyleft-next compatible with the EPL?
This question is a troll.
5. Compliance freshness date encourages prompt remedies?
Is the goal of §11.a to encourage coming in to compliance
quickly else requiring You to negotiate a new license with Us?
In other words downloading a new copy of the "Covered Work"
does not reset the clock on a terminated license?
6. Does the definition of "Corresponding Source" combined with §7
effectively form an anti-lockdown provision?
A Product shipping with Corresponding Source yet not runnable
by rebuilding the Source (due to, for example, the lack of a certain
cryptographic signature) would withhold freedom #1.
It is not obvious that the interpretation of copyleft-next
could simultaneously support lockdown and qualify
as a Free Software license by supporting all four freedoms.
Certain developers may believe there is a solution in
explicitly allowing key replacement
(such that private key material need not be disclosed).
7. What triggers derivation vs. aggregation?
For the purpose of understanding the applicability of §5
is there a "bright line" test to distinguish aggregation?
For example, if Object Code from the Covered Work is
linked with a Separate Work is the result a Derived Work?
Or if Object Code operates in conjunction with a Separate Work
over a network connection is the result a Mere Aggregation?
8. Based on the FOSDEM presentation
is the choice of a Hyena as a mascot an allusion
to the unfortunate occurrence of tribal infighting (cannibalism?)
in Free Software communities (first mentioned in a blog
post long ago by Mark Shuttleworth)?
9. Proprietary relicensing deflation loophole
Why offer a loophole of one year in §3 before
deflation kicks in?
10. Getting to 201 lines
All the metrics of copyleft-next are currently meeting
objectives, except for line count. How can we best
get down to 201 lines? Do we really need decorations
for §13 and §14? That may be acceptable if it is
an alternative for SCREAMING in all caps. Perhaps
limiting decorations to the margins would eliminate
11. Will copyleft-next* (i.e. copyleft-next or copyleft-next-ns)
be silent on data or try to incorporate the spirit of the
Franklin Street Statement?
Both Section 7(ii) and Section 8 allow users to provide the
Corresponding Source from a network location so long as it is provided
at no charge.
I would like to add additional requirements.
The basic thing I'm looking for is that the source be made publicly
available and not put behind some wall of inconvenience (such as
requiring a specific device or requiring a user account, etc). Below are
three sections: 1) stuff I want to prevent, 2) stuff I don't want to
prevent, 3) stuff I'm not sure about.
## Stuff I want to prevent
A person providing source shouldn't make a user do any of the following
in order to be able to download the source:
* Create a user account
* Undergo identity verification/authentication (or sign in with some
third party service like Facebook or Twitter)
* Complete a survey or lengthy data collection process.
* First request send a request to the host that your IP address be added
to a whitelist
* Require the use of running proprietary software in order to download
the source code (e.g., requiring the use of some proprietary App Store
* Require the use of a specific kind of device or require a person to
spoof device metadata (similar to how the Android App store will prevent
you from downloading an App that is not compatible with a certain device).
* Require some PACER like step of having a PIN mailed to you in the mail.
With the exception of PACER, I have encountered each of the above issues
when trying to download source of programs licensed under the GPL.
## Stuff I don't want to prevent
At the same time, I wouldn't want to prevent a person distributing the
source from doing things that are sensible.
* Blacklisting spammer/crawler IP addresses.
* Require users to fill out a captcha
* Tracking basic info provided in HTTP headers
* Provide a user with simple instructions like: 'in order to download
this source, please enter the username "public" and password "anonymous"
to the following form'.
## Stuff I'm not sure about
* Requiring the user to use a version control systems (e.g., providing
access only over a "git clone" statement).
* Requiring the user to connect to some weird protocol even if there is
free software that can connect to it (e.g., like, imagine if f-droid
didn't have an HTTP interface, but it used some weird interface and it
only provided source via the f-droid app interface running on your
Replicant/Android/Linux OS) -- in order to connect from GNU/Linux you'd
either have to figure out how to get f-droid running on GNU/Linux or
you'd need to figure out how to create a connection to the store).
* Operating system requirements. For example, people do not build
Android Apps on top of Android, they build them on top of a different OS.
I just realized that a part of my brief conversation with Mike
Milinkovic following my FOSDEM talk triggers HBR.
While not a substantive point, I noted to Mike my interest in
submitting some version of copyleft-next for OSI approval. (Mike, who
heads the Eclipse Foundation, is on the OSI board of directors.)
The substantive point, though, was this: we were talking about how the
EPL (like the MPL and its relatives) allows proprietary licensing of
binary versions. I told him that I had recently thought about whether
this was in conflict or not with the basic notion of strong copyleft,
and whether copyleft-next could or should be revised to allow more
restrictive licensing of binaries (more restrictive than
copyleft-next/GPL/AGPL, that is). That might sound heretical, but it
is not meant to be. It relates to a historical puzzle I have thought
I noted that the GNU GPL was originally intended for software that
would be compiled by proprietary compilers and run on proprietary
operating systems. The earliest binary versions of GNU Emacs must have
contained proprietary code. This of course was what led RMS to add
what came to be known as the system library exception to the
definition of 'complete source code'. But the system library exception
does not tell us what the license of a statically-linked binary formed
out of GPL-licensed code and 'system library' code is supposed to be.
I am not sure whether RMS thought about this issue. It is possible
that the licensing terms governing the various operating systems and
compilers in use among the early users/porters of GPL-licensed
programs like GNU Emacs were such that the question was thought to be
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
If this is inappropriate for the full list then reply separately, but I
thought I'd start by asking here as part of the further exploration of the
Why is redline so objectionable? It is simply another form of version
control and is available in LibreOffice.
My challenges with Github were that I could not figure out how to compare
my last revision to anything but the most previous commit. In a case where
all I had changed from the previous commit was an uppercase letter to a
lowercase, that wasn't particularly helpful. In order to compare my latest
iteration to the base document I was revising, I took copies and compared
them in LibreOffice because I couldn't figure out how to do it any other
way. I concede I don't know if there was a way to do it if I was using Git
proper and knew how to use it, though.
The other challenge was changing my mind. There was one addition I made in
one commit, then changed my mind and took it out, which was a second
commit. In a LibreOffice redline it would have simply disappeared. I
suppose you can argue that it shouldn't, and you should have insight into
my every keystroke, but I think that's overkill when it's a contemplative
I found the commit process apparently requires more forethought about when
to commit that what I exercised (sorry Richard). Ideally one would commit
at logical iterations, but I don't find it very easy to do that when
revising a text document, where I often jump around and change my mind
after I've read and absorbed more. Richard broke out my changes into
logical issues after the fact, but they didn't get created so logically.
I also find a redlined document no harder to read than a version
comparison, it's pretty clear what's what (unless you have too many cooks
before accepting changes). It's also easy to do, just turn it on.
I appreciate that redline is incompatible with Git and so is inappropriate
for this project. But I am a bit puzzled by what seems to be antipathy to
redline in general, which I just see as another form of version control and
perhaps better suited to text documents that the Git functionality.
Github pull request:
> In case Proprietary Relicensing happens, copyleft is effectively wiped out.
What remains is a fallback license of sorts, which should at least require
> attribution I think...
I wonder if this is enough, I can't figure out well enough what would
> happen when all the
fun questions would be asked (compatibility...)