Just curious if anyone has thought about, looked at, or drafted a permissive license based on the structure, organization, and terminology of copyleft.next.
On 09/22/2012 03:34 PM, Luis Villa wrote:
Just curious if anyone has thought about, looked at, or drafted a permissive license based on the structure, organization, and terminology of copyleft.next.
In fact I have thought about it (but didn't go beyond the 'thought' stage), not too after I had already started the project. Once a certain level of simplification of structure was achieved I realized it wouldn't be difficult to achieve this. Whether it is worth doing is an interesting idea to ponder.
- Richard
On Sat, Sep 22, 2012 at 2:58 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 09/22/2012 03:34 PM, Luis Villa wrote:
Just curious if anyone has thought about, looked at, or drafted a permissive license based on the structure, organization, and terminology of copyleft.next.
In fact I have thought about it (but didn't go beyond the 'thought' stage), not too after I had already started the project. Once a certain level of simplification of structure was achieved I realized it wouldn't be difficult to achieve this. Whether it is worth doing is an interesting idea to ponder.
If nothing else, it would be an interesting drafting exercise and might point out structural issues.
(And I do think, if I could snap my fingers and change all licenses at once, having parallel licenses akin to CC-BY/CC-SA/CC-ND for Apache/MPL/EPL/GPL/AGPL would be a huge win for the world.)
Luis
On Sat, Sep 22, 2012 at 3:03 PM, Luis Villa luis@tieguy.org wrote:
On Sat, Sep 22, 2012 at 2:58 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 09/22/2012 03:34 PM, Luis Villa wrote:
Just curious if anyone has thought about, looked at, or drafted a permissive license based on the structure, organization, and terminology of copyleft.next.
In fact I have thought about it (but didn't go beyond the 'thought' stage), not too after I had already started the project. Once a certain level of simplification of structure was achieved I realized it wouldn't be difficult to achieve this. Whether it is worth doing is an interesting idea to ponder.
If nothing else, it would be an interesting drafting exercise and might point out structural issues.
I'd love to see it. As I've carped elsewhere, the state of the art of permissive licenses is pretty poor.
(And I do think, if I could snap my fingers and change all licenses at once, having parallel licenses akin to CC-BY/CC-SA/CC-ND for Apache/MPL/EPL/GPL/AGPL would be a huge win for the world.)
ND really?
If I could snap my fingers, there would be no parallel licenses; only a set of public domain->permissive->weak copylefts->strong copyleft->network copyleft instruments for all overlapping magisteria (and they all do).
Mike
On Wed, Sep 26, 2012 at 10:09 AM, Mike Linksvayer ml@gondwanaland.com wrote:
On Sat, Sep 22, 2012 at 3:03 PM, Luis Villa luis@tieguy.org wrote:
On Sat, Sep 22, 2012 at 2:58 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 09/22/2012 03:34 PM, Luis Villa wrote:
Just curious if anyone has thought about, looked at, or drafted a permissive license based on the structure, organization, and terminology of copyleft.next.
In fact I have thought about it (but didn't go beyond the 'thought' stage), not too after I had already started the project. Once a certain level of simplification of structure was achieved I realized it wouldn't be difficult to achieve this. Whether it is worth doing is an interesting idea to ponder.
If nothing else, it would be an interesting drafting exercise and might point out structural issues.
I'd love to see it. As I've carped elsewhere, the state of the art of permissive licenses is pretty poor.
(And I do think, if I could snap my fingers and change all licenses at once, having parallel licenses akin to CC-BY/CC-SA/CC-ND for Apache/MPL/EPL/GPL/AGPL would be a huge win for the world.)
ND really?
I knew I should have clarified that. Only included it to point out that a common framework does not prevent a rich/complex spectrum of permissiveness (akin to the finer shades between MPL/LGPL/GPL/AGPL), not to advocate that the free software world should have a specific NC or ND equivalent.
Luis
Hello,
On 09/26/2012 07:19 PM, Luis Villa wrote:
I knew I should have clarified that. Only included it to point out that a common framework does not prevent a rich/complex spectrum of permissiveness (akin to the finer shades between MPL/LGPL/GPL/AGPL), not to advocate that the free software world should have a specific NC or ND equivalent.
A license which is currently "missing" on that spectrum is a copyleft license compatible with the current popular app stores.
The microsoft and apple app stores are fairly hostile toward free software developers, but they do have a considerable market share. So I think there are free software developers who would be interested in a license which achieves the aims of copyleft insofar that is allowed by the common app store agreements.
Has anyone given this any thought?
-- kuno / warp.
On 09/27/2012 02:47 AM, Kuno Woudt wrote:
A license which is currently "missing" on that spectrum is a copyleft license compatible with the current popular app stores.
The microsoft and apple app stores are fairly hostile toward free software developers, but they do have a considerable market share. So I think there are free software developers who would be interested in a license which achieves the aims of copyleft insofar that is allowed by the common app store agreements.
Has anyone given this any thought?
I haven't thought about it (until now) in connection with copyleft-next, but this is a good suggestion to consider. The problem seems analogous to the problem that the old GPL system library exception was trying to solve (or clarify).
This goes in the still non-existent issue tracker. :)
- Richard
On 09/27/2012 02:47 AM, Kuno Woudt wrote:
A license which is currently "missing" on that spectrum is a copyleft license compatible with the current popular app stores.
Richard Fontana wrote on 27 September:
I haven't thought about it (until now) in connection with copyleft-next, but this is a good suggestion to consider.
I don't agree. I think the copyleft-incompatibility of app stores is specifically designed to work against the software freedom of users, particularly in Apple's case. In Google's case, they demand a permissive license from the author for Google's own benefit, which means there's no way copyleft-next could do that unless it had a "permissive out especially for Google" clause, which I think would be a bad idea.
App stores are just a way to distribute software. Why should some distributions get special treatment?
Luis' points are interesting on this: a true app-store that wants to DTRT should actually have no trouble complying with copyleft-next, or AGPLv3, for that matter!
On Thu, Oct 11, 2012 at 4:13 AM, Bradley M. Kuhn bkuhn@ebb.org wrote:
On 09/27/2012 02:47 AM, Kuno Woudt wrote:
A license which is currently "missing" on that spectrum is a copyleft license compatible with the current popular app stores.
Richard Fontana wrote on 27 September:
I haven't thought about it (until now) in connection with copyleft-next, but this is a good suggestion to consider.
I don't agree. I think the copyleft-incompatibility of app stores is specifically designed to work against the software freedom of users, particularly in Apple's case. In Google's case, they demand a permissive license from the author for Google's own benefit, which means there's no way copyleft-next could do that unless it had a "permissive out especially for Google" clause, which I think would be a bad idea.
App stores are just a way to distribute software. Why should some distributions get special treatment?
To be clear, they are a form of distribution where the distributor is really minimally interested and wants to have the minimum possible involvement. And I think that's actually OK, and is distinguishable from other forms of distribution. So we do want to think about how to make that possible. It's just that I think that the modern licenses *do* make that possible as long as the distributor is a neutral conduit and doesn't actively trample people's rights under the licenses.
As an interesting note, and something I will blog about soon, I recently discovered that Microsoft has changed their app store license policies for Windows Mobile 8. So I believe that at least their on-paper legal policies, putting aside any limitations built into the OS, would now be compliant with copyleft.next and GPL 3.
Luis
Luis Villa wrote at 16:02 (CEST) on Thursday:
[app stores] are a form of distribution where the distributor is really minimally interested and wants to have the minimum possible involvement. And I think that's actually OK, and is distinguishable from other forms of distribution. So we do want to think about how to make that possible.
While I think that I see your point, I see this situation rather simply: they're either common carriers, or they aren't. We don't sue ISPs for copyleft infringement because they have safe harbor: at worst, they get a DMCA take-down, but they aren't and shouldn't be liable.
App-stores want editorial control, at the very least. Thus, they aren't common carriers. They don't deserve special distribution treatment. If software authors want to allow "minimally interested distribution" that isn't common carrier activity, then highly permissive license is probably what they were looking for in the first place.
We also have to take here some of Fontana's points about the idea that copyleft-next should take care not to be overly influenced by "issues of the day". Fontana has pointed to places where both GPLv2 and GPLv3 fell victim to that. I agree with him on this point, although we probably disagree which parts of GPLv2/v3 had this problem. :)
My gut says that the "app stores are really really really a special type of distribution, that's SO different from all the distribution we've ever had in the past" might be just such a case where we've let an issue of the day influence license drafting. Fontana, I'm curious if you agree.
I recently discovered that Microsoft has changed their app store license policies for Windows Mobile 8. So I believe that at least their on-paper legal policies ... would now be compliant
I'd be interested to see your findings on this. Will your blog post disclose whether or not Microsoft is your client and/or funded your work, BTW? I hope so; I don't want to have to compare you to Edward J. Naughton. :)
copyleft.next
BTW, while I keep propagating "copyleft.next" naming myself, Fontana has finally beaten it into my head it's called copyleft-next, and copyleft.next is a misspelling. :)
Hello,
On 10/12/2012 12:16 AM, Bradley M. Kuhn wrote:
copyleft.next
BTW, while I keep propagating "copyleft.next" naming myself, Fontana has finally beaten it into my head it's called copyleft-next, and copyleft.next is a misspelling. :)
I would have preferred "copyleft.next" as a name, and hereby want to voice my support for this misspelling :)
-- kuno / warp.
On 10/12/2012 02:58 AM, Kuno Woudt wrote:
Hello,
On 10/12/2012 12:16 AM, Bradley M. Kuhn wrote:
copyleft.next
BTW, while I keep propagating "copyleft.next" naming myself, Fontana has finally beaten it into my head it's called copyleft-next, and copyleft.next is a misspelling. :)
I would have preferred "copyleft.next" as a name, and hereby want to voice my support for this misspelling :)
It was originally "GPL.next" and then (bkuhn's suggestion) "copyleft.next". Luis Rodriguez proposed "copyleft-next" which seemed to me an improvement.
- Richard
On 10/11/2012 06:16 PM, Bradley M. Kuhn wrote:
My gut says that the "app stores are really really really a special type of distribution, that's SO different from all the distribution we've ever had in the past" might be just such a case where we've let an issue of the day influence license drafting. Fontana, I'm curious if you agree.
I don't think this particular issue of the day has actually influenced any FLOSS license drafting (yet).
- RF
I think Bradley and I are mostly violently agreeing; details below.
On Thu, Oct 11, 2012 at 3:16 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
My gut says that the "app stores are really really really a special type of distribution, that's SO different from all the distribution we've ever had in the past" might be just such a case where we've let an issue of the day influence license drafting. Fontana, I'm curious if you agree.
I strongly agree that issues of the day should not influence drafting, and certainly agree there should not be special exceptions for app stores.
That said, in most cases, I think no special exception for app stores is necessary. There are three big issues I've seen articulated with regards to app stores, and all are either addressed or would never be addressed by copyleft.next:
1) Most app stores do not want to distribute source code themselves. This is arguably prohibited by GPL v2, but copyleft.next (following GPL 3 and MPL2) allow source to be distributed by a party other than the party that distributed the binary; i.e., in the app store case, by the party that uploaded the binary to the app store. So I don't think that copyleft.next has a problem with app stores along this axis.
2) Most app store vendors do not want to license their patents that might cover an app. copyleft.next (following GPL 3, MPL 1.1, and Apache 2) only requires parties to license patents when they modify an app. Since no app store that I'm aware of modifies apps (and if they did, they should obviously grant patents to those modifications), this particular problem is again not an issue for copyleft.next.
3) Many (most?) app stores distribute to locked-down platforms, where user rights are restricted by means both legal and technical. This is an important issue, and at the current time an issue that often appears in the same places as app stores, but it is a different issue, and should be resolved independently. Or to put it another way: locked-down platforms can be locked down without an app store, and app stores can deliver to non-locked-down platforms. Given this, the license should take care, while solving the lockdown problem, not to accidentally draft restrictions that would prohibit someone from using an app-store-like approach to deliver code to a rights-respecting platform. Again, I think copyleft.next handles this the right way, divorcing the anti-lockdown text (Corresponding Source, part (ii)) from discussion of the delivery mechanism (elsewhere in Sec. 9).
I have not looked at this problem in detail in some time, so I may be missing some aspects, but these are the three problems that comes to mind. Certainly if there are others I'm not thinking about they should be raised- they'd be useful both specifically to use to analyze copyleft.next, as well as other licenses.
Luis
I'll note that there are a number of worked examples which allow GPL'ed code to be distibuted via an app store already. All you have to do is use a two step process. So the app-store distributed application (for example, the Android Better Terminal application) can simply download the necessary GPL'ed or LGPL'ed components from a web site, which can respect the source code distribution requirements.
There are issues around what is one program versus multiple programs/"mere aggregation" (i.e., does a Copyleft license infect across a shell script invocation, remote procedure call, or a pipe), but those are issues which exist already.
I'm not sure off-hand whether or not IOS applications are able to download executable content, but this is certainly possible on Android devices.
- Ted
On 11/26/2012 09:58 PM, Luis Villa wrote:
That said, in most cases, I think no special exception for app stores is necessary. There are three big issues I've seen articulated with regards to app stores, and all are either addressed or would never be addressed by copyleft.next:
- Most app stores do not want to distribute source code themselves.
This is arguably prohibited by GPL v2, but copyleft.next (following GPL 3 and MPL2) allow source to be distributed by a party other than the party that distributed the binary; i.e., in the app store case, by the party that uploaded the binary to the app store.
I also think this is the FSF's official interpretation of GPLv2, though a stricter interpretation is possible. Also, GPLv2 allows the source code offer with network-distributed object code.
So I don't think that copyleft.next has a problem with app stores along this axis.
Right.
- Most app store vendors do not want to license their patents that
might cover an app. copyleft.next (following GPL 3, MPL 1.1, and Apache 2) only requires parties to license patents when they modify an app. Since no app store that I'm aware of modifies apps (and if they did, they should obviously grant patents to those modifications), this particular problem is again not an issue for copyleft.next.
Right.
- Many (most?) app stores distribute to locked-down platforms, where
user rights are restricted by means both legal and technical. This is an important issue, and at the current time an issue that often appears in the same places as app stores, but it is a different issue, and should be resolved independently. Or to put it another way: locked-down platforms can be locked down without an app store, and app stores can deliver to non-locked-down platforms. Given this, the license should take care, while solving the lockdown problem, not to accidentally draft restrictions that would prohibit someone from using an app-store-like approach to deliver code to a rights-respecting platform. Again, I think copyleft.next handles this the right way, divorcing the anti-lockdown text (Corresponding Source, part (ii)) from discussion of the delivery mechanism (elsewhere in Sec. 9).
I don't think there is any anti-lockdown text as such. Maybe this needs to be clarified. Did I mistakenly merge a bkuhn patch? :-)
- RF
On Tue, Nov 27, 2012 at 6:01 PM, Richard Fontana fontana@sharpeleven.org wrote:
- Many (most?) app stores distribute to locked-down platforms, where
user rights are restricted by means both legal and technical. This is an important issue, and at the current time an issue that often appears in the same places as app stores, but it is a different issue, and should be resolved independently. Or to put it another way: locked-down platforms can be locked down without an app store, and app stores can deliver to non-locked-down platforms. Given this, the license should take care, while solving the lockdown problem, not to accidentally draft restrictions that would prohibit someone from using an app-store-like approach to deliver code to a rights-respecting platform. Again, I think copyleft.next handles this the right way, divorcing the anti-lockdown text (Corresponding Source, part (ii)) from discussion of the delivery mechanism (elsewhere in Sec. 9).
I don't think there is any anti-lockdown text as such. Maybe this needs to be clarified. Did I mistakenly merge a bkuhn patch? :-)
My understanding of the functional requirement of Sec. 9(ii) was that it required the *ability* to install, not merely a description of how it might be done:
"all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate, modify, install and run the Covered Work."
i.e., if the "skilled developer" cannot "install and run the Covered Work" (say, because of a lack of keys), then the Corresponding Source has not been supplied.
Luis
On 11/27/2012 10:46 PM, Luis Villa wrote:
On Tue, Nov 27, 2012 at 6:01 PM, Richard Fontana fontana@sharpeleven.org wrote:
I don't think there is any anti-lockdown text as such. Maybe this needs to be clarified. Did I mistakenly merge a bkuhn patch? :-)
My understanding of the functional requirement of Sec. 9(ii) was that it required the *ability* to install, not merely a description of how it might be done:
"all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate, modify, install and run the Covered Work."
i.e., if the "skilled developer" cannot "install and run the Covered Work" (say, because of a lack of keys), then the Corresponding Source has not been supplied.
Right. This may have to be fixed ... I suppose what I must have had in mind was "install and run on the received device in some hypothetical world in which the device was not locked down", or "install and run on similar but non-locked-down devices".
Although I note that GPLv3 section 1 uses "install and run", so that's the origin of this phrasing. That is, "install and run" is part of the general definition of Corresponding Source in GPLv3 even for those cases that fall outside the 'Installation Information' requirements of the second half of section 6. That could simply mean that the GPLv3 definition can be improved upon, or it could mean that there isn't a real problem in using "install and run" language for a definition of Corresponding Source that does not necessarily imply a requirement to provide anti-anti-lockdown information.
- RF
On 11/27/2012 10:46 PM, Luis Villa wrote:
My understanding of the functional requirement of Sec. 9(ii) was that it required the *ability* to install, not merely a description of how it might be done:
"all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate, modify, install and run the Covered Work."
i.e., if the "skilled developer" cannot "install and run the Covered Work" (say, because of a lack of keys), then the Corresponding Source has not been supplied.
I've now taken out "install and run" from the definition of Corresponding Source.
- RF
TL;DR: Fontana, please accept the merge request at https://gitorious.org/copyleft-next/copyleft-next/merge_requests/25 to restore the "install and run" wording until such time as community consensus is reached regarding a compromise of which users should actually get the freedom to install modified versions.
On 11/27/2012 10:46 PM, Luis Villa wrote:
My understanding of the functional requirement of Sec. 9(ii) was that it required the *ability* to install, not merely a description of how it might be done:
"all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate, modify, install and run the Covered Work."
I understand that Luis' clients, who aren't friendly to the rights of users to install modified versions of software, would want this removed. I'm sorry to see that Richard has removed it at Luis' behest without any discussion about the issue.
I've now taken out "install and run" from the definition of Corresponding Source.
The right to install and run modified versions is *the* essential freedom that copyleft must now defend, especially with embedded systems.
GPLv3 made compromises of various sorts of this regard. However, it's a mistake for copyleft-next to "start" the negotiation point as "users have no freedom to install and run modified versions".
Therefore, I've submitted a merge request to revert this change. Please accept it. If Luis and those who oppose the freedom to install and run modified versions want to propose a compromise position -- as was done by the same powers-that-be during GPLv3 -- they should propose a compromise that allows the freedom to install modified versions some but not all of the time, as GPLv3 does. Then we can consider the compromise as a community.
Let's start at protecting the rights to install and run. Luis can propose an actual patch that shows what compromise he and his clients want on this front, and then we as a community can decide if that's the right compromise.
Please accept my merge request to revert the change that was made without real discussion, and then let Luis propose a patch for a compromise.
On Mon, Dec 3, 2012 at 12:59 PM, Bradley M. Kuhn bkuhn@ebb.org wrote:
TL;DR: Fontana, please accept the merge request at https://gitorious.org/copyleft-next/copyleft-next/merge_requests/25 to restore the "install and run" wording until such time as community consensus is reached regarding a compromise of which users should actually get the freedom to install modified versions.
On 11/27/2012 10:46 PM, Luis Villa wrote:
My understanding of the functional requirement of Sec. 9(ii) was that it required the *ability* to install, not merely a description of how it might be done:
"all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate, modify, install and run the Covered Work."
I understand that Luis' clients, who aren't friendly to the rights of users to install modified versions of software, would want this removed. I'm sorry to see that Richard has removed it at Luis' behest without any discussion about the issue.
I've now taken out "install and run" from the definition of Corresponding Source.
The right to install and run modified versions is *the* essential freedom that copyleft must now defend, especially with embedded systems.
GPLv3 made compromises of various sorts of this regard. However, it's a mistake for copyleft-next to "start" the negotiation point as "users have no freedom to install and run modified versions".
Evolutions on free software licensing helps us address concrete philosophical freedoms we have become aware of that we have and therefore need new amendments on a contract to help us protect these freedoms. Because of these evolutionary changes, however, whether we like it or not business models take off with certain assumptions on certain licenses. It would be only fair then to ensure that older licensing documents can benefit from evolutions on licensing that do not affect assumed pivotal freedoms / assumptions businesses can make. The alternative is to leave old licenses with ambiguity, which is where perhaps some may believe GPLv2 was at regarding this particular clause. I personally see a benefit to evolve copyleft-next slowly to enhance copyleft where GPLv2 left off, and at very specific points in time help tack on new evolutions that do incorporate new philosophical rights we want to embrace. This would allow us to evolve software licensing as we want it but at the same time allow businesses to understand the different freedoms/contract requirement concretely.
Where and what applies to copy-left next then and at what point is a matter of mission statement. My hope was that copyleft-next could help us align the evolutions necessary for licensing in an orderly fashion that evolves slowly as the philosophical elements are ironed out in considerations for current practices and how we can help evolve those practices.
Luis
Luis Rodriguez wrote at 17:19 (EST) on Monday:
I personally see a benefit to evolve copyleft-next slowly to enhance copyleft where GPLv2 left off,
Richard Fontana wrote at 17:59 (EST) on Monday:
For the basic version of copyleft-next, I want users to have the same freedom to install and run that they have under GPLv2. .
My point is that without "install and run", we're moving backwards from GPLv2. GPLv2 requires inclusion of "scripts used to control compilation and installation of the executable" with Source Code.
If you don't have those words in there, it's the equivalent of going to a weaker copyleft -- on the issue of installation of modified versions -- than GPLv2. Does copyleft-next seek to be *weaker* than GPLv2?
I don't really want copyleft-next to be about 'negotiations' and 'compromises'.
Then why develop it publicly it all? Why not write it privately and throw it over the wall for all to use? That's, after all, how GPLv2 was developed, AFAIK. ;)
I intend to follow up with some further thoughts on why I made the 'install and run' deletion.
I suggest that you take merge request in, which will document my reasons why I think it should be there in the git log. Then, when you remove it again, you can put your reasons why you're removing it into the git log.
In between that time, we can discuss whether people actually want it removed.
On 12/04/2012 08:30 AM, Bradley M. Kuhn wrote:
Luis Rodriguez wrote at 17:19 (EST) on Monday:
I personally see a benefit to evolve copyleft-next slowly to enhance copyleft where GPLv2 left off,
Richard Fontana wrote at 17:59 (EST) on Monday:
For the basic version of copyleft-next, I want users to have the same freedom to install and run that they have under GPLv2. .
My point is that without "install and run", we're moving backwards from GPLv2. GPLv2 requires inclusion of "scripts used to control compilation and installation of the executable" with Source Code.
Ah, that's a good point. I was starting with the GPLv3 definition, which rewrote the CS (C[&]CSC) definition from scratch, essentially.
If you don't have those words in there, it's the equivalent of going to a weaker copyleft -- on the issue of installation of modified versions -- than GPLv2. Does copyleft-next seek to be *weaker* than GPLv2?
Certainly not. (Well, it is weaker in a few senses - for example, it allows 'relicensing' under GPLv3 and AGPLv3 and later FSF versions of GPL/AGPL, which GPLv2 does not. And it states that it evaporates into a noncopyleft license under proprietary relicensing circumstances.)
I don't really want copyleft-next to be about 'negotiations' and 'compromises'.
Then why develop it publicly it all? Why not write it privately and throw it over the wall for all to use? That's, after all, how GPLv2 was developed, AFAIK. ;)
Because I believe collaboration and public discussion (up to a point) will lead to something better.
I think RMS did publish at least one draft of GPLv2 to Usenet.
- RF
On 12/04/2012 08:30 AM, Bradley M. Kuhn wrote:
Luis Rodriguez wrote at 17:19 (EST) on Monday:
I personally see a benefit to evolve copyleft-next slowly to enhance copyleft where GPLv2 left off,
[...]
I suggest that you take merge request in, which will document my reasons why I think it should be there in the git log. Then, when you remove it again, you can put your reasons why you're removing it into the git log.
I have now made a significant revision to the definition of Corresponding Source:
"Corresponding Source" of a Covered Work in Object Code form means (i) the Source Code of the Covered Work; (ii) all associated interface definition files; (iii) all scripts, instructions and similar information that were used to build such Source Code; and (iv) a list clearly identifying all Separate Works that were used in building and installing the Covered Work. Corresponding Source must be machine-readable.
On 12/03/2012 03:59 PM, Bradley M. Kuhn wrote:
TL;DR: Fontana, please accept the merge request at https://gitorious.org/copyleft-next/copyleft-next/merge_requests/25 to restore the "install and run" wording until such time as community consensus is reached regarding a compromise of which users should actually get the freedom to install modified versions.
[...]
I'm sorry to see that Richard has removed it at Luis' behest without any discussion about the issue.
I didn't remove it at Luis's behest - he never suggested that it be removed (AFAICR). I'd be happy to have further discussion about the issue.
I've now taken out "install and run" from the definition of Corresponding Source.
The right to install and run modified versions is *the* essential freedom that copyleft must now defend, especially with embedded systems.
GPLv3 made compromises of various sorts of this regard. However, it's a mistake for copyleft-next to "start" the negotiation point as "users have no freedom to install and run modified versions".
For the basic version of copyleft-next, I want users to have the same freedom to install and run that they have under GPLv2. That's why I had the (now-deleted) "dl-supp" file. (Yes, I realize there isn't universal agreement on the scope of such freedom, so let us suppose that there is a majority view on what that means.)
Therefore, I've submitted a merge request to revert this change. Please accept it. If Luis and those who oppose the freedom to install and run modified versions want to propose a compromise position -- as was done by the same powers-that-be during GPLv3 -- they should propose a compromise that allows the freedom to install modified versions some but not all of the time, as GPLv3 does. Then we can consider the compromise as a community.
I don't really want copyleft-next to be about 'negotiations' and 'compromises'.
Please accept my merge request to revert the change that was made without real discussion, and then let Luis propose a patch for a compromise.
I agree that there wasn't as much discussion about this as there could have been. I intend to follow up with some further thoughts on why I made the 'install and run' deletion.
- RF
On 12/03/2012 05:59 PM, Richard Fontana wrote:
I intend to follow up with some further thoughts on why I made the 'install and run' deletion.
(Beyond the obvious: making the license text two words shorter. :-)
On 12/03/2012 05:59 PM, Richard Fontana wrote:
I agree that there wasn't as much discussion about this as there could have been. I intend to follow up with some further thoughts on why I made the 'install and run' deletion.
As a preliminary matter, here is a review of the history of the Corresponding Source definition.
GPLv1 (1989):
"For an executable file, complete source code means all the source code for all modules it contains".
GPLv2 (1991):
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
GPLv3, Discussion Draft 1 (January 2006):
"The 'Complete Corresponding Source Code' for a work in object code form means all the *source code* [EMPHASIS ADDED - RF] needed to understand, adapt, modify, compile, link, install, and run the work .... For example, this includes any scripts used to control those activities, and any shared libraries and dynamically linked subprograms that the work is designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work, and interface definition files associated with the program source files.
"Complete Corresponding Source Code *also* [EMPHASIS ADDED - RF] includes any encryption or authorization codes necessary to install and/or execute the source code of the work, perhaps modified by you, in the recommended or principal context of use, such that its functioning in all circumstances is identical to that of the work, except as altered by your modifications. It also includes any decryption codes necessary to access or unseal the work's output...."
GPLv3, Discussion Draft 2 (July 2006)
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, .... For example, Corresponding Source includes scripts used to control those activities, interface definition files associated with the program source files, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by complex data communication or control flow between those subprograms and other parts of the work.
"The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (For instance, if the work is a DVD player and can play certain DVDs, it must be possible for modified versions to play those DVDs. If the work communicates with an online service, it must be possible for modified versions to communicate with the same online service in the same way such that the service cannot distinguish.) A key need not be included in cases where use of the work normally implies the user already has the key and can read and copy it, as in privacy applications where users generate their own keys. However, the fact that a key is generated based on the object code of the work or is present in hardware that limits its use does not alter the requirement to include it in the Corresponding Source."
GPLv3 had a few more 'Discussion Drafts' but the major changes to the Corresponding Source definition were largely complete by Discussion Draft 3. That draft got rid of the controversial 'keys' part of the definition of Corresponding Source and replaced it with a new 'Installation Information' requirement which supplemented the requirement to 'convey' Corresponding Source where object code was conveyed in a defined category of 'User Products'. Here is the Corresponding Source definition in the released version of GPLv3:
"The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.... For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."
Here is the Corresponding Source definition in copyleft-next as of this moment:
"Corresponding Source" of a Covered Work in Object Code form means (i) the Source Code of the Covered Work; (ii) all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate and modify the Covered Work; (iii) all relevant interface definition files; (iv) the Source Code of shared libraries that the Covered Work is specifically designed to require, such as by intimate data communication or control flow between those libraries and parts of the Covered Work; and (v) a list clearly identifying all Separate Works that were used in building, compiling, generating and installing the Covered Work. Corresponding Source must be in machine-readable form."
On Tue, Dec 04, 2012 at 11:05:57PM -0500, Richard Fontana wrote:
(iv) the Source Code of shared libraries that the Covered Work is specifically designed to require, such as by intimate data communication or control flow between those libraries and parts of the Covered Work;
Are you going to define what is meant by "intimate data communication or control flow"? I could imagine that being considered somewhat vague.... and things which are vague that can only be settled by a lawsuit is, in my mind, unfortunate....
- Ted
On 12/04/2012 11:29 PM, Theodore Ts'o wrote:
On Tue, Dec 04, 2012 at 11:05:57PM -0500, Richard Fontana wrote:
(iv) the Source Code of shared libraries that the Covered Work is specifically designed to require, such as by intimate data communication or control flow between those libraries and parts of the Covered Work;
Are you going to define what is meant by "intimate data communication or control flow"? I could imagine that being considered somewhat vague.... and things which are vague that can only be settled by a lawsuit is, in my mind, unfortunate....
This is a bit of the GPLv3 definition I have left intact. I don't think I can improve on it (maybe someone else can), and I don't want the Corresponding Source definition to get even longer, so, assuming it's not improved on, I think it's a matter of either keeping it or deleting it. It is a kind of codification of FSF interpretation of GPLv2 (I think the term 'intimate' is used in the FSF's GNU licenses FAQ).
Notice that during the drafting of GPLv3 "intimate" was replaced with "complex" in response to people complaining that they couldn't figure out what "intimate" meant, but then people complained about "complex". I recall being the one who suggested returning to "intimate" since it seemed more suggestive of what the FSF was trying to express than "complex", and I sort of liked the eccentricity of it (indeed I still do).
Actually I'm curious to know Bradley's view on whether the 'intimate' clause is worth keeping or not. I imagine that, were it in GPLv2, it would not have much relevance for the typical GPLv2 enforcement situation.
- RF
On 12/04/2012 11:29 PM, Theodore Ts'o wrote:
On Tue, Dec 04, 2012 at 11:05:57PM -0500, Richard Fontana wrote:
(iv) the Source Code of shared libraries that the Covered Work is specifically designed to require, such as by intimate data communication or control flow between those libraries and parts of the Covered Work;
Are you going to define what is meant by "intimate data communication or control flow"? I could imagine that being considered somewhat vague.... and things which are vague that can only be settled by a lawsuit is, in my mind, unfortunate....
I've now deleted this.
- RF
On 12/05/2012 09:24 PM, Richard Fontana wrote:
On 12/04/2012 11:29 PM, Theodore Ts'o wrote:
On Tue, Dec 04, 2012 at 11:05:57PM -0500, Richard Fontana wrote:
(iv) the Source Code of shared libraries that the Covered Work is specifically designed to require, such as by intimate data communication or control flow between those libraries and parts of the Covered Work;
Are you going to define what is meant by "intimate data communication or control flow"? I could imagine that being considered somewhat vague.... and things which are vague that can only be settled by a lawsuit is, in my mind, unfortunate....
I've now deleted this.
Good-Faith Partial Harvey Birdman Rule Violation Cure:
I recently had a telephone conversation with bkuhn in which we briefly discussed some of the substantive issues raised in this thread or subthread. I had thought that bkuhn was going to cure this Harvey Birdman Rule violation, and I believe he did take some notes for that purpose, but he hasn't yet posted anything on this list or communicated otherwise. My recollection of this conversation (which took place last week) is beginning to fade.
One of the issues we discussed (though only for a minute or two) was my decision to delete this portion of the Corresponding Source definition that Ted Ts'o had highlighted. The substantive point I wish to HBR-ify is that bkuhn observed that an arguably nice aspect of the deleted clause is that it codifies traditional FSF interpretation. I believe I pointed out that while I agree that this is a nice feature, I am not sure that the language of the clause matches such interpretation as closely as it was intended to do. I pointed out to bkuhn that perhaps something like this language could instead go into the definition of 'Derived Work'.
I noted to bkuhn (though not in the following level of detail) my recollection that during the drafting of GPLv3, in one or more meetings of 'Committee B' there were some persons who proposed to FSF counsel that what they saw as insufficient clarity around the scope of GPLv2 'derivative work'/'work based on the Program' might be resolved by moving elements of the quite detailed Corresponding Source definition into a definition of either the successor label to 'derivative work' or else the definition of the basic copyleft condition in GPLv3 section 5.
The perception was that the definition of 'Corresponding Source' was a sort of misplaced attempt to define what GPLv2 means by 'derivative work'. I actually don't think that is quite correct, but it is important to know that the argument was made and I do believe it contains an important insight.
What is interesting about the GPLv3 ancestor of the deleted clause is that it appears to avoid the traditional tiresome legal debate about GPLv2, shared libraries and 'derivative works' by instead focusing on what one has to provide as a matter of source code if one distributes (conveys) a binary.
However, I am not convinced that the result of applying the deleted clause adequately captures either pre-GPLv3 FSF interpretive tradition or intuition among most strong-copyleft-supporting, GPL-using developer-licensors who have been strongly influenced by FSF interpretive tradition. I do not have time to go into this, but I will note that the suggestion made some time ago by a person on github (see thread "Allow linking with any FSF/OSI approved license" from September) may be worth thinking about here. Ignoring the details of the suggestion, I believe the suggestion may express an intuition common among GPL licensors: what matters is not pure orthodox GPL FLOSS license compatibility (under traditional FSF-ish strong copyleft interpretive doctrine, however one understands that) but rather avoidance of certain cases of GPL/proprietary code coexistence assumed to be allowed under weak copyleft licensing regimes.
- RF
On Wed, Dec 12, 2012 at 10:22:06AM -0500, Richard Fontana wrote:
What is interesting about the GPLv3 ancestor of the deleted clause is that it appears to avoid the traditional tiresome legal debate about GPLv2, shared libraries and 'derivative works' by instead focusing on what one has to provide as a matter of source code if one distributes (conveys) a binary.
I'll observe if indeed the goal was to bypass the whole question of "derivitive works", then there is the danger that it could change the general understanding of what is and isn't covered in a dramatic fashion. This is because I've heard people "steeped in the FSF interpreative tradition" claim that the GPLv2 should (at least from their moral/ethical calculus) infect across an RPC call. This interpretation had been strictly ruled out because it's clear that a program running on a completely different computer on the other side of a network connection very clearly could not be reached via copyright law due restrictions to what I judge would likely tolerate via-a-vis stretching the definition of derivitive before throwing a lawyer who tried to claim that the GPL infected across an RPC call out of the courtroom.
If we bypass the protections of the common law interpretation of what deritive works mean, then "intimate data flow" could easily be interpreted to include non-copyleft-next source code which tries to call copyleft-next code across a network connection via an RPC, and I think that would be a huge change.
- Ted
The definition of 'Complete Corresponding Source Code' in GPLv3 Discussion Draft 1 was a significant change from the GPLv2 definition. It gives an expansive list of verbs (which was later pared down in response to some criticism that it was *too* expansive) in place of the quasi-tautological formula in GPLv2. "Scripts" are mentioned and are assumed to be a form of "source code" (itself a defined term). The "keys" provision treated certain "encryption or authorization keys" as something that was not "source code" but which was a categorically different part of Complete Corresponding Source Code.
From discussions with Bradley, I have learned of the significance of
the words "scripts used to control compilation and installation of the executable" in the context of GPLv2 enforcement. I have gathered that failure to provide scripts, or the equivalent, satisfying this definition is a common problem in such enforcement.
I believe Bradley sees the Installation Information requirements of present-day GPLv3 as a descendant, of sorts, of the "scripts used to control compilation and installation of the executable" wording in GPLv2, which is interesting.
Now, here again is the beginning of the definition of Corresponding Source in present-day GPLv3:
The 'Corresponding Source' for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.
Note that scripts to control 'installation' and 'running' are one category of source code that is part of Corresponding Source. But note also that a separate section of GPLv3 details 'Installation Information' requirements which apply only to conveying of object code in 'User Products'.
I do not see how one can read the GPLv3 Corresponding Source definition such that "scripts to control" the activities of installation and running include "Installation Information". The fact that Installation Information is limited to User Products makes clear that Installation Information is information that is *additional* to Corresponding Source. Any alternate reading seems to suggest that GPLv3 has two Installation Information requirements: one which is quite detailed and applies only in the User Product context, and the other which is vaguer and which applies in all (or all other) contexts. As a matter of common sense, plain reading, and historical evidence, this cannot be a correct reading of GPLv3.
This brings us to the current copyleft-next definition. I quote the beginning of it:
"Corresponding Source" of a Covered Work in Object Code form means (i) the Source Code of the Covered Work; (ii) all scripts, instructions and information known to you necessary for a skilled developer to build, compile, generate and modify the Covered Work; [....]
Note that this is different from GPLv3 in the following sense: it does not treat "scripts, instructions and information known to you" as a form of "Source Code". Clause (i) has the quasi-tautological flavor of GPLv2 and its ancestors. Clause (ii) is the descendant of the "scripts used to control compilation and installation of the executable" language of GPLv2, as well as the descendant of the 'expansive set of verbs' approach in the basic definition of Corresponding Source in GPLv3.
Now, here's what I think happened. By keeping (i) and (ii) separate (in a way in which they are not separate in GPLv3, but sort of are in GPLv2), and by broadening (ii) to refer not merely to "scripts", I believe an interesting problem was created. My argument above that GPLv3's definition of Corresponding Source cannot possibly be read to imply a sort of stealth general Installation Information requirement is not relevant to copyleft-next, because copyleft-next has this "source code vs. other information" separation built into the definition, and also copyleft-next did away with the explicit Installation Information provisions altogether.
However, as Luis Villa pointed out, this all permits the copyleft-next definition (when it had the verbs "install and run", which Bradley wants to restore) to be read as *having* something like an Installation Information requirement in some non-specific sense, particularly because broader words than merely "scripts" are used. And this reading by Luis appears to be justified since Bradley seems to be either saying that this is how the definition *must* be read, or that this is how it reasonably *can* be read. (And Bradley had some part in drafting the current version.)
In other words, we created a situation in which "install and run" arguably meant more in copyleft-next than it possibly can in GPLv3. We don't have the Installation Information provisions and the GPLv3 limitation of 'things other than conventional source code' to "scripts" to make clear that such a broad reading of "install and run" would be preposterous.
That is why I deleted "install and run".
I may have more to say on this but I'll leave it at that for now.
- RF
Hello,
On 10/11/2012 01:13 PM, Bradley M. Kuhn wrote:
I don't agree. I think the copyleft-incompatibility of app stores is specifically designed to work against the software freedom of users, particularly in Apple's case. In Google's case, they demand a permissive license from the author for Google's own benefit, which means there's no way copyleft-next could do that unless it had a "permissive out especially for Google" clause, which I think would be a bad idea.
I wasn't suggesting copyleft.next should support this scenario, as I expect it would weaken the license, which I agree would be a bad idea.
(sidenote, I don't see google demanding a permissive license in [1], is there a different agreement I should be aware of?)
App stores are just a way to distribute software. Why should some distributions get special treatment?
Luis' points are interesting on this: a true app-store that wants to DTRT should actually have no trouble complying with copyleft-next, or AGPLv3, for that matter!
I am talking about app-stores with significant market share. To be specific, I am talking about:
- Mac App Store and iOS App Store - Windows Store and Windows Phone Store - Google Play - Ubuntu Software Center
I don't consider any of these as wanting to Do The Right Thing. Specifically Microsoft and Apple seem very hostile toward free software.
As a software developer I want people to use my software, so I cannot simply ignore the incredible marketshare of these platforms. I have to make a choice.
I think this comes down to the old question of whether it is better to promote free software by only supporting sufficiently open and free platforms, and thereby depriving large groups of users of the opportunity to learn about free software through your application. Or if it is better to support closed platforms in order to reach their users and educate them about the virtues of free software, but in doing so contribute to strengthening the position of those evil platforms in the market.
-- kuno / warp.
[1] http://www.android.com/us/developer-distribution-agreement.html
Kuno Woudt wrote at 08:56 (CE ST):
(sidenote, I don't see google demanding a permissive license in [1], is there a different agreement I should be aware of?) http://www.android.com/us/developer-distribution-agreement.html
No, the thing I'm talking about is still in there:
You grant to Google a nonexclusive, worldwide, and royalty-free license to: copy, distribute, perform, display, and use the Products in connection with the Market and the Android platform.
This prevents distribution of software through the Market that makes use of GPL'd code licensed from others. In fact, it will have this effect on code released under anything but the most permissive free software licenses. For example, it would also prevent incorporation other people's LGPLed or MPLed code.
As a software developer I want people to use my software, so I cannot simply ignore the incredible marketshare of these platforms. I have to make a choice.
Copyleft/permissive is always about that kind of choice, so I don't necessarily see this situation as any different.
I think this comes down to the old question of whether it is better to promote free software by only supporting sufficiently open and free platforms, and thereby depriving large groups of users of the opportunity to learn about free software through your application.
Again, classic trade-off related to copyleft/permissive.
Hello,
On 10/12/2012 02:20 PM, Bradley M. Kuhn wrote:
Kuno Woudt wrote at 08:56 (CE ST):
(sidenote, I don't see google demanding a permissive license in [1], is there a different agreement I should be aware of?) http://www.android.com/us/developer-distribution-agreement.html
No, the thing I'm talking about is still in there:
You grant to Google a nonexclusive, worldwide, and royalty-free license to: copy, distribute, perform, display, and use the Products in connection with the Market and the Android platform.
This prevents distribution of software through the Market that makes use of GPL'd code licensed from others. In fact, it will have this effect on code released under anything but the most permissive free software licenses. For example, it would also prevent incorporation other people's LGPLed or MPLed code.
Doesn't the GPL already grant a nonexclusive, worldwide, and royalte-free license to: copy, distribute, perform, display, and use the licensed software?
I guess the problem is that if I as a developer agree to that developer agreement I am giving Google those permissions without Google being subject to the conditions of the GPL. I didn't read it that way.
I think this comes down to the old question of whether it is better to promote free software by only supporting sufficiently open and free platforms, and thereby depriving large groups of users of the opportunity to learn about free software through your application.
Again, classic trade-off related to copyleft/permissive.
I don't see this as a trade-off between copyleft and permissive. It has previously always been possible to develop and distribute copyleft software compatible with proprietary platforms such as Windows, Mac OS X and the various proprietary unixes.
I was hoping we could figure out a way to do this in the app stores.
-- kuno / warp.
On 10/12/2012 09:30 AM, Kuno Woudt wrote:
I don't see this as a trade-off between copyleft and permissive. It has previously always been possible to develop and distribute copyleft software compatible with proprietary platforms such as Windows, Mac OS X and the various proprietary unixes.
I was hoping we could figure out a way to do this in the app stores.
I'm not convinced that copyleft-next hasn't already solved this issue.
- RF
On Wed, Sep 26, 2012 at 10:09 AM, Mike Linksvayer ml@gondwanaland.com wrote:
On Sat, Sep 22, 2012 at 3:03 PM, Luis Villa luis@tieguy.org wrote:
On Sat, Sep 22, 2012 at 2:58 PM, Richard Fontana fontana@sharpeleven.org wrote:
On 09/22/2012 03:34 PM, Luis Villa wrote:
Just curious if anyone has thought about, looked at, or drafted a permissive license based on the structure, organization, and terminology of copyleft.next.
In fact I have thought about it (but didn't go beyond the 'thought' stage), not too after I had already started the project. Once a certain level of simplification of structure was achieved I realized it wouldn't be difficult to achieve this. Whether it is worth doing is an interesting idea to ponder.
If nothing else, it would be an interesting drafting exercise and might point out structural issues.
I'd love to see it. As I've carped elsewhere, the state of the art of permissive licenses is pretty poor.
Because they suck for freedoms anyway. Who would care and most importantly *why*? I think we stand more to gain to focus on addressing FUD and stupidity over Free Software licenses rather than promoting archaic practices. In a way I think copyleft-next helps with this exact issue.
Don't get me wrong, I am not saying permissive licenses do not have their place today, quite the contrary, I've been promoting localizing the GPL [0] and using permissive licenses specifically even in the Linux kernel to help fight killing off proprietary drivers, but in the long run permissive licenses are old and decrepit. The importance of the GPL [1] is the freedoms they bring and guarantee to us as both a community and ecosystem, permissive licenses today are there simply a compromise to deal with current political and legal stupidity by part of certain OS vendors / projects and lastly archaic economic models. Sure permissive licenses can still be advanced and brought up to date, but for what purpose ?
[0] http://mcgrof.blogspot.com/2012/04/localizing-gpl.html [1] http://mcgrof.blogspot.com/2012/03/importance-of-gpl.html
Luis
On Wed, Sep 26, 2012 at 10:55 AM, Richard Fontana fontana@sharpeleven.org wrote:
On 09/26/2012 01:09 PM, Mike Linksvayer wrote:
As I've carped elsewhere, the state of the art of permissive licenses is pretty poor.
Is there any public record of such carping? I'm curious to know your views on that topic.
I don't think in any more detail than above. I probably don't have a very good case to make, but here it is:
* Exclusive (due to lack of alternative) choice between at best implied patent grant (MIT/BSD/etc) and GPLv2-incompatibility (Apache2) seems suboptimal * Apache2 is a whole bunch of text for what it does...copyleft-next-current is shorter. * There are lots of minor variations of MIT/BSD/etc; a permissive license with a canonical text would be minorly nice * "reproduce the above copyright notice, this list of conditions and the following disclaimer" (BSD) not ideal for anything but non-minified source (admittedly that's most cases, but why not more?), Apache2 more ambiguous ("attach") and in practice Apache projects just link to the license, eg for documentation, copyleft-next-current says "inform recipients how they can obtain a copy of this License", IMO best. * People in domains not far from software think Apache2 language inadequate to cover their works (I think they're mostly wrong, but I don't see any reason there shouldn't be a permissive (and a copyleft; I intend to post about this) license that may unambiguously be used for software and eg for "open hardware" designs).
OTOH I think it is kind of nice that the most widely used permissive license(s of course; BSD) are almost unchanged over approaching 3 decades, apart from removing clauses slowly understood to be harmful (advertising) or unnecessary (no endorsement); maybe any further optimization would just cause people to think about licenses more than they ought to.
Mike
copyleft-next@lists.fedorahosted.org
-
Bradley M. Kuhn -
Kuno Woudt -
Luis R. Rodriguez -
Luis Villa -
Mike Linksvayer -
Richard Fontana -
Theodore Ts'o