3:56 a.m.
Hello,
How? Where? What is the appropriate permlink to reference when
licensing my creative works under copyleft-next 0.1.0?
Do you have a standard blurb to copy/paste in my source files?
Why does http://copyleft-next.org/ only say "hello world!" ?
To be blunt, it doesn't look very released without any of these things.
But, congratulations on the release anyway! :)
-- kuno / warp.
4:15 a.m.
On 2013-01-26 17:56, Kuno Woudt wrote:
Hello,
How? Where? What is the appropriate permlink to reference when
licensing my creative works under copyleft-next 0.1.0?
Might that be:
https://www.gitorious.org/copyleft-next/copyleft-next/blobs/raw/v0.1.0/Re...
?
I'm a bit out of the lurker loop the last few weeks, and I'm not clear
on whether github or gitorious is the main site ... but gitorious is the
one that carries the v0.1.0 tag, so it seems to be the primary one.
A shorter and more hosting-opaque URL would probably be appropriate. How
about setting up a simple redirect from
http://copyleft-next.org/copyleft-next-0.1.0 to the appropriate GIT blob?
Another idea would be to register a URL at http://purl.org/ .
Do you have a standard blurb to copy/paste in my source files?
Why does http://copyleft-next.org/ only say "hello world!"
?
Maybe the root should simply redirect to the git repo welcome page until
there is some idea of what content should be on the website.
To be blunt, it doesn't look very released without any of these
things.
But, congratulations on the release anyway! :)
Congratulations from me as well! This is an interesting journey to be
following!
--
/c
10:13 a.m.
On 01/26/2013 05:15 AM, "Claes Wallin (韋嘉誠)" wrote:
On 2013-01-26 17:56, Kuno Woudt wrote:
> Hello,
> How? Where? What is the appropriate permlink to reference when
> licensing my creative works under copyleft-next 0.1.0?
Might that be:
https://www.gitorious.org/copyleft-next/copyleft-next/blobs/raw/v0.1.0/Re...
?
I'm a bit out of the lurker loop the last few weeks, and I'm not clear
on whether github or gitorious is the main site ... but gitorious is the
one that carries the v0.1.0 tag, so it seems to be the primary one.
Yes.
A shorter and more hosting-opaque URL would probably be appropriate.
How
about setting up a simple redirect from
http://copyleft-next.org/copyleft-next-0.1.0 to the appropriate GIT blob?
Another idea would be to register a URL at http://purl.org/ .
> Do you have a standard blurb to copy/paste in my source files?
> Why does http://copyleft-next.org/ only say "hello world!" ?
Maybe the root should simply redirect to the git repo welcome page until
there is some idea of what content should be on the website.
Good suggestions! Thank you.
- RF
9:37 a.m.
On 01/26/2013 04:56 AM, Kuno Woudt wrote:
Hello,
How?
By way of the "git tag" functionality, and the placement of the
numbered version in the Releases/ directory of the source repository.
What is the appropriate permlink to reference when
licensing my creative works under copyleft-next 0.1.0?
Oh, that's a good point, as copyleft-next 0.1.0 doesn't *require* one
to include a copy of the license text in the traditional manner. "You
may Distribute Covered Works, provided that You (i) inform recipients
how they can obtain a copy of this License; ....".
I guess permalinks have been useful for the Apache License 2.0.
Do you have a standard blurb to copy/paste in my source files?
No. I don't like any of the standard license notices used by
relatively mainstream non-tiny FLOSS licenses (GPL/LGPL, Apache
License 2.0, EPL, MPL 1.1/2.0), but I'm also reluctant to recommend
any particular notice (particularly in a "How to Apply" appendix that
becomes part of the license document). Arguably those have served some
minor purpose in the GPL/LGPL and Apache-2.0 universes.
If it were me, I'd just say something simple like
License: copyleft-next
or
License: copyleft-next 0.1.0
or, if I wanted to preclude use of 'Later Versions' without permission,
License: copyleft-next 0.1.0.
NOTE! The only valid version of copyleft-next as far as [PROJECT
NAME] is concerned is _this_ particular version of the license
(i.e. v0.1.0, not v0.1.1 or v1.x.x or whatever), unless explicitly
otherwise stated.
Why does http://copyleft-next.org/ only say "hello world!"
?
Because it hasn't been updated. However, I would like to do something
with that website.
To be blunt, it doesn't look very released without any of these
things.
When I were a lad, we announced license releases on Usenet newsgroups!
But, congratulations on the release anyway! :)
Thank you.
- RF
9:58 a.m.
On Jan 26, 2013 11:37 PM, "Richard Fontana" <fontana(a)sharpeleven.org>
wrote:
On 01/26/2013 04:56 AM, Kuno Woudt wrote:
> What is the appropriate permlink to reference when
> licensing my creative works under copyleft-next 0.1.0?
Oh, that's a good point, as copyleft-next 0.1.0 doesn't *require* one
to include a copy of the license text in the traditional manner. "You
may Distribute Covered Works, provided that You (i) inform recipients
how they can obtain a copy of this License; ....".
I guess permalinks have been useful for the Apache License 2.0.
A canonical reference address is always beneficial, not the least for use
as an identity in formalized license declarations like the one in RDF that
CC has been working on.
12:42 p.m.
On Sat, Jan 26, 2013 at 10:37:58AM -0500, Richard Fontana wrote:
License: copyleft-next 0.1.0
or, if I wanted to preclude use of 'Later Versions' without permission,
License: copyleft-next 0.1.0.
I'd suggest using something which is a bit more obvious than the
presence or absence of a period. Something which is more explicit,
such as the presence or absence "(or later)" is less likely to be
missed, or accidentally deleted while editing a source file.
- Ted
1:11 p.m.
On Sat, Jan 26, 2013 at 10:42 AM, Theodore Ts'o <tytso(a)mit.edu> wrote:
On Sat, Jan 26, 2013 at 10:37:58AM -0500, Richard Fontana wrote:
>
> License: copyleft-next 0.1.0
>
> or, if I wanted to preclude use of 'Later Versions' without permission,
>
> License: copyleft-next 0.1.0.
I'd suggest using something which is a bit more obvious than the
presence or absence of a period. Something which is more explicit,
such as the presence or absence "(or later)" is less likely to be
missed, or accidentally deleted while editing a source file.
I suggest
License: copyleft-next 0.1.0-only
This would help people write about the license in sentences using
precisely the same language as used in notices.
(But I wish the -only feature weren't in the license at all. At least
requiring unambiguous selection and notice of the feature is a
tremendous improvement over GPLv1/2/3. I think EUPL 1.1 may have been
first license like this "this Licence or of a later version of this
Licence unless the Original Work is expressly distributed only under
this version of the Licence" -- but I wonder if it is slightly
stronger than copyleft-next-0.1.0 is, not allowing "-only" to be added
by an adaptation.
Also EUPL 1.2
https://joinup.ec.europa.eu/sites/default/files/EUPL%20v1.2%20-%20Draft%2...
may end up being first to facilitate backwards compatibility, in the
draft EUPL 1.1 is one of the compatible licenses.).
Mike
1:27 p.m.
On 01/26/2013 02:11 PM, Mike Linksvayer wrote:
On Sat, Jan 26, 2013 at 10:42 AM, Theodore Ts'o
<tytso(a)mit.edu> wrote:
> On Sat, Jan 26, 2013 at 10:37:58AM -0500, Richard Fontana wrote:
>>
>> License: copyleft-next 0.1.0
>>
>> or, if I wanted to preclude use of 'Later Versions' without permission,
>>
>> License: copyleft-next 0.1.0.
>
> I'd suggest using something which is a bit more obvious than the
> presence or absence of a period. Something which is more explicit,
> such as the presence or absence "(or later)" is less likely to be
> missed, or accidentally deleted while editing a source file.
I suggest
License: copyleft-next 0.1.0-only
This would help people write about the license in sentences using
precisely the same language as used in notices.
(But I wish the -only feature weren't in the license at all. At least
requiring unambiguous selection and notice of the feature is a
tremendous improvement over GPLv1/2/3. I think EUPL 1.1 may have been
first license like this "this Licence or of a later version of this
Licence unless the Original Work is expressly distributed only under
this version of the Licence" -- but I wonder if it is slightly
stronger than copyleft-next-0.1.0 is, not allowing "-only" to be added
by an adaptation.
Also EUPL 1.2
https://joinup.ec.europa.eu/sites/default/files/EUPL%20v1.2%20-%20Draft%2...
may end up being first to facilitate backwards compatibility, in the
draft EUPL 1.1 is one of the compatible licenses.).
Interesting. I seem to remember backwards compatibility being briefly
discussed at a late stage in *GPLv3 drafting, I believe because of the
concerns that were then being raised about GPLv2-only/LGPLv3
incompatibility. I'll look more closely at the EUPL when I get a
chance. (I'm interested more generally in studying EUPL for possible
internationalization benefits.)
I suppose there could be problems with backwards compatibility. A lot
of GPL license compatibility theory (at least the theory I've
developed in my head) seems to be based on theoretical downstream
resolvability to GPLv3. I'll have to think about that.
- RF
1:16 p.m.
On 01/26/2013 01:42 PM, Theodore Ts'o wrote:
On Sat, Jan 26, 2013 at 10:37:58AM -0500, Richard Fontana wrote:
>
> License: copyleft-next 0.1.0
>
> or, if I wanted to preclude use of 'Later Versions' without permission,
>
> License: copyleft-next 0.1.0.
I'd suggest using something which is a bit more obvious than the
presence or absence of a period. Something which is more explicit,
such as the presence or absence "(or later)" is less likely to be
missed, or accidentally deleted while editing a source file.
The inclusion of the period in the 'preclusion of or-later' suggestion
was not meant to be meaningful - it was only a punctuation consequence
of following it with a paragraph containing the adaptation of Linus's
preliminary note in the Linux kernel COPYING file. (It was a
semi-joking suggestion, but I think the Linux kernel notice is
remarkably clear about how "or-later" is rejected unless there is some
indication to the contrary.)
Anyway, this goes to the policy question of what to do about or-later.
The three known approaches are
1) GPL approach: a) if no designation of a numbered version, any
version can be used (note in some situations this can be unclear); b)
if 'or later' is designated, any later version can be used; c)
otherwise you have to use the designated numbered version. The
non-clarity I refer to was probably what Linus picked up on when
deciding to put the caveat in the kernel COPYING file.
2) Typical approach of other OSI-approved licenses addressing later
versions (MPL, EPL etc.): everyone has permission to use a later
version, built in to the license text.
3) current copyleft-next approach: Default is 2), unless you make
clear that no permission to use later versions is granted.
Given that 3) *could* change, it may be a good idea to recommend some
standardized language for those who don't wish to give blanket
permission to use later versions (not necessarily the language I
suggested earlier).
- RF
9:17 p.m.
On Sat, Jan 26, 2013 at 02:16:46PM -0500, Richard Fontana wrote:
Anyway, this goes to the policy question of what to do about
or-later.
I'm pretty sure we've already discussed this once (although I don't
think any conclusion has been reached), but it seems to me that the
question of "or-later" is inextricably bound up in who and by what
process gets to decide what is an official "next version" of the
copyleft-next license.
Consider for the sake of argument, what might happen if some very
important piece of code starts using the copyleft-next license, and
then whatever organization which is handed the responsibility of
maintaining the copyleft-next license releases a new version which
basically says, "new rules! copyleft-next-v2 == new BSD-style license"
I would assume a large number of poeple, including those people who
trusted their code to a copyright-next 1.0-or-later license, would be
upset if something like this were to come to pass.
BTW, I find it really interesting that for all the FSF was
super-paranoid about what might happen if they were lose control of
their assets, didn't try to take steps to protect against a
theoretical future where an insufficient of true beleivers continue
their FSF membership, and a large number of "new blood" members vote
in a new board which approves a GPLv4 which substantially changes the
meaning the GPL (either by reverting the GPLv3-style Anti-Tivoization
to the GPLv2 definition, or by making the GPLv4 == BSD).
Of course, I'm not sure what kind of protections you can really place
to prevent this sort of thing, other than not allowing later versions
in the first place.
Note that this particular class of problems is not an issue which with
the Apache or other more permissive free software licenses, since you
can't add new restrictions in an effective manner (people can simply
refuse to upgrade to the new version, such as what the Linux Kernel
developers have done via-a-vis GPLv3). You can only make the license
be more relaxed. Given that you can't really make the Apache license
any more relaxed (except maybe in the clauses relating defensive
patent retribution clauses).
- Ted
12:35 a.m.
On 01/26/2013 10:17 PM, Theodore Ts'o wrote:
BTW, I find it really interesting that for all the FSF was
super-paranoid about what might happen if they were lose control of
their assets, didn't try to take steps to protect against a
theoretical future where an insufficient of true beleivers continue
their FSF membership, and a large number of "new blood" members vote
in a new board which approves a GPLv4 which substantially changes the
meaning the GPL (either by reverting the GPLv3-style Anti-Tivoization
to the GPLv2 definition, or by making the GPLv4 == BSD).
The FSF is not a membership organization in this sense. We run an
associate membership program, but associate members have no voting power
over the board or of management or of the unionized employees.
6:34 a.m.
On Sun, Jan 27, 2013 at 01:35:00AM -0500, Joshua Gay wrote:
The FSF is not a membership organization in this sense. We run an
associate membership program, but associate members have no voting power
over the board or of management or of the unionized employees.
Ah, I didn't realize that. So the FSF Board is a self-perpetuating
body then? It selects/elects its successors? If not, who is
responsible for electing/selecting the board members?
- Ted
9:58 p.m.
On Sun, Jan 27, 2013 at 2:17 PM, Theodore Ts'o <tytso(a)mit.edu> wrote:
Consider for the sake of argument, what might happen if some very
important piece of code starts using the copyleft-next license, and
then whatever organization which is handed the responsibility of
maintaining the copyleft-next license releases a new version which
basically says, "new rules! copyleft-next-v2 == new BSD-style license"
In the context of a program licensed under "GPLv3 or later", I remember
someone asking RMS that question during one of his public talks.
Unfortunately, I can no longer find a reference to his exact answer but my
recollection of it is that Section 14 covers that:
"Such new versions will be similar in spirit to the present version"
A non-copyleft GPLv4 would not be similar in spirit and so the "upgrade
clause" would no longer apply.
It does feel like a fairly weak protection though.
Cheers,
Francois
10:12 p.m.
On Mon, Jan 28, 2013 at 02:58:16PM +1100, Francois Marier wrote:
In the context of a program licensed under "GPLv3 or
later", I remember
someone asking RMS that question during one of his public talks.
Unfortunately, I can no longer find a reference to his exact answer but my
recollection of it is that Section 14 covers that:
"Such new versions will be similar in spirit to the present version"
A non-copyleft GPLv4 would not be similar in spirit and so the "upgrade
clause" would no longer apply.
Of course, this begs the question who gets to decide whether a new
verison is similar in spirit or not. I suppose it's possible that a
judge and/or a jury would rule that way. I'm not sure I would count
on that, though.
Does the fact that the GPLv3 add things like the anti-Tivoization
clause make it sufficiently different? Certainly the Linux kernel
development community thought the anti-Tivo clause made enough of a
significant difference that they rejected the license.
Trying to steer this back to the copyleft-next topic, it seems to me
until questions around how newer versions will be drafted and
officially blessed, and some kind of definition of what principles
would be used when creating a new version, I could imagine many
developers perhaps thinking twice about whether they would be willing
to use a "or later version" clause.
Speaking more generally, what makes the copyleft-next uniquely
"itself" in terms of how could we tell whether the next version is
similar in spirit to the current version? If the 2.0 version of
copyleft-next increases its word count by 90% (which is the percentage
increase from the GPLv2 at 2968 words to the GPLv3 weighing in at
5644), would it still have the same spirit? :-)
Regards,
- Ted
12:24 a.m.
I am liking it so far.
I had a question about termination (§11).
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
On 01/26/2013 12:13 AM, Richard Fontana wrote:
I suspect a v0.1.1 will arrive soon. :)
- RF
_______________________________________________
copyleft-next mailing list
copyleft-next(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
12:37 a.m.
On 01/27/2013 01:24 AM, Joshua Gay wrote:
I am liking it so far.
Thank you. BTW can you take a look at Plank 4 of the Harvey Birdman Rule?
https://gitorious.org/copyleft-next/copyleft-next/blobs/raw/master/CONTRI...
- RF
12:50 a.m.
New subject: Harvey Birdman Rule question
In section 4, where it states "top-posted replies to quoted earlier
mailing list postings". Does that simply mean that I should delete the
quoted text in my reply if I don't want it to be ignored by virtue of
this rule?
9:04 p.m.
New subject: Harvey Birdman Rule question
On 01/27/2013 01:50 AM, Joshua Gay wrote:
In section 4, where it states "top-posted replies to quoted
earlier
mailing list postings". Does that simply mean that I should delete the
quoted text in my reply if I don't want it to be ignored by virtue of
this rule?
It means you shouldn't top-post. :-)
- RF
4111
days inactive
4113
days old
copyleft-next@lists.fedorahosted.org
20 comments
7 participants
participants (7)
-
Claes Wallin (韋嘉誠) -
Francois Marier -
Joshua Gay -
Kuno Woudt -
Mike Linksvayer -
Richard Fontana -
Theodore Ts'o