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.
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/Relea... ?
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!
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/Relea... ?
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
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
On Jan 26, 2013 11:37 PM, "Richard Fontana" fontana@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.
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
On Sat, Jan 26, 2013 at 10:42 AM, Theodore Ts'o tytso@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%20EN... may end up being first to facilitate backwards compatibility, in the draft EUPL 1.1 is one of the compatible licenses.).
Mike
On 01/26/2013 02:11 PM, Mike Linksvayer wrote:
On Sat, Jan 26, 2013 at 10:42 AM, Theodore Ts'o tytso@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%20EN... 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
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
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
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.
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
On Sun, Jan 27, 2013 at 2:17 PM, Theodore Ts'o tytso@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
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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
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/CONTRIBUT...
- RF
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?
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
copyleft-next@lists.fedorahosted.org
-
Claes Wallin (韋嘉誠) -
Francois Marier -
Joshua Gay -
Kuno Woudt -
Mike Linksvayer -
Richard Fontana -
Theodore Ts'o