Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
This is of course conceptually similar to the Creative Commons 'Founder's Copyright' idea and is related to general criticisms of present-day copyright term duration.
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
Please do not hesitate to shoot this down.
- RF
On 02/13/2013 10:40 PM, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
This is of course conceptually similar to the Creative Commons 'Founder's Copyright' idea and is related to general criticisms of present-day copyright term duration.
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
Please do not hesitate to shoot this down.
- RF
copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
Perhaps you might explain further the situation with the code you encountered today? I would like to see some further background on this edge case and your reasoning before even considering a shoot-down. Some of our kernel hacking compatriots can tell us what the lifespan of a piece of code **that is in active use** may be these days, I suppose.
Stephen Michael Kellat
On Wed, Feb 13, 2013 at 10:53:49PM -0500, Stephen Michael Kellat wrote:
Perhaps you might explain further the situation with the code you encountered today?
The issue involved what was arguably a derivative work of code published in 1979. I only mention it to show that issues relating to really old code can occasionally arise.
- RF
On Wed, Feb 13, 2013 at 10:40 PM, Richard Fontana fontana@sharpeleven.org wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
I'm assuming what you mean to happen after the limited term is that there is some effort to have the work enter a quasi-public domain status. The Founders Copyright has a licensing vehicle that it uses to mimic the public domain -- did you have something similar in mind?
I guess it depends on how confident you feel that a public domain commitment will be unproblematic. It will also mean that the copyleft goal is subverted with what might turn out to be fairly important software. Assuming you set a 30 year term, would it be ok for the early parts of Linux to enter the public domain in 10 years? Which brings up practical problems; it's active code that has creation dates spread over 20 years. Would you have to figure out what drops and what doesn't (which I suppose is an existing problem anyway, but one we'll confront much later)?
Perhaps you can elaborate more on why in your $DAYJOB situation the license made your task more difficult?
Pam
On Wed, Feb 13, 2013 at 11:00:39PM -0500, Pamela Chestek wrote:
I'm assuming what you mean to happen after the limited term is that there is some effort to have the work enter a quasi-public domain status. The Founders Copyright has a licensing vehicle that it uses to mimic the public domain -- did you have something similar in mind?
Not similar in the details, but rather what I was envisioning was the license becoming noncopyleft after a certain number of years.
Assuming you set a 30 year term, would it be ok for the early parts of Linux to enter the public domain in 10 years?
I was hoping Ted Ts'o might chime in. :)
Which brings up practical problems; it's active code that has creation dates spread over 20 years. Would you have to figure out what drops and what doesn't (which I suppose is an existing problem anyway, but one we'll confront much later)?
It wouldn't seem to be a problem in that respect, because it would be like the use of BSD-licensed code within otherwise-GPL'd Linux.
Perhaps you can elaborate more on why in your $DAYJOB situation the license made your task more difficult?
It was just to note the annoyance of having to deal with an issue concerning code published in 1979.
- RF
On Thu, Feb 14, 2013 at 01:29:59AM -0500, Richard Fontana wrote:
Assuming you set a 30 year term, would it be ok for the early parts of Linux to enter the public domain in 10 years?
I was hoping Ted Ts'o might chime in. :)
Because of the rapid pace of hardware change, it's highly unlikely that Linux from ten years ago would be particularly interesting for most people. This might be less true of mature, more slowly moving projects, that don't have hardware dependencies, such as GNU Emacs, however.
One nice thing about having a sunset clause like this is that it makes it easier to relicense code, since you only need to try to find/contact developers who have contributed to the project in the last ten years.
- Ted
On Thu, Feb 14, 2013 at 9:39 AM, Theodore Ts'o tytso@mit.edu wrote:
On Thu, Feb 14, 2013 at 01:29:59AM -0500, Richard Fontana wrote:
Assuming you set a 30 year term, would it be ok for the early parts of Linux to enter the public domain in 10 years?
I was hoping Ted Ts'o might chime in. :)
Because of the rapid pace of hardware change, it's highly unlikely that Linux from ten years ago would be particularly interesting for most people. This might be less true of mature, more slowly moving projects, that don't have hardware dependencies, such as GNU Emacs, however.
One nice thing about having a sunset clause like this is that it makes it easier to relicense code, since you only need to try to find/contact developers who have contributed to the project in the last ten years.
FWIW (and my opinion is probably the least important), I have been convinced that it would be worthwhile to have term limit on the copyleft and have the license reverts to a permissive one after that. My main concern was with the uncertainty of an effort to commit to the public domain, but a permissive license instead would solve the problem. I also wondered whether you would undermine the copyleft goal but it sounds like not; that after an appropriate period of time it isn't that likely that the software would be commercially appealing. In return, there would be some benefit for the legacy users; in particular you've solved the relicensing problem at the outset (which it sounds like is a real, not hypothetical, issue) rather than having to find copyright owners many years later.
Pam
On Thu, Feb 14, 2013 at 7:02 AM, Pamela Chestek pchestek@gmail.com wrote:
On Thu, Feb 14, 2013 at 9:39 AM, Theodore Ts'o tytso@mit.edu wrote:
On Thu, Feb 14, 2013 at 01:29:59AM -0500, Richard Fontana wrote:
Assuming you set a 30 year term, would it be ok for the early parts of Linux to enter the public domain in 10 years?
I was hoping Ted Ts'o might chime in. :)
Because of the rapid pace of hardware change, it's highly unlikely that Linux from ten years ago would be particularly interesting for most people. This might be less true of mature, more slowly moving projects, that don't have hardware dependencies, such as GNU Emacs, however.
One nice thing about having a sunset clause like this is that it makes it easier to relicense code, since you only need to try to find/contact developers who have contributed to the project in the last ten years.
FWIW (and my opinion is probably the least important), I have been convinced that it would be worthwhile to have term limit on the copyleft and have the license reverts to a permissive one after that. My main concern was with the uncertainty of an effort to commit to the public domain, but a permissive license instead would solve the problem. I also wondered whether you would undermine the copyleft goal but it sounds like not; that after an appropriate period of time it isn't that likely that the software would be commercially appealing. In return, there would be some benefit for the legacy users; in particular you've solved the relicensing problem at the outset (which it sounds like is a real, not hypothetical, issue) rather than having to find copyright owners many years later.
The relicensing issue is a bit of a clincher for me; I had not been strongly leaning one way or the other but it seems like a real, valuable win.
Luis
On Thu, Feb 14, 2013 at 08:13:28AM -0800, Luis Villa wrote:
The relicensing issue is a bit of a clincher for me; I had not been strongly leaning one way or the other but it seems like a real, valuable win.
I wonder if there's a way we could make this be automatic way of doing relicensing.
Specifically, consider the potential process where the project states that all new code commited into the project repository will be released under the following meta-license: "Before date XXXXX, this code is licensed under copyleft-next 1.0; after date XXXX, this code is licensed under the terms described under copyleft-next 2.0."
This would mean that it would take ten years (or whatever the timeout period might be) to transition to a new license, but it means that it eliminates one of the excuses for wanting CLA's, with all of the disincentives to developers joining a process because of a requirement to sign legal documents before a developer can participate in a project.
- Ted
On 2013-02-14 11:40, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
It is an excellent idea! I'd like to think this idea has been brewing in your mind since I mentioned it about a year ago. :-)
I had the idea when I saw @zooko's license, which is precisely the opposite -- permissive for two years (IIRC), then strengthening to copyleft.
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
Yes. I view the "delayed permissive" function as an alternative way of handling the license upgrade issue, one that removes any "or later" or "decision proxy organization" complexities.
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
This is of course conceptually similar to the Creative Commons 'Founder's Copyright' idea and is related to general criticisms of present-day copyright term duration.
I will look this up.
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
15 years is a very long time. For example, bringing Linux 2.2 up to shape to be commercially usable today would require a massive amount of work. It's almost irrelevant for practical purposes what license Linux 2.2 is under.
If this is meant to have any practical effect, I would suggest 10 years or even 5 years.
But couldn't this be up to the project licensing the software? Of course, to make this useful in any way, the project would need to have a clear policy that all incoming contributions would be under the same delayed-permissive terms, so that one could look at a consistent X-year-old tree and know that it was now permissively licensed.
Please do not hesitate to shoot this down.
Leaving that to somebody else. I am enthusiastic that this has been brought up.
For me, this kind of arrangement would be the main use of a "permissive-next" license.
On 2013-02-14 12:19, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-14 11:40, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
It is an excellent idea! I'd like to think this idea has been brewing in your mind since I mentioned it about a year ago. :-)
I had the idea when I saw @zooko's license, which is precisely the opposite -- permissive for two years (IIRC), then strengthening to copyleft.
One year.
https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/COPYING.TGPPL.rst
"to distribute or communicate copies of the Original Work and Derivative Works to the public, with the proviso that copies of Original Work or Derivative Works that You distribute or communicate shall be licensed under this Transitive Grace Period Public Licence no later than 12 months after You distributed or communicated said copies"
@zooko is https://identi.ca/zooko .
On Thu, Feb 14, 2013 at 12:19:28PM +0800, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-14 11:40, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
It is an excellent idea! I'd like to think this idea has been brewing in your mind since I mentioned it about a year ago. :-)
I knew someone had mentioned it, though I couldn't remember who.
I had the idea when I saw @zooko's license, which is precisely the opposite -- permissive for two years (IIRC), then strengthening to copyleft.
Right, this occurred to me too.
But couldn't this be up to the project licensing the software?
It could. Of course this can be achieved today under the GPL with an exception/additional permission (and one could do the same with copyleft-next).
- RF
On Wednesday, February 13 2013, 23:19:28, Claes Wallin (韋嘉誠) wrote:
15 years is a very long time. For example, bringing Linux 2.2 up to shape to be commercially usable today would require a massive amount of work. It's almost irrelevant for practical purposes what license Linux 2.2 is under.
If this is meant to have any practical effect, I would suggest 10 years or even 5 years.
True, but VMWare bootstraps off of 2.4.x series kernels and those are 10-12 years old, and the Xenlinux for Xen dom0 patches hang off of old 2.6.18 kernels (circa 2006,) which I suspect are still *incredibly* prevalent in actual deployments.
I'm not sure what the conclusion is: it's safe to say that there's a lot of very widely deployed GPL'd software that's 5 or even 10 years old. I'm not sure a sunset on the copyleft would have any real deleterious effects.
(On the other hand, if a sunset provides incentives for third parties to maintain old software longer than the original maintainer did; it might discourage slow moving organizations from supporting/contributing to current development efforts, which wouldn't be ideal. Also unlikely and somewhat contrived.)
Cheers, sam
-- Sam Kleinman (tychoish): - garen@tychoish.com - tychoish http://tychoish.com/ "don't get it right, get it written" -- james thurber
On Thu, Feb 14, 2013 at 4:40 PM, Richard Fontana fontana@sharpeleven.org wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
I really like the idea. It's an elegant hack on the ever-increasing copyright term. It would also put a bound on the amount of work involved in relicensing old pieces of code with lots of unreachable contributors.
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
Are there examples of 20 year-old copyleft code that would be useful today as it was published 20 years ago? In other words, in 5 years, could someone fork the 1998 Linux kernel and do something that would threaten the GPL project in any way?
Francois
On 2013-02-14 12:24, Francois Marier wrote:
On Thu, Feb 14, 2013 at 4:40 PM, Richard Fontana fontana@sharpeleven.org wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
I really like the idea. It's an elegant hack on the ever-increasing copyright term. It would also put a bound on the amount of work involved in relicensing old pieces of code with lots of unreachable contributors.
Exactly. It is an upper bound on the consequences of a mistaken licensing choice. Unless of course that licensing choice were a permissive license. :-)
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
Are there examples of 20 year-old copyleft code that would be useful today as it was published 20 years ago? In other words, in 5 years, could someone fork the 1998 Linux kernel and do something that would threaten the GPL project in any way?
I find it unlikely that the 2003 Linux Kernel would be a threat to the mainline. Useful, yes. Possibly even commercially viable. But not for the same uses as the mainline.
OTOH, people are still running Windows XP, which is around 10 years old. OTOOH, the version people are actually using is SP4, which is just under 5 years old.
On 02/14/2013 04:40 AM, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
The only reason I can see for wanting this is to deal with copyleft license compatibility issues. Which in my experience are not enough of a problem to weaken the copyleft nature of the work in this way.
-- kuno / warp.
On Thu, Feb 14, 2013 at 06:53:51AM +0100, Kuno Woudt wrote:
On 02/14/2013 04:40 AM, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
[...]
The only reason I can see for wanting this is to deal with copyleft license compatibility issues. Which in my experience are not enough of a problem to weaken the copyleft nature of the work in this way.
Since you are the only person I know of who is actually using copyleft-next as a license, this is enough to make me want to reject the idea (or at most make it an optional configuration, but in that case I'm not sure it's worth the extra words/lines of text). :)
- RF
On Thu, Feb 14, 2013 at 06:53:51AM +0100, Kuno Woudt wrote:
On 02/14/2013 04:40 AM, Richard Fontana wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
The only reason I can see for wanting this is to deal with copyleft license compatibility issues. Which in my experience are not enough of a problem to weaken the copyleft nature of the work in this way.
Out of curiosity: If you were writing a new copyright statute to cover software, how long would you make the duration of copyright?
- RF
On 2013-02-16 10:38, Richard Fontana wrote:
On Thu, Feb 14, 2013 at 06:53:51AM +0100, Kuno Woudt wrote:
On 02/14/2013 04:40 AM, Richard Fontana wrote:
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
The only reason I can see for wanting this is to deal with copyleft license compatibility issues. Which in my experience are not enough of a problem to weaken the copyleft nature of the work in this way.
Out of curiosity: If you were writing a new copyright statute to cover software, how long would you make the duration of copyright?
Five, with the ability to extend with five more if registered and source code placed in escrow for the public upon expiration.
Out of curiosity: If you were writing a new copyright statute to cover software, how long would you make the duration of copyright?
Five, with the ability to extend with five more if registered and source code placed in escrow for the public upon expiration.
Interesting question the way you worded it - "a new copyright statute to cover software." I read it to mean the same scheme as now, which is same term for all types of works. To that, I would say between 30 years and life of the author, but not longer. I do believe that an author of a work should get all the income from the work as long as it's at a commercial level of income production. So you get to earn the fruits of your labor but your kids are on their own. Part of this might be to protect moral rights too, so that an artist doesn't have to witness the mutilation of their work.
Software is a different thing, though. It's continuously improved (so you don't want to protect against "mutilation") and has a shorter commercial lifespan which would suggest a much shorter term of protection. Five seems short to me, but I don't really know. I probably would have said 10.
Pam
On 16/02/2013 06:41 πμ, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-16 10:38, Richard Fontana wrote:
On Thu, Feb 14, 2013 at 06:53:51AM +0100, Kuno Woudt wrote:
On 02/14/2013 04:40 AM, Richard Fontana wrote:
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
The only reason I can see for wanting this is to deal with copyleft license compatibility issues. Which in my experience are not enough of a problem to weaken the copyleft nature of the work in this way.
Out of curiosity: If you were writing a new copyright statute to cover software, how long would you make the duration of copyright?
Five, with the ability to extend with five more if registered and source code placed in escrow for the public upon expiration.
How would source code escrow work? The only setup I can think of involves you shipping a full (compiler and all) build system along with the source, them building the binary for you and you only being allowed to distribute the binaries that they have built. Doesn't sound very practical (or trustworthy). Maybe you had something else in mind?
Angelos
On 2013-02-16 23:19, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:41 πμ, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-16 10:38, Richard Fontana wrote:
On Thu, Feb 14, 2013 at 06:53:51AM +0100, Kuno Woudt wrote:
On 02/14/2013 04:40 AM, Richard Fontana wrote:
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
The only reason I can see for wanting this is to deal with copyleft license compatibility issues. Which in my experience are not enough of a problem to weaken the copyleft nature of the work in this way.
Out of curiosity: If you were writing a new copyright statute to cover software, how long would you make the duration of copyright?
Five, with the ability to extend with five more if registered and source code placed in escrow for the public upon expiration.
How would source code escrow work? The only setup I can think of involves you shipping a full (compiler and all) build system along with the source, them building the binary for you and you only being allowed to distribute the binaries that they have built. Doesn't sound very practical (or trustworthy). Maybe you had something else in mind?
The standard for the code in escrow would be the same as for the CCS of GPL'ed binaries shipped today. If the source code is not usable, the person who would have benefited from it can sue you for damages, in a similar way as copyright owners are today suing people who ship derivatives of their GPL'ed code without proper CCS.
On 16/02/2013 06:42 μμ, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-16 23:19, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:41 πμ, "Claes Wallin (韋嘉誠)" wrote:
[...]
Five, with the ability to extend with five more if registered and source code placed in escrow for the public upon expiration.
How would source code escrow work? The only setup I can think of involves you shipping a full (compiler and all) build system along with the source, them building the binary for you and you only being allowed to distribute the binaries that they have built. Doesn't sound very practical (or trustworthy). Maybe you had something else in mind?
The standard for the code in escrow would be the same as for the CCS of GPL'ed binaries shipped today. If the source code is not usable, the person who would have benefited from it can sue you for damages, in a similar way as copyright owners are today suing people who ship derivatives of their GPL'ed code without proper CCS.
OK. My understanding was that the point of having the code in escrow would be so that you wouldn't have to just rely on a legal obligation of the other party (as said party might not even be around to sue anymore N years in the future). I don't see what escrow adds on top of the legal obligation in what you describe, but maybe I'm misunderstanding the terminology.
BTW, I'm not sure this is on-topic anymore :) Angelos
On 2013-02-17 11:10, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:42 μμ, "Claes Wallin (韋嘉誠)" wrote:
The standard for the code in escrow would be the same as for the CCS of GPL'ed binaries shipped today. If the source code is not usable, the person who would have benefited from it can sue you for damages, in a similar way as copyright owners are today suing people who ship derivatives of their GPL'ed code without proper CCS.
OK. My understanding was that the point of having the code in escrow would be so that you wouldn't have to just rely on a legal obligation of the other party (as said party might not even be around to sue anymore N years in the future). I don't see what escrow adds on top of the legal obligation in what you describe, but maybe I'm misunderstanding the terminology.
Good point! I will think about this.
On 2013-02-17 11:10, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:42 μμ, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-16 23:19, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:41 πμ, "Claes Wallin (韋嘉誠)" wrote:
[...]
Five, with the ability to extend with five more if registered and source code placed in escrow for the public upon expiration.
How would source code escrow work? The only setup I can think of involves you shipping a full (compiler and all) build system along with the source, them building the binary for you and you only being allowed to distribute the binaries that they have built. Doesn't sound very practical (or trustworthy). Maybe you had something else in mind?
The standard for the code in escrow would be the same as for the CCS of GPL'ed binaries shipped today. If the source code is not usable, the person who would have benefited from it can sue you for damages, in a similar way as copyright owners are today suing people who ship derivatives of their GPL'ed code without proper CCS.
... or indeed in the same way as third-party benificiaries to the copyleft-next 0.2.0. :-)
OK. My understanding was that the point of having the code in escrow would be so that you wouldn't have to just rely on a legal obligation of the other party (as said party might not even be around to sue anymore N years in the future). I don't see what escrow adds on top of the legal obligation in what you describe, but maybe I'm misunderstanding the terminology.
Ok, I have thought about it.
I think one advantage of escrow compared to release upon expiration is that it requires at least a reasonable effort to get the CCS, and to show some minimally credible CCS before being able to extend another five years.
For an applicant that is not malicious, merely unorganized, this could create benefits for the public, although it's difficult to say how great.
Another advantage is if the copyright owners or at least the people capable of producing the CCS disappear during the second five-year-term. By putting it in escrow it enforces the need to do the work of packaging it all up before getting the extension.
If analysis shows that this kind of escrow would give enough benefits, that the risk of the source code being useless for reproducing the binaries is too great, then I can imagine a stronger model:
Source code is published, but with all rights reserved, except the right to use the source to produce a working binary and verify its function.
On 2013-02-17 11:10, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:42 μμ, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-16 23:19, Angelos Oikonomopoulos wrote:
On 16/02/2013 06:41 πμ, "Claes Wallin (韋嘉誠)" wrote:
[...]
Five, with the ability to extend with five more if registered and
source
code placed in escrow for the public upon expiration.
How would source code escrow work? The only setup I can think of involves you shipping a full (compiler and all) build system along with the source, them building the binary for you and you only being allowed to distribute the binaries that they have built. Doesn't sound very practical (or trustworthy). Maybe you had something else in mind?
The standard for the code in escrow would be the same as for the CCS of GPL'ed binaries shipped today. If the source code is not usable, the person who would have benefited from it can sue you for damages, in a similar way as copyright owners are today suing people who ship derivatives of their GPL'ed code without proper CCS.
... or indeed in the same way as third-party benificiaries to the copyleft-next 0.2.0. :-)
OK. My understanding was that the point of having the code in escrow would be so that you wouldn't have to just rely on a legal obligation of the other party (as said party might not even be around to sue anymore N years in the future). I don't see what escrow adds on top of the legal obligation in what you describe, but maybe I'm misunderstanding the terminology.
Ok, I have thought about it.
I think one advantage of escrow compared to release upon expiration is that it requires at least a reasonable effort to get the CCS, and to show some minimally credible CCS before being able to extend another five years.
For an applicant that is not malicious, merely unorganized, this could create benefits for the public, although it's difficult to say how great.
Another advantage is if the copyright owners or at least the people capable of producing the CCS disappear during the second five-year-term. By putting it in escrow it enforces the need to do the work of packaging it all up before getting the extension.
If analysis shows that this kind of escrow would give enough benefits, that the risk of the source code being useless for reproducing the binaries is too great, then I can imagine a stronger model:
Source code is published, but with all rights reserved, except the right to use the source to produce a working binary and verify its function.
On 2013-02-20 21:55, "Claes Wallin (韋嘉誠)" wrote:
If analysis shows that this kind of escrow would give enough benefits, that the risk of the source code being useless for reproducing the binaries is too great, then I can imagine a stronger model:
That is, if best-effort escrow would *not* give enough benefits.
Source code is published, but with all rights reserved, except the right to use the source to produce a working binary and verify its function.
... which would mean that you could, as a beneficiary who finds the published source useless, force them to improve the published source even before the second five-year term is over, or prove that the published source can indeed produce a working and equivalent binary.
On 2013-02-20 22:01, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-20 21:55, "Claes Wallin (韋嘉誠)" wrote:
If analysis shows that this kind of escrow would give enough benefits, that the risk of the source code being useless for reproducing the binaries is too great, then I can imagine a stronger model:
That is, if best-effort escrow would *not* give enough benefits.
Source code is published, but with all rights reserved, except the right to use the source to produce a working binary and verify its function.
... which would mean that you could, as a beneficiary who finds the published source useless, force them to improve the published source even before the second five-year term is over, or prove that the published source can indeed produce a working and equivalent binary.
Come to think of it, a similar mechanism could be employed against useless overbroad patents as well. If the information contained in the patent cannot be used to reproduce anything useful, the patent should be invalidated, as the original quid-pro-quo of disclosure for monopoly is then not upheld.
On 2013-02-20 22:01, "Claes Wallin (韋嘉誠)" wrote:
On 2013-02-20 21:55, "Claes Wallin (韋嘉誠)" wrote:
If analysis shows that this kind of escrow would give enough benefits, that the risk of the source code being useless for reproducing the binaries is too great, then I can imagine a stronger model:
That is, if best-effort escrow would *not* give enough benefits.
Source code is published, but with all rights reserved, except the right to use the source to produce a working binary and verify its function.
... which would mean that you could, as a beneficiary who finds the published source useless, force them to improve the published source even before the second five-year term is over, or prove that the published source can indeed produce a working and equivalent binary.
Come to think of it, a similar mechanism could be employed against useless overbroad patents as well. If the information contained in the patent cannot be used to reproduce anything useful, the patent should be invalidated, as the original quid-pro-quo of disclosure for monopoly is then not upheld.
On Wed, Feb 13, 2013 at 7:40 PM, Richard Fontana fontana@sharpeleven.org wrote:
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
This is of course conceptually similar to the Creative Commons 'Founder's Copyright' idea and is related to general criticisms of present-day copyright term duration.
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
Please do not hesitate to shoot this down.
I've been slowly warming up to this idea for the last year, which I attribute in part to becoming less annoyed at all the things wrong with 'Founder's Copyright' (inducement of unbalanced ticks perhaps the most minor).
Some things referenced in http://wiki.creativecommons.org/4.0/Sandbox#Time-based_switch_to_more_freedo... might be interesting.
Anyway, now I wholly support it, for roughly three reasons, the 2nd being by far the most important for copyleft-next:
1) public copyright licenses have largely not borne any relation to copyright reform proposals (the ones that mitigate copyright restrictions anyway) other than the general sense that they mitigate copyright restrictions (there's also the problem that public licenses have largely not inspired copyright reform proposals, but I think that's a different problem). I think there's a lot of space to explore licenses that do reflect the usual reform proposals. Maybe much of this space "should not" be explored, but see (3).
2) In part due to (1), inclusion of any limited term in copyleft-next would be a genius marketing gambit. It would be cited in more law review papers. If potential copyleft-next users are afraid that they might lose the ability to do (or delegate) the work that is very hard and boring and nobody but a few heroes wish to do (I listened to http://faif.us/cast/2013/feb/13/0x37/ today see) after some number of years sometimes deemed reasonable or efficient or merely with ancient historical precedent, ie a dangerous weakening of copyleft, make it an absurdly long period, say 50 years. Which also serves to point out how absurdly long life+70 or 95 years are.
3) The space of public licenses as art projects is under-explored (though as someone reminded me last week, one might characterize the early days of Creative Commons as trending that way, mostly unawares).
Mike
Hi,
I really like and second this idea. I'll seriously consider releasing my code under copyleft-next if this idea is realized nicely, since there is no other well-known FLOSS license now which has similar clause, AFAIK. I think this will make copyleft-next quite distinctive.
Some economics literature tries to estimate the optimal copyright term. For example, Boldrin & Levine (2009) [1] thinks the term should zero at all but 2 years would be an acceptable compromise. Pollock (2007) [2] gives 14 years. It depends on the "decay" rate of value, and my hunch is that the decay rate of program code is higher than those of copyrighted works in general. Maybe 10 years would be a good choice?
Best regards, MH
-- Masayuki Hatta Assistant Professor of Economics, Surugadai University, Japan mhatta@gnu.org / mhatta@debian.org / mhatta@mhatta.org / hatta.masayuki@surugadai.ac.jp
[1] http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1432245 [2] http://www.rufuspollock.org/economics/papers/optimal_copyright.pdf
2013/2/14 Richard Fontana fontana@sharpeleven.org
Does anyone think the idea of a limited-term copyleft -- particularly given that copyleft-next is a software-oriented license -- is a good/bad idea?
We're now a few years from the point where there could be 30-year-old code under GPL-like licenses. I have found from $DAYJOB experience that one occasionally has to deal with legal issues concerning *really* old code (in a situation I dealt with today, from 1979; admittedly that's unusual).
The idea would be to have the copyleft terms disappear after some limited period far short of the statutory copyright term.
This is of course conceptually similar to the Creative Commons 'Founder's Copyright' idea and is related to general criticisms of present-day copyright term duration.
If anyone thinks it's a good idea, what would be a good copyleft duration? 15, 20, 25 years?
Please do not hesitate to shoot this down.
- RF
copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
copyleft-next@lists.fedorahosted.org