8:10 p.m.
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
8:19 p.m.
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
8:52 p.m.
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
9:40 p.m.
On Tue, Nov 20, 2012 at 9:52 PM, Richard Fontana
<fontana(a)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(a)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
7:46 a.m.
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.
11:08 a.m.
Den 21 nov 2012 10:10 skrev "Richard Fontana" <fontana(a)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.
--
/c
10:44 p.m.
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
7:24 a.m.
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?
--
-- bkuhn
8:10 a.m.
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
4:34 p.m.
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
4222
days inactive
4235
days old
copyleft-next@lists.fedorahosted.org
9 comments
6 participants
participants (6)
-
Ben Cotton -
Bradley M. Kuhn -
Claes Wallin (韋嘉誠) -
Kuno Woudt -
Richard Fontana -
Stephen Michael Kellat