Should the first release of copyleft-next be designated with the version number 1.0, 0.1, 0.01, something else?
I'm somewhat inclined to go with "0.01" (which still is suggestive of 'likely to see further improvement'). Incidentally, I am increasingly of the view that the version stability of (at least interesting) FLOSS (and free or quasi-free content) licenses is a flaw, and I am envisioning copyleft-next as a license that could rapidly evolve even when one only considers a series of official numbered releases.
Most FLOSS licenses with numbered releases (and names) have begun with "1.0" (famous exceptions are the GNU LGPL and the GNU AGPL). Apparently there was an 0.5 release of the Common Public License that was applied to some software, so there is some limited precedent for having pre-1.0 numbered releases.
- RF
Having no experience in this area, I'm delightfully unencumbered by any historical context. Before I form my opinion, I wonder what the purpose behind numbering a release is at this point? Are we saying that copyleft-next is ready to be used or just that it's sufficiently mature to be reviewed by people who haven't been watching the development process (incidentally, I have a lot of commit messages to catch up on)?
As for the anti-feature nature of license stability, I understand your view from an academic perspective, but I wonder what effect a rapidly-evolving license would have on adoption and enforcement.
-- Ben Cotton
On 11/20/2012 09:19 PM, Ben Cotton wrote:
Having no experience in this area, I'm delightfully unencumbered by any historical context. Before I form my opinion, I wonder what the purpose behind numbering a release is at this point? Are we saying that copyleft-next is ready to be used or just that it's sufficiently mature to be reviewed by people who haven't been watching the development process (incidentally, I have a lot of commit messages to catch up on)?
I actually do think it is ready to be used. It's not perfect, but no one can seriously say that any of the relatively popular FLOSS licenses is in any *better* shape.
I know I got out of the habit of semi-weekly updates. Partly this was because I got busier with other things from the end of the summer on, but partly also it was that it seemed that improvements were going to be *very* gradual anyway (unless a lot more people got more actively involved). I think the updates would have gotten kind of boring, but people can see the commit logs.
However, in addition to your comment about needing to catch up on commits, the redoubtable Bradley Kuhn has said that he intends to make some comments on some recent changes (such as my deletion of "ws-supp" which I think he may have found disturbing). (To the extent that my previous non-disclosure of such conversation [medium forgotten] was a Harvey Birdman Rule violation, I have now cured it.) So I guess I'm not the only busy person. :)
As for the anti-feature nature of license stability, I understand your view from an academic perspective, but I wonder what effect a rapidly-evolving license would have on adoption and enforcement.
Well, after sending that message I realized that "rapidly-evolving" gives the wrong impression. I actually mean something more like "slowly changing but with lots of point releases so that the improvements can be applied right away [unless the licensor has said otherwise]". I'm reminded of how some critics of GPLv3 argued that there should have been the equivalent of mere "bug fixes" of GPLv2 instead rather than the more substantial changes from GPLv2 to GPLv3. One could imagine the FSF having done such "bug fixes" over the years in a series of GPLv2.x releases, as they did in releasing LGPLv2.1 (containing a minor change from LGPLv2) in 1999. Maybe that would have created an atmosphere of greater instability that would have limited adoption of the GPL (in its various versions) generally.
It is also worth remembering that the GPL actually did evolve fairly rapidly from its earliest versions in the latter 1980s to 1991, with the release of GPLv2. There were just two years between GPLv1 and GPLv2. I wonder if RMS/the FSF in 1991 assumed that GPLv3 would be released by 1993 or so.
- RF
On Tue, Nov 20, 2012 at 9:52 PM, Richard Fontana fontana@sharpeleven.org wrote:
I actually do think it is ready to be used.
Given this, I'm in favor of 1.0.
On Tue, Nov 20, 2012 at 9:10 PM, Richard Fontana fontana@sharpeleven.org wrote:
I'm somewhat inclined to go with "0.01" (which still is suggestive of 'likely to see further improvement').
This is a fair point, but I think 0.01 conveys a "not really ready for use" mindset, whereas 1.0 is more generally recognized as "usable" by the public.
Then again, it's just a number, as the varied numbering schemes of projects like the Linux kernel and WINE can attest to. I like 1.0, but I won't try to argue against anyone who disagrees.
-- Ben Cotton
Hello,
On 11/21/2012 03:10 AM, Richard Fontana wrote:
Should the first release of copyleft-next be designated with the version number 1.0, 0.1, 0.01, something else?
For simplicity, I would prefer a single incrementing integer. (version 1, version 2, version 3, etc...).
If you do pick a major/minor versioning scheme, it would be useful to know what kind of changes you think should bump which number.
-- kuno / warp.
Den 21 nov 2012 10:10 skrev "Richard Fontana" fontana@sharpeleven.org:
Should the first release of copyleft-next be designated with the version number 1.0, 0.1, 0.01, something else?
I'm somewhat inclined to go with "0.01" (which still is suggestive of 'likely to see further improvement'). Incidentally, I am increasingly of the view that the version stability of (at least interesting) FLOSS (and free or quasi-free content) licenses is a flaw, and I am envisioning copyleft-next as a license that could rapidly evolve even when one only considers a series of official numbered releases.
Please do no use 0.01.
Regardless of issues such as the applicability and mapping of "stable API", "added feature", "bug fix" etc to a license text, I do think that http://semver.org/ summarizes well today's general expectations of a version number.
In particular, points are not decimal points, they are separators between non-negative integers, such that 0.10.0 > 0.2.0.
So, please do not use 0.01; 0.0.0 or 0.1.0 is better.
This is my strong opinion on the color of this particular wall of the bike shed.
On 11/21/2012 12:08 PM, Claes Wallin (韋嘉誠) wrote:
Please do no use 0.01.
Regardless of issues such as the applicability and mapping of "stable API", "added feature", "bug fix" etc to a license text, I do think that http://semver.org/ summarizes well today's general expectations of a version number.
In particular, points are not decimal points, they are separators between non-negative integers, such that 0.10.0 > 0.2.0.
So, please do not use 0.01; 0.0.0 or 0.1.0 is better.
This is my strong opinion on the color of this particular wall of the bike shed.
I am inclined to follow this suggestion. I think the first numbered release should be "0.1.0".
- RF
I wanted to register something I may have told Fontana already, which makes this email an HBR cure as well:
I don't think that copyleft-next should release until we actually think it's appropriate for software developers to license software under it.
And, since this came up in the GitHub thread: I don't think a release isn't going to cause network effects, if that's what you're aiming for.
For that, I suggest instead we do a discussion draft model. Granted, in git, every revision is a discussion draft, but we could mark a specific git revision for which we're willing to "take comments on" for a longer period -- even as the master branch moves forward. Basically, we'd be making a commitment to the community that comments for an older version would be considered for longer, and we'd always answer questions on that revision, even if the answer is: "We changed that text to this in the current draft which we think addresses your issue".
What do you think of that idea?
On 12/04/2012 08:24 AM, Bradley M. Kuhn wrote:
I don't think that copyleft-next should release until we actually think it's appropriate for software developers to license software under it.
I *sort of* agree with this, but we may have different notions of 'appropriate'. I now have the view that 'releasing for the sake of there being a release' makes no particular sense.
And, since this came up in the GitHub thread: I don't think a release isn't
(ITYM 'is')
going to cause network effects, if that's what you're aiming for.
Initially I think it was more like 'symbolic sign of progress', although that was before I realized copyleft-next is already quite suitable for use as a license (at least by comparison to existing popular or widely used FLOSS licenses).
For that, I suggest instead we do a discussion draft model. Granted, in git, every revision is a discussion draft, but we could mark a specific git revision for which we're willing to "take comments on" for a longer period -- even as the master branch moves forward. Basically, we'd be making a commitment to the community that comments for an older version would be considered for longer, and we'd always answer questions on that revision, even if the answer is: "We changed that text to this in the current draft which we think addresses your issue".
What do you think of that idea?
This is a nice idea, and is also similar to what I was thinking for a while. I forget whether I said this on the mailing list or to you in person (if the latter, this is HBR cure) - I said a numbered release could be similar to the GPLv3 discussion drafts. However, in reality there isn't currently much of a wider 'community' to make such a commitment to - beyond this mailing list of course. (I think there is a much larger group of people who have heard of copyleft-next, who are 'watching' the github repository, etc., but I'm not sure how significant their level of interest is.) I'm not saying that's a horrible thing, but it may make 'discussion drafts' seem a bit silly.
- RF
On 12/04/2012 08:24 AM, Bradley M. Kuhn wrote:
I wanted to register something I may have told Fontana already, which makes this email an HBR cure as well:
I don't think that copyleft-next should release until we actually think it's appropriate for software developers to license software under it.
And, since this came up in the GitHub thread: I don't think a release isn't going to cause network effects, if that's what you're aiming for.
For that, I suggest instead we do a discussion draft model. Granted, in git, every revision is a discussion draft, but we could mark a specific git revision for which we're willing to "take comments on" for a longer period -- even as the master branch moves forward. Basically, we'd be making a commitment to the community that comments for an older version would be considered for longer, and we'd always answer questions on that revision, even if the answer is: "We changed that text to this in the current draft which we think addresses your issue".
What do you think of that idea?
If we're going to consider a discussion draft, let us divorce any release (discussion draft or otherwise) from the realm of established F/LOSS conferences. This should stand alone and be launched with a press conference of its own where we can explain as simply as possible to the tech media what on earth this is and how we got here. Serendipitous discovery is great and seems to be what Fontana is driving for relative to people discovering copyleft-next. I would much rather avoid that and at least launch this so that even non-developers might get a glimpse at what is being attempted.
It may come from cynicism erupting from being a precinct election official last month where plenty of write-in candidates hoped to be found and voted for in a serendipitous fashion and instead were handily crushed by candidates actually printed on the ballot. Then again, I also saw plenty of third party candidates shoot for the serendipity route get crushed too. Going down that road just seems unwise at this juncture.
Stephen Michael Kellat
copyleft-next@lists.fedorahosted.org
-
Ben Cotton -
Bradley M. Kuhn -
Claes Wallin (韋嘉誠) -
Kuno Woudt -
Richard Fontana -
Stephen Michael Kellat