DGPL

[simo]

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:
> 
> 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.


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.