So, by popular demand on a recent thread, I'll present here my thoughts about the needs for a creation of a new license (I like to call it DGPL, but other proposals are welcome).
_______________________________
Motivations -------------
The main license we all know from the FSF is the GPL. It's good because it's open source and "contaminates" the target software in order to conserve the freedom on derivative works. However, some other licenses very similar to this one have been created because other needs came out:
* LGPL: less restrictive wrt the 0-freedom. Some developers or companies don't mind if their libraries are used by non-free software. This is another way of promoting free software code, by promoting the usage and adoption, rather than avoiding the creation of propietary software.
* AGPL: more restrictive wrt the 0-freedom. The web is a special scenario in which it was seen that proprietary vendors could take advantage of GPL software without distributing the software (but still having user base) and thus to circumvent the "contamination" requisites of the main license.
So, similarly to the AGPL case, there's another special scenario in which proprietary ISVs can take advantage of GPL/AGPL software without being forced to open their software. It's another case of the need of having a more restrictive clause to the 0-freedom in order to avoid the expansion of non-free software: the non-linkable developer tools (by non-linkable I mean programs, as opposed libraries) such as IDEs, VCS, Installer Tools, Code Analyzers, etc.
Downsides ----------
There are a lot of diverse antagonistic opinions to this idea:
a) People that think that the 0-freedom should not be restricted more beyond the AGPL terms even though the main target is avoid the creation of propietary software.
b) People that think that the developer tools are fine using the GPL, because it promotes usage and adoption of free-software.
The people on the group (b) is normally the people that would also think it's better to use LGPL for a library instead of GPL, and they're free to think this way. But not everyone thinks in the same way, and we need a more restrictive license for the people that don't prefer this kind of promotion.
Method -------
The mechanism to protect the developer tools here would be to add an additional clause that states that, if the DGPL software is used for aiding/helping/supporting the development of other software, and this resulting software is distributed in any form, it should be DGPL as well. (The 'D' stands for "Developer".)
Taking the GPL text as the base, I've done some slight modifications and additions on it that I think could help achieve the restrictions for this scenario. If the motivations exposed here finally are considered as valid to move forward, I'll publish this "diff" so we can start the next discussion.
Benefits ---------
If approved, we could see two effects:
1. Proprietary developer tools turn DGPL. I know some feasible cases in which this could happen, because the company seeks community building and wide adoption. Most companies like these, normally offer free-licenses to open source developers, but they have to still remain closed source. If they turned into DGPL, their software products could be started to be integrated into the free-software ecosystem, avoiding the reluctance of open source developers to them.
2. Developer tools, which are already GPL, switching to DGPL. Proprietary software companies that were using these tools would have to consider seriously to open their developments as they find they need to keep using the latest versions of their development tools, or either stick to licensing options which the open source developers of the tools could benefit from. It's not likely that this move would cause the companies switch to the usage of proprietary software because it would imply also a cost and a migration.
___________________
That's basically the idea. Of course I welcome any discussion, additions (new bullets on every section?), opinions...
Thanks for reading and thanks in advance for any feedback.
On Sun, Mar 08, 2009 at 05:29:31PM -0400, "Andrés G. Aragoneses" wrote:
The mechanism to protect the developer tools here would be to add an additional clause that states that, if the DGPL software is used for aiding/helping/supporting the development of other software, and this resulting software is distributed in any form, it should be DGPL as well. (The 'D' stands for "Developer".)
My uneducated opinion is that you'll never get this accepted by the FSF or OSI.
You're essentially restricting field of use, which is freedom zero.
You've lost my interest at this point, but that's just me.
- Proprietary developer tools turn DGPL. I know some feasible cases in
which this could happen, because the company seeks community building and wide adoption. Most companies like these, normally offer free-licenses to open source developers, but they have to still remain closed source. If they turned into DGPL, their software products could be started to be integrated into the free-software ecosystem, avoiding the reluctance of open source developers to them.
I would stop using such tools.
I do a significant amount of work for the ASF, and we use the APL.
My work for Debian uses the GNU All Permissive.
Some of my personal stuff is CC-BY, or CC-BY-SA, depending on my mood.
My work for GNU is GPL 3.
Forcing me to choose once license each time rules it out of my toolbox.
Best,
Andrés G. Aragoneses wrote:
- LGPL: less restrictive wrt the 0-freedom.
The LGPL is just the GPL with additional permissions, but the GPL already gives unconditional permission to run. I'm not sure how you can get "less restrictive" than that.
- AGPL: more restrictive wrt the 0-freedom.
That's not really true either; it's slightly more restrictive with respect to modification, not use.
So, similarly to the AGPL case, there's another special scenario in which proprietary ISVs can take advantage of GPL/AGPL software without being forced to open their software.
I'm not sure everyone sees the GPL as a coercive tool, although many will agree it has that effect. There is a big difference between opting into the decision to share your software with others so you can receive the same in kind, and being forced to share because "that's what's right".
I'm also not sure to what extent people would actually want this. To be obviously in demand, there would need to be a reasonable set of people for whom the GPL was "too loose". Most development tools I'm aware of are actually licensed more "loosely" than the GPL, so why they would move to DGPL when they're not interested in the GPL is debatable.
I think in any situation where you move the discussion from "how I want share my software" to "how I want to force other people to share theirs" it becomes pretty indefensible morally, no matter how bad you think proprietary software is.
Cheers,
Alex.
On Sun, 2009-03-08 at 17:29 -0400, "Andrés G. Aragoneses" wrote:
So, by popular demand on a recent thread, I'll present here my thoughts about the needs for a creation of a new license (I like to call it DGPL, but other proposals are welcome).
Motivations
The main license we all know from the FSF is the GPL. It's good because it's open source and "contaminates" the target software in order to conserve the freedom on derivative works. However, some other licenses very similar to this one have been created because other needs came out:
- LGPL: less restrictive wrt the 0-freedom. Some developers or companies
don't mind if their libraries are used by non-free software. This is another way of promoting free software code, by promoting the usage and adoption, rather than avoiding the creation of propietary software.
- AGPL: more restrictive wrt the 0-freedom. The web is a special
scenario in which it was seen that proprietary vendors could take advantage of GPL software without distributing the software (but still having user base) and thus to circumvent the "contamination" requisites of the main license.
So, similarly to the AGPL case, there's another special scenario in which proprietary ISVs can take advantage of GPL/AGPL software without being forced to open their software. It's another case of the need of having a more restrictive clause to the 0-freedom in order to avoid the expansion of non-free software: the non-linkable developer tools (by non-linkable I mean programs, as opposed libraries) such as IDEs, VCS, Installer Tools, Code Analyzers, etc.
Downsides
There are a lot of diverse antagonistic opinions to this idea:
a) People that think that the 0-freedom should not be restricted more beyond the AGPL terms even though the main target is avoid the creation of propietary software.
b) People that think that the developer tools are fine using the GPL, because it promotes usage and adoption of free-software.
The people on the group (b) is normally the people that would also think it's better to use LGPL for a library instead of GPL, and they're free to think this way. But not everyone thinks in the same way, and we need a more restrictive license for the people that don't prefer this kind of promotion.
Method
The mechanism to protect the developer tools here would be to add an additional clause that states that, if the DGPL software is used for aiding/helping/supporting the development of other software, and this resulting software is distributed in any form, it should be DGPL as well. (The 'D' stands for "Developer".)
Taking the GPL text as the base, I've done some slight modifications and additions on it that I think could help achieve the restrictions for this scenario. If the motivations exposed here finally are considered as valid to move forward, I'll publish this "diff" so we can start the next discussion.
Benefits
If approved, we could see two effects:
- Proprietary developer tools turn DGPL. I know some feasible cases in
which this could happen, because the company seeks community building and wide adoption. Most companies like these, normally offer free-licenses to open source developers, but they have to still remain closed source. If they turned into DGPL, their software products could be started to be integrated into the free-software ecosystem, avoiding the reluctance of open source developers to them.
- Developer tools, which are already GPL, switching to DGPL.
Proprietary software companies that were using these tools would have to consider seriously to open their developments as they find they need to keep using the latest versions of their development tools, or either stick to licensing options which the open source developers of the tools could benefit from. It's not likely that this move would cause the companies switch to the usage of proprietary software because it would imply also a cost and a migration.
That's basically the idea. Of course I welcome any discussion, additions (new bullets on every section?), opinions...
Thanks for reading and thanks in advance for any feedback.
I think you forgot one point in your analysis, the downsides of the DGPL.
The license you propose is not free software, as it restrict freedom 0, this pretty much makes it something both FSF and OSI will reject without even going into the details.
Besides, nobody could (and I am not saying, 'would' on purpose) use it, it is incompatible with the GPL2/3 (of course), and that means nobody in the free software field would switch to the DGPL as that would mean all people that use the GPL for their project would have to stop using the tools that are made DGPL.
What you are proposing, if you go down to the root, is that all software should become DGPL. This is not going to happen anytime soon. (Or you are proposing a niche community that cannot share code with anybody else, which would probably be just stupid).
You are actually proposing a real "viral" license. One that would taint anything it touches, and turn it into a non-free license. It is also something extremely difficult to enforce, so it is also impractical.
Good luck trying to restrict freedom 0 and still call it a Free Software license or even Open Source (as defined by OSI).
Simo.
"Andrés G. Aragoneses" aaragoneses@novell.com writes:
Motivations
The main license we all know from the FSF is the GPL. It's good because it's open source
It's even better because it's a free software license :-)
and "contaminates" the target software in order to conserve the freedom on derivative works. However, some other licenses very similar to this one have been created because other needs came out:
- LGPL: less restrictive wrt the 0-freedom.
When talking about free software, freedom zero is the freedom to run the work for any purpose, any way you like. What difference is there between the GPL and LGPL with regard to this freedom? Or, indeed, any of the four freedoms?
I think perhaps you means the Lesser GPL grants permissions *additional to* the four freedoms: namely, the permission to derive a non-free work from the LGPL work in the limited case where the non-free work has a run-time link to the unchanged LGPL work.
Some developers or companies don't mind if their libraries are used by non-free software.
The word “use” is very ambiguous when one is talking about program code. Often it simply means “execute”. Here, I think you mean “derive from in a run-time link relationship”.
This is another way of promoting free software code, by promoting the usage and adoption, rather than avoiding the creation of propietary software.
The FSF doesn't see it that way: popularity promotes the code, but that's of no value if it doesn't promote the freedom.
Rather, the FSF made the Lesser GPL as a tactical move, to allow free software to be used in some common situations where the GPL would only cause the work to be rejected in favour of an existing non-free work.
- AGPL: more restrictive wrt the 0-freedom.
Here I think there is a case to be made. I'm not yet decided either way, but I don't think this thread is the place to discuss whether or not the AGPL restricts the four freedoms, so I won't.
So, similarly to the AGPL case, there's another special scenario in which proprietary ISVs can take advantage of GPL/AGPL software without being forced to open their software.
Note that the cause of free software is *directly opposed* to the operation of non-free software vendors. They have the same freedoms in free software as anyone else, of course. But saying that such vendors can take advantage of free software isn't going to be of special interest for the purpose of promoting free software.
That doesn't mean it's of no interest for *other* reasons, of course. But you explicitly wanted to have a license that is “blessed by the FSF”, and I'm pointing out that the above benefit you state is null as far as the cause of free software is concerned.
It's another case of the need of having a more restrictive clause to the 0-freedom in order to avoid the expansion of non-free software: the non-linkable developer tools (by non-linkable I mean programs, as opposed libraries) such as IDEs, VCS, Installer Tools, Code Analyzers, etc.
You assert this as a need, but I don't see any support for the assertion. Why is this a need *for free software*?
b) People that think that the developer tools are fine using the GPL, because it promotes usage and adoption of free-software.
Rather, I think it's not the place of a copyright license to try to restrict the product of using the tool. It would require an over-reach of copyright that I think is quite inappropriate.
The people on the group (b) is normally the people that would also think it's better to use LGPL for a library instead of GPL
I think people should have the four freedoms in every work, but I don't think it's better to use the LGPL for a library instead of GPL. So you may need to re-assess your model of people's positions.
But not everyone thinks in the same way, and we need a more restrictive license for the people that don't prefer this kind of promotion.
I'm still seeing no support for the assertion of need for this extra restriction on freedom zero.
Method
The mechanism to protect the developer tools here would be to add an additional clause that states that, if the DGPL software is used for aiding/helping/supporting the development of other software, and this resulting software is distributed in any form, it should be DGPL as well. (The 'D' stands for "Developer".)
I think this clause would be well outside the bounds of copyright law; or, if it's not, it should be.
Copyright is *not* a tool appropriate for exercising arbitrary control over recipients of a work; it is a tool for protecting *rights* of the copyright holder. The further you get from reasonable rights of an individual into affecting the lives of others, the further it goes from a right of freedom toward a grant of power over other people.
Your proposed clause, as far as I can determine, is clearly an exercise of power over others, and not a right that anyone should have.
Benefits
If approved, we could see two effects:
Proprietary developer tools turn DGPL. […]
Developer tools, which are already GPL, switching to DGPL. […]
You don't give any support for why this would be in any way a good idea, so I'm not seeing the benefit.
By framing two outcomes as “benefits”, you omit other possible outcomes. Significantly, you omit the “the new license is not adopted for any significant amount of works” outcome.
I don't see how what you're proposing advances the cause of free software. I certainly wouldn't consider works licensed as you describe to be free software, so wouldn't be interested in using them.
2009/3/9 Ben Finney bignose+hates-spam@benfinney.id.au:
I think this clause would be well outside the bounds of copyright law; or, if it's not, it should be. Copyright is *not* a tool appropriate for exercising arbitrary control over recipients of a work; it is a tool for protecting *rights* of the copyright holder. The further you get from reasonable rights of an individual into affecting the lives of others, the further it goes from a right of freedom toward a grant of power over other people. Your proposed clause, as far as I can determine, is clearly an exercise of power over others, and not a right that anyone should have.
In this sense, it works like an EULA, with the same ethical problems.
- d.
Am Montag, 9. März 2009 05:45:18 schrieb Ben Finney:
I think perhaps you means the Lesser GPL grants permissions *additional to* the four freedoms: namely, the permission to derive a non-free work from the LGPL work in the limited case where the non-free work has a run-time link to the unchanged LGPL work.
I came to think of GNU LGPL as "less freedom protecting" license or with "weak freedom protection" as opposed to "strong freedom protection" in the GNU GPL or "no protection" in the X11-style licenses.
Less freedom protection in the license can lead to more Free Software and more freedom in total. So it can be the right idea to use in a number of situations.
Ben Finney wrote:
b) People that think that the developer tools are fine using the GPL, because it promotes usage and adoption of free-software.
Rather, I think it's not the place of a copyright license to try to restrict the product of using the tool. It would require an over-reach of copyright that I think is quite inappropriate.
I'm not sure that is the case in general: probably in some limited aspect it may be true for specific development environments, but there are few that many people would want to use where some aspect of the development tools are not built into the final product.
As a common example, you have the GCC runtime exception, but I can think of a number of development environments for which it would be true - either with source code being directly included with software (as in GNU Bison) or significant support library requirement (Delphi, Java, .net, etc.). I would have suspicion that for scripting languages in general a very strong argument could be made; even if it were a highly pipe-reliant shell script (if it were suitably non-trivial, anyway).
So I don't think it's an over-reach of copyright particularly.
Cheers,
Alex.
Thank you for your thoughts.
Am Sonntag, den 08.03.2009, 17:29 -0400 schrieb "Andrés G. Aragoneses":
So, similarly to the AGPL case, there's another special scenario in which proprietary ISVs can take advantage of GPL/AGPL software without being forced to open their software. It's another case of the need of having a more restrictive clause to the 0-freedom in order to avoid the expansion of non-free software: the non-linkable developer tools (by non-linkable I mean programs, as opposed libraries) such as IDEs, VCS, Installer Tools, Code Analyzers, etc.
My understanding of the GPL, which I believe to be shared by a large portion of the free software community, is that the license a tool to insure the /users/ freedoms by setting a frame of /minimal/ restrictions needed to insure the legal and technical feasibility to foster Free Software.
It was never the intent to /coerce/ anyone to using or writing free software. All it states is that /if/ you want to use our software, these are the /minimal/ fundamental rules.
Unfortunately the GPL has often been portrayed as tool for coercion, sometimes from within the "Open Source" community. And I have the (hopefully false) impression that this proposal roots in the idea of extending this alleged /coercion/ to developer tools.
I hope that from this perspective it becomes clear why this proposal does not display merit to many Free Software proponents.
Cheers, David Ayers
Hi Andrés,
thanks for sharing your thoughts. This list is indeed global, though operated by FSFE (which is one of the few independent major FSFs in the world, the others are FSF, FSFI and FSFLA).
Some others have already pointed out some problems with the terminology and the legal side of adding more requirements towards a GNU AGPL license. I agree with them and I am also not convinced by the idea so far.
Am Sonntag, 8. März 2009 22:29:31 schrieb Andrés G. Aragoneses:
The mechanism to protect the developer tools here would be to add an additional clause that states that, if the DGPL software is used for aiding/helping/supporting the development of other software, and this resulting software is distributed in any form, it should be DGPL as well. (The 'D' stands for "Developer".)
Several GNU licenses already have a clause which affects part of the development tools, e.g. GNU GPLv3:
http://www.gnu.org/licenses/gpl-3.0-standalone.html Section 1: 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. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. [..]
6. Conveying Non-Source Forms: You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: [..]
Arguably this does not cover all development tools used in the process, and your idea is to get a grip an those as well. My point is that some are already covered which reduces the need for your idea.
Note also that using a proprietary development tool hurts the developer itself by restricting certain levels of open development. So there are already quite a few practical incentives to use open development tools even without this being forced in a license.
Best, Bernhard