All:
Upon review of a recent release (0.1.1) I am wondering the following:
1. Will there be a FAQ? If there were a "place" to put explanations it may facilitate concision. There is precedent with the FSF FAQ's.
BFDL mentions a FAQ in slide 22 (see question 8 below).
2. Is the rationale for design decisions captured explicitly? The mailing list has provided a great deal of clarification regarding goals, approaches and thinking. However searching the mailing list for thinking on a specific point may be difficult. Is there a convention, for example, that changesets should document the rationale for changes on the affected lines? Short of having a good memory on the "oral tradition" of the license evolution would commit messages or any other approach answer the question "what is the point *that* phrase?" or "why did the BFDL choose this solution among alternates?"?
3. Why list in §10 specific license compatibility? In fact this is is more license *morphing* than compatibility. If, for example, copyleft-next is intended to plug loopholes of AGPL then does not §11 preserve such loopholes (through morphing)?
4. Is copyleft-next compatible with the EPL? This question is a troll.
5. Compliance freshness date encourages prompt remedies? Is the goal of §11.a to encourage coming in to compliance quickly else requiring You to negotiate a new license with Us? In other words downloading a new copy of the "Covered Work" does not reset the clock on a terminated license?
6. Does the definition of "Corresponding Source" combined with §7 effectively form an anti-lockdown provision? A Product shipping with Corresponding Source yet not runnable by rebuilding the Source (due to, for example, the lack of a certain cryptographic signature) would withhold freedom #1. It is not obvious that the interpretation of copyleft-next could simultaneously support lockdown and qualify as a Free Software license by supporting all four freedoms. Certain developers may believe there is a solution in explicitly allowing key replacement (such that private key material need not be disclosed).
7. What triggers derivation vs. aggregation? For the purpose of understanding the applicability of §5 is there a "bright line" test to distinguish aggregation? For example, if Object Code from the Covered Work is linked with a Separate Work is the result a Derived Work? Or if Object Code operates in conjunction with a Separate Work over a network connection is the result a Mere Aggregation?
8. Based on the FOSDEM presentation https://fosdem.org/2013/schedule/event/copyleft_next/ is the choice of a Hyena as a mascot an allusion to the unfortunate occurrence of tribal infighting (cannibalism?) in Free Software communities (first mentioned in a blog post long ago by Mark Shuttleworth)?
9. Proprietary relicensing deflation loophole Why offer a loophole of one year in §3 before deflation kicks in?
10. Getting to 201 lines All the metrics of copyleft-next are currently meeting objectives, except for line count. How can we best get down to 201 lines? Do we really need decorations for §13 and §14? That may be acceptable if it is an alternative for SCREAMING in all caps. Perhaps limiting decorations to the margins would eliminate 8 lines?
11. Will copyleft-next* (i.e. copyleft-next or copyleft-next-ns) be silent on data or try to incorporate the spirit of the Franklin Street Statement?
Regards,
--Tom
On Fri, Feb 08, 2013 at 04:40:12PM -0600, Tom Marble wrote:
All:
Upon review of a recent release (0.1.1) I am wondering the following:
- Will there be a FAQ?
RSN.
- Is the rationale for design decisions captured explicitly? The mailing list has provided a great deal of clarification regarding goals, approaches and thinking. However searching the mailing list for thinking on a specific point may be difficult.
Agreed. This concerns me.
Is there a convention, for example, that changesets should document the rationale for changes on the affected lines? Short of having a good memory on the "oral tradition" of the license evolution would commit messages or any other approach answer the question "what is the point *that* phrase?" or "why did the BFDL choose this solution among alternates?"?
Could you explain a bit more? I've tried to be good about informative commit messages. Would something more than this or different from this be helpful?
- Why list in §10 specific license compatibility? In fact this is is more license *morphing* than compatibility. If, for example, copyleft-next is intended to plug loopholes of AGPL then does not §11 preserve such loopholes (through morphing)?
You're right that it's license morphing, which is deemed by tradition to achieve GPL compatibility through magical means. This of course is problematic. But outbound (A)GPL compatibility is a design goal.
And yes, allowing "relicensing" under GPL/AGPL means that if such relicensing occurs or is deemed to occur, you get any problems (assuming such problems exist) in those outbound licenses restored. This is a drawback, but I've assumed that having copyleft-next be flat-out GPL-incompatible (I suppose AGPL doesn't seriously matter at this point) is worse than having that drawback.
Maybe there's a better way to handle GPL-compatibility (short of a GPLv4 with bi-directional copyleft-next compatibility being released in 2028). It's clear that the FSF regards magical relicensing clauses as an easy way to do it, and if the FSF thinks copyleft-next is GPL-compatible, so will the rest of the universe. I suppose I've been trying to avoid opening the can of worms of figuring out what magical relicensing clauses actually are, or do, but we might have to do so.
- Is copyleft-next compatible with the EPL? This question is a troll.
It is not compatible with the EPL. But I've been seriously thinking that the github person who suggested a far more liberal compatibility policy than we have with GPL may be on the right track. I think orthodox GPL compatibility doctrine may itself be a source of competitive disadvantage for strong copyleft.
- Compliance freshness date encourages prompt remedies? Is the goal of §11.a to encourage coming in to compliance quickly else requiring You to negotiate a new license with Us? In other words downloading a new copy of the "Covered Work" does not reset the clock on a terminated license?
"Termination of Your rights disqualifies You from receiving new licenses covering the Received Work...." (or does that not resolve the concern?)
- Does the definition of "Corresponding Source" combined with §7 effectively form an anti-lockdown provision?
No, or at least that is not the intention.
A Product shipping with Corresponding Source yet not runnable by rebuilding the Source (due to, for example, the lack of a certain cryptographic signature) would withhold freedom #1. It is not obvious that the interpretation of copyleft-next could simultaneously support lockdown and qualify as a Free Software license by supporting all four freedoms.
Can't the same be said of GPLv2, as interpreted by most who've tried to interpret it (including the FSF)? Not to mention noncopyleft licenses. It's also true of GPLv3 since the anti-lockdown provisions only apply to 'User Products'. GPLv3 legislative history will show that the FSF assumed that GPLv3-software-containing medical devices could be locked down.
Certain developers may believe there is a solution in explicitly allowing key replacement (such that private key material need not be disclosed).
- What triggers derivation vs. aggregation? For the purpose of understanding the applicability of §5 is there a "bright line" test to distinguish aggregation?
No more than in the GPL.
For example, if Object Code from the Covered Work is linked with a Separate Work is the result a Derived Work?
I don't think there's any clearer general answer than you'd get with the GPL.
Or if Object Code operates in conjunction with a Separate Work over a network connection is the result a Mere Aggregation?
That seems likely in most if not all cases.
A question underneath your question is whether copyleft-next (or copyleft-next + FAQ) could or should create more clarity around such questions than we've had with the GPL (or more precisely GPL + FSF FAQ + evolving customary interpretation).
Within the license itself, I'm not sure it's possible without making the license longer even than GPLv3.
- Based on the FOSDEM presentation https://fosdem.org/2013/schedule/event/copyleft_next/ is the choice of a Hyena as a mascot an allusion to the unfortunate occurrence of tribal infighting (cannibalism?) in Free Software communities (first mentioned in a blog post long ago by Mark Shuttleworth)?
I can confirm that this was *not* a reason for the choice of a hyena as the mascot.
However, while HBR does not require this disclosure, I will disclose that at lunch with Karen Sandler, Deb Nicholson, and Martin Michlmayr following that presentation, there appeared to be among those three individuals a unanimous sentiment that a hyena was a remarkably poor choice for a mascot.
- Proprietary relicensing deflation loophole Why offer a loophole of one year in §3 before deflation kicks in?
Here are the situations I was thinking of:
i) Foo Inc. does proprietary licensing of program P at T0. At T1 Foo ceases further proprietary licensing and places P under copyleft-next. This should not trigger the poison pill.
ii) Foo Inc., which has a proprietary software product P, is acquired by Bar Inc. Bar continues the ongoing business of Foo wrt P, but intends to transition towards what I'm afraid (as I believe you know) some companies call "open sourcing" of P. The process may be such that proprietary P will be distributed simultaneously with copyleft-next P during some time period.
Regarding case ii, I was influenced by something I remember Bradley once saying, that he thought it was reasonable for a company acquiring proprietary software assets to take a year to accomplish completion of a transition from proprietary to free.
So the year is a grace period. After that grace period expires, you no longer have any excuses and the poison pill kicks in. In a sense, by that point there is an irrebuttable presumption that the continued proprietary and copyleft licensing of P is nefarious. (That presumption is actually unfair, but I wouldn't want to have a grace period of more than a year.)
Maybe this makes things more complicated than is really necessary.
- Getting to 201 lines All the metrics of copyleft-next are currently meeting objectives, except for line count. How can we best get down to 201 lines? Do we really need decorations for §13 and §14? That may be acceptable if it is an alternative for SCREAMING in all caps. Perhaps limiting decorations to the margins would eliminate 8 lines?
That's a good idea. If Luis Villa ever sees this I'm curious to know what he'd think of that. 8 lines is a lot.
- Will copyleft-next* (i.e. copyleft-next or copyleft-next-ns) be silent on data or try to incorporate the spirit of the Franklin Street Statement?
I don't know yet.
- RF
On Fri, Feb 8, 2013 at 10:15 PM, Richard Fontana fontana@sharpeleven.org wrote:
On Fri, Feb 08, 2013 at 04:40:12PM -0600, Tom Marble wrote:
<snip>
- Proprietary relicensing deflation loophole Why offer a loophole of one year in §3 before deflation kicks in?
Here are the situations I was thinking of:
i) Foo Inc. does proprietary licensing of program P at T0. At T1 Foo ceases further proprietary licensing and places P under copyleft-next. This should not trigger the poison pill.
ii) Foo Inc., which has a proprietary software product P, is acquired by Bar Inc. Bar continues the ongoing business of Foo wrt P, but intends to transition towards what I'm afraid (as I believe you know) some companies call "open sourcing" of P. The process may be such that proprietary P will be distributed simultaneously with copyleft-next P during some time period.
Regarding case ii, I was influenced by something I remember Bradley once saying, that he thought it was reasonable for a company acquiring proprietary software assets to take a year to accomplish completion of a transition from proprietary to free.
So the year is a grace period. After that grace period expires, you no longer have any excuses and the poison pill kicks in. In a sense, by that point there is an irrebuttable presumption that the continued proprietary and copyleft licensing of P is nefarious. (That presumption is actually unfair, but I wouldn't want to have a grace period of more than a year.)
Maybe this makes things more complicated than is really necessary.
I had to go back and look at the language, because I hadn't thought of the "open sourcing" scenario (ii) and wasn't sure that in that case the evaporation would work. I'm still not sure, although I'm not entirely sure why. I think the word "offer" is what throws me off and wonder whether it might be understood to mean "initial offer." If so, then the initial offer was before the copyleft-next licensing and the evaporation doesn't come to pass. If you struck "offer to" would that hurt anything, i.e., "If, more than one year after Our first Distribution of the Received Work under this License, We license a work that would be a Covered Work had You prepared it, ...."? Removing the word "offer" removes any possible interpretation that it might mean "initial offer." But maybe it's just me.
Pam
On Fri, Feb 8, 2013 at 10:15 PM, Richard Fontana fontana@sharpeleven.org wrote:
On Fri, Feb 08, 2013 at 04:40:12PM -0600, Tom Marble wrote:
All:
Upon review of a recent release (0.1.1) I am wondering the following:
- Will there be a FAQ?
RSN.
- Is the rationale for design decisions captured explicitly? The mailing list has provided a great deal of clarification regarding goals, approaches and thinking. However searching the mailing list for thinking on a specific point may be difficult.
Agreed. This concerns me.
Is there a convention, for example, that changesets should document the rationale for changes on the affected lines? Short of having a good memory on the "oral tradition" of the license evolution would commit messages or any other approach answer the question "what is the point *that* phrase?" or "why did the BFDL choose this solution among alternates?"?
Could you explain a bit more? I've tried to be good about informative commit messages. Would something more than this or different from this be helpful?
- Why list in §10 specific license compatibility? In fact this is is more license *morphing* than compatibility. If, for example, copyleft-next is intended to plug loopholes of AGPL then does not §11 preserve such loopholes (through morphing)?
You're right that it's license morphing, which is deemed by tradition to achieve GPL compatibility through magical means. This of course is problematic. But outbound (A)GPL compatibility is a design goal.
And yes, allowing "relicensing" under GPL/AGPL means that if such relicensing occurs or is deemed to occur, you get any problems (assuming such problems exist) in those outbound licenses restored. This is a drawback, but I've assumed that having copyleft-next be flat-out GPL-incompatible (I suppose AGPL doesn't seriously matter at this point) is worse than having that drawback.
Maybe there's a better way to handle GPL-compatibility (short of a GPLv4 with bi-directional copyleft-next compatibility being released in 2028). It's clear that the FSF regards magical relicensing clauses as an easy way to do it, and if the FSF thinks copyleft-next is GPL-compatible, so will the rest of the universe. I suppose I've been trying to avoid opening the can of worms of figuring out what magical relicensing clauses actually are, or do, but we might have to do so.
- Is copyleft-next compatible with the EPL? This question is a troll.
It is not compatible with the EPL. But I've been seriously thinking that the github person who suggested a far more liberal compatibility policy than we have with GPL may be on the right track. I think orthodox GPL compatibility doctrine may itself be a source of competitive disadvantage for strong copyleft.
- Compliance freshness date encourages prompt remedies? Is the goal of §11.a to encourage coming in to compliance quickly else requiring You to negotiate a new license with Us? In other words downloading a new copy of the "Covered Work" does not reset the clock on a terminated license?
"Termination of Your rights disqualifies You from receiving new licenses covering the Received Work...." (or does that not resolve the concern?)
- Does the definition of "Corresponding Source" combined with §7 effectively form an anti-lockdown provision?
No, or at least that is not the intention.
A Product shipping with Corresponding Source yet not runnable by rebuilding the Source (due to, for example, the lack of a certain cryptographic signature) would withhold freedom #1. It is not obvious that the interpretation of copyleft-next could simultaneously support lockdown and qualify as a Free Software license by supporting all four freedoms.
Can't the same be said of GPLv2, as interpreted by most who've tried to interpret it (including the FSF)? Not to mention noncopyleft licenses. It's also true of GPLv3 since the anti-lockdown provisions only apply to 'User Products'. GPLv3 legislative history will show that the FSF assumed that GPLv3-software-containing medical devices could be locked down.
Certain developers may believe there is a solution in explicitly allowing key replacement (such that private key material need not be disclosed).
- What triggers derivation vs. aggregation? For the purpose of understanding the applicability of §5 is there a "bright line" test to distinguish aggregation?
No more than in the GPL.
For example, if Object Code from the Covered Work is linked with a Separate Work is the result a Derived Work?
I don't think there's any clearer general answer than you'd get with the GPL.
Or if Object Code operates in conjunction with a Separate Work over a network connection is the result a Mere Aggregation?
That seems likely in most if not all cases.
A question underneath your question is whether copyleft-next (or copyleft-next + FAQ) could or should create more clarity around such questions than we've had with the GPL (or more precisely GPL + FSF FAQ
- evolving customary interpretation).
Within the license itself, I'm not sure it's possible without making the license longer even than GPLv3.
- Based on the FOSDEM presentation https://fosdem.org/2013/schedule/event/copyleft_next/ is the choice of a Hyena as a mascot an allusion to the unfortunate occurrence of tribal infighting (cannibalism?) in Free Software communities (first mentioned in a blog post long ago by Mark Shuttleworth)?
I can confirm that this was *not* a reason for the choice of a hyena as the mascot.
However, while HBR does not require this disclosure, I will disclose that at lunch with Karen Sandler, Deb Nicholson, and Martin Michlmayr following that presentation, there appeared to be among those three individuals a unanimous sentiment that a hyena was a remarkably poor choice for a mascot.
- Proprietary relicensing deflation loophole Why offer a loophole of one year in §3 before deflation kicks in?
Here are the situations I was thinking of:
i) Foo Inc. does proprietary licensing of program P at T0. At T1 Foo ceases further proprietary licensing and places P under copyleft-next. This should not trigger the poison pill.
ii) Foo Inc., which has a proprietary software product P, is acquired by Bar Inc. Bar continues the ongoing business of Foo wrt P, but intends to transition towards what I'm afraid (as I believe you know) some companies call "open sourcing" of P. The process may be such that proprietary P will be distributed simultaneously with copyleft-next P during some time period.
Regarding case ii, I was influenced by something I remember Bradley once saying, that he thought it was reasonable for a company acquiring proprietary software assets to take a year to accomplish completion of a transition from proprietary to free.
So the year is a grace period. After that grace period expires, you no longer have any excuses and the poison pill kicks in. In a sense, by that point there is an irrebuttable presumption that the continued proprietary and copyleft licensing of P is nefarious. (That presumption is actually unfair, but I wouldn't want to have a grace period of more than a year.)
Maybe this makes things more complicated than is really necessary.
- Getting to 201 lines All the metrics of copyleft-next are currently meeting objectives, except for line count. How can we best get down to 201 lines? Do we really need decorations for §13 and §14? That may be acceptable if it is an alternative for SCREAMING in all caps. Perhaps limiting decorations to the margins would eliminate 8 lines?
That's a good idea. If Luis Villa ever sees this I'm curious to know what he'd think of that. 8 lines is a lot.
- Will copyleft-next* (i.e. copyleft-next or copyleft-next-ns) be silent on data or try to incorporate the spirit of the Franklin Street Statement?
I don't know yet.
- RF
copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
On Fri, Feb 08, 2013 at 10:44:14PM -0500, Pamela Chestek wrote:
On Fri, Feb 8, 2013 at 10:15 PM, Richard Fontana fontana@sharpeleven.org wrote:
ii) Foo Inc., which has a proprietary software product P, is acquired by Bar Inc. Bar continues the ongoing business of Foo wrt P, but intends to transition towards what I'm afraid (as I believe you know) some companies call "open sourcing" of P. The process may be such that proprietary P will be distributed simultaneously with copyleft-next P during some time period.
I had to go back and look at the language, because I hadn't thought of the "open sourcing" scenario (ii) and wasn't sure that in that case the evaporation would work. I'm still not sure, although I'm not entirely sure why. I think the word "offer" is what throws me off and wonder whether it might be understood to mean "initial offer." If so, then the initial offer was before the copyleft-next licensing and the evaporation doesn't come to pass. If you struck "offer to" would that hurt anything, i.e., "If, more than one year after Our first Distribution of the Received Work under this License, We license a work that would be a Covered Work had You prepared it, ...."? Removing the word "offer" removes any possible interpretation that it might mean "initial offer." But maybe it's just me.
This was a relatively recent change. Here's the commit message:
commit 415df2df927f6153032923b5d28f758784af2976 Author: Richard Fontana fontana@sharpeleven.org Date: Sun Jan 13 12:06:58 2013 -0500
Broaden Proprietary Relicensing section to cover "copyleft trolling".
The Proprietary Relicensing provision should also apply in circumstances where 'We' (perhaps including licensors downstream from the original licensor) offer to forgive past or future noncompliance with respect to a work 'We' do not distribute (e.g., what would be a downstream Derived Work but which is created by someone lateral to 'you') through purchase of a proprietary license.
There is some evidence that some purported GPL licensors are engaging in such behavior (rather than the more familiar case of announcing at the outset that proprietary licenses are available for the GPL-licensed work distributed by the licensor, or some enhanced the outset that proprietary licenses are available for the GPL-licensed work distributed by the licensor, or some enhanced version of it).
(It occurs to me that 'license' may not be a sufficient term.)
That said, I'm not sure 'offer to' is necessary to deal with this scenario, or whether it might be addressable in some better way. But that was the intention.
There's a new proprietary relicensing problem I just became aware of that I'm not sure how to address, if at all, but I'll note that in a different mailing list post.
- RF
On Sat, Feb 9, 2013 at 11:45 AM, Richard Fontana fontana@sharpeleven.org wrote:
On Fri, Feb 08, 2013 at 10:44:14PM -0500, Pamela Chestek wrote:
On Fri, Feb 8, 2013 at 10:15 PM, Richard Fontana fontana@sharpeleven.org wrote:
ii) Foo Inc., which has a proprietary software product P, is acquired by Bar Inc. Bar continues the ongoing business of Foo wrt P, but intends to transition towards what I'm afraid (as I believe you know) some companies call "open sourcing" of P. The process may be such that proprietary P will be distributed simultaneously with copyleft-next P during some time period.
I had to go back and look at the language, because I hadn't thought of the "open sourcing" scenario (ii) and wasn't sure that in that case the evaporation would work. I'm still not sure, although I'm not entirely sure why. I think the word "offer" is what throws me off and wonder whether it might be understood to mean "initial offer." If so, then the initial offer was before the copyleft-next licensing and the evaporation doesn't come to pass. If you struck "offer to" would that hurt anything, i.e., "If, more than one year after Our first Distribution of the Received Work under this License, We license a work that would be a Covered Work had You prepared it, ...."? Removing the word "offer" removes any possible interpretation that it might mean "initial offer." But maybe it's just me.
This was a relatively recent change. Here's the commit message:
commit 415df2df927f6153032923b5d28f758784af2976 Author: Richard Fontana fontana@sharpeleven.org Date: Sun Jan 13 12:06:58 2013 -0500
Broaden Proprietary Relicensing section to cover "copyleft trolling". The Proprietary Relicensing provision should also apply in circumstances where 'We' (perhaps including licensors downstream from the original licensor) offer to forgive past or future noncompliance with respect to a work 'We' do not distribute (e.g., what would be a downstream Derived Work but which is created by someone lateral to 'you') through purchase of a proprietary license. There is some evidence that some purported GPL licensors are engaging in such behavior (rather than the more familiar case of announcing at the outset that proprietary licenses are available for the GPL-licensed work distributed by the licensor, or some enhanced the outset that proprietary licenses are available for the GPL-licensed work distributed by the licensor, or some enhanced version of it).
(It occurs to me that 'license' may not be a sufficient term.)
That said, I'm not sure 'offer to' is necessary to deal with this scenario, or whether it might be addressable in some better way. But that was the intention.
In that scenario, I think my suggestion makes you worse off. And my scenario is already somewhat attenuated because I had to imply a meaning into "offer" (i.e., "initial offer") for it to be a problem. So I would leave "offer to" in.
Pam
On 02/08/2013 09:15 PM, Richard Fontana wrote:
On Fri, Feb 08, 2013 at 04:40:12PM -0600, Tom Marble wrote:
[...] Is there a convention, for example, that changesets should document the rationale for changes on the affected lines? Short of having a good memory on the "oral tradition" of the license evolution would commit messages or any other approach answer the question "what is the point *that* phrase?" or "why did the BFDL choose this solution among alternates?"?
Could you explain a bit more? I've tried to be good about informative commit messages. Would something more than this or different from this be helpful?
I was thinking of requesting that commit messages contain rationale for changes and that individual lines could be tracked via git blame: http://alblue.bandlem.com/2011/07/git-tip-of-week-assigning-blame.html
While this is generally a good practice it does not lend itself to a format which is readily accessible by muggles. Instead it may be helpful to collect rationale from the FOSDEM presentation (which provided excellent background) as well as some sort of companion document which includes annotations on each section.
This does increase the number of documents to the license, the FAQ and the Rationale, yet it seems this would be serve as a central location to better understand specific parts of the license as well as collect the thinking over the course of drafting.
And yes, allowing "relicensing" under GPL/AGPL means that if such relicensing occurs or is deemed to occur, you get any problems (assuming such problems exist) in those outbound licenses restored. This is a drawback, but I've assumed that having copyleft-next be flat-out GPL-incompatible (I suppose AGPL doesn't seriously matter at this point) is worse than having that drawback.
Would there be a way to allow relicensing with the added restriction of §3?
It is not compatible with the EPL. But I've been seriously thinking that the github person who suggested a far more liberal compatibility policy than we have with GPL may be on the right track. I think orthodox GPL compatibility doctrine may itself be a source of competitive disadvantage for strong copyleft.
While EPL compatibility would be very nice it should not come at the expense of weakening or adding loopholes to copyleft-next.
- Compliance freshness date encourages prompt remedies? Is the goal of §11.a to encourage coming in to compliance quickly else requiring You to negotiate a new license with Us? In other words downloading a new copy of the "Covered Work" does not reset the clock on a terminated license?
"Termination of Your rights disqualifies You from receiving new licenses covering the Received Work...." (or does that not resolve the concern?)
I think "everyone knows" you can't just re-download the code and restart the clock on the license, but something like this might prevent hucksters from attempting such an approach.
- Does the definition of "Corresponding Source" combined with §7 effectively form an anti-lockdown provision?
No, or at least that is not the intention.
I realize such a provision may not be popular with the more permissive minded on this list (including those from a permissive Linux mindset), yet I would like such a provision even if it specifically allowed key replacement (as to counteract the alarmist fears of private key disclosure).
I note that James Bottomley, on behalf of the Linux Foundation, offers such a key replacement approach for UEFI Secure Boot as discussed at Linux Conf Australia: http://linux.conf.au/schedule/30115/view_talk?day=thursday
So the year is a grace period. After that grace period expires, you no longer have any excuses and the poison pill kicks in. In a sense, by that point there is an irrebuttable presumption that the continued proprietary and copyleft licensing of P is nefarious. (That presumption is actually unfair, but I wouldn't want to have a grace period of more than a year.)
Maybe this makes things more complicated than is really necessary.
It seems generous and accommodates transitions. Thanks for the clarification.
Regards,
--Tom
On Sat, Feb 09, 2013 at 07:44:32PM -0600, Tom Marble wrote:
I was thinking of requesting that commit messages contain rationale for changes and that individual lines could be tracked via git blame: http://alblue.bandlem.com/2011/07/git-tip-of-week-assigning-blame.html
But isn't this what I've been doing, apart from the problem of not using "--author" (IIRC)?
While this is generally a good practice it does not lend itself to a format which is readily accessible by muggles. Instead it may be helpful to collect rationale from the FOSDEM presentation (which provided excellent background) as well as some sort of companion document which includes annotations on each section.
That's a good idea, at least in theory. I once suggested the FSF do something like that for GPLv3 post-release, and seems akin to the several 'rationale documents' that accompanied public GPLv3 drafts.
Would there be a way to allow relicensing with the added restriction of §3?
Do you mean with the poison pill persisting in a downstream relicensed-to-GPL universe?
I think not. For the usual case, this would seem not to matter. Section 3 is primarily intended to be (in really a mostly theoretical sense) a kind of self-imposed limitation applied by the original copyright holder who does proprietary relicensing. Permission to relicense under GPL is something given to downstream licensees. I suppose that a downstream licensee has to choose between enjoying GPL compatibility or being able to use the upstream code under a noncopyleft license if the upstream licensor makes the mistake of engaging in proprietary relicensing.
I say it's mostly theoretical because the purpose of the provision is actually to deter upstream licensors from using copyleft-next for proprietary relicensing. This is why it is very important to make the provision easier to understand somehow. Actually the audience of the provision is probably primarily lawyers (so it's important for the provision to be easy for lawyers to understand).
The more difficult case is the copyleft troll case which I mentioned recently. In the scenarios I've heard about, I am not at all sure that the copyleft troll isn't a downstream licensee. Here, you can imagine that a copyleft troll could escape the effect of the poison pill by relicensing to GPL. But that's okay. The world is no worse off than it was before copyleft-next existed.
That said, the copyleft troll problem is probably much smaller.
It is not compatible with the EPL. But I've been seriously thinking that the github person who suggested a far more liberal compatibility policy than we have with GPL may be on the right track. I think orthodox GPL compatibility doctrine may itself be a source of competitive disadvantage for strong copyleft.
While EPL compatibility would be very nice it should not come at the expense of weakening or adding loopholes to copyleft-next.
Right. I honestly don't know how to solve this problem yet.
I have recently heard rumors of an EPL 2.0. Maybe it will be made GPL-compatible.
- RF
On Fri, Feb 8, 2013 at 7:15 PM, Richard Fontana fontana@sharpeleven.org wrote:
- Getting to 201 lines All the metrics of copyleft-next are currently meeting objectives, except for line count. How can we best get down to 201 lines? Do we really need decorations for §13 and §14? That may be acceptable if it is an alternative for SCREAMING in all caps. Perhaps limiting decorations to the margins would eliminate 8 lines?
That's a good idea. If Luis Villa ever sees this I'm curious to know what he'd think of that. 8 lines is a lot.
DISCLAIMER: Lines is an awful metric for licenses as for code. You should use wordcount instead, each paragraph should be a single line, and your tools (pandoc FTW) should take care of creating a properly formatted output.
The Uniform Commercial Code (which as a general matter is the source of the mythology around ALL CAPS; see http://tieguy.org/blog/2012/08/19/a-quick-note-on-conspicuous-text-also-know... ) says that if characters are the same size (inevitably the case in a plain-text document) text can be made conspicuous by being "set off from surrounding text of the same size by symbols or other marks that call attention to the language."
"set off" is obviously not well-defined. I'd be inclined to be conservative and surround the text on all sides, but I could see the point of doing it only on the sides. If it were just on the sides, I'd be inclined to make it double-width, like so:
## foo ##
So as to make it *extremely* visible.
Luis
copyleft-next@lists.fedorahosted.org