DGPL

"Andrés G. Aragoneses" aaragoneses at novell.com
Sun Mar 8 21:29:31 UTC 2009


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.


-- 

Andrés G. Aragoneses
Software Engineer
aaragoneses at novell.com

Novell, Inc.
http://www.novell.com/
Software for the open enterprise




More information about the Discussion mailing list