A GitHub person recently reported the following issue:
- begin - IMHO one of the worst problems of the GPL is that it don't allows linking (static or dynamic) programs licensed under the GPL with some of the FSF/OSI approved licenses (OpenSSL,CDDL,PHP License...)
I think it will be a good idea to add an exception to this license that allows linking the software with ANY of the licenses considered as free software license by the FSF/OSI while at the same time forbids to link the software with any proprietary license.
Perhaps something like:
In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with any software licensed under a license that satisfies either the Free Software Definition, version 1.111, as published by the Free Software Foundation ("FSF") or the Open Source Definition, as published by the Open Source Initiative, and distribute linked combinations including the two. - end -
- RF
On Sat, Sep 1, 2012 at 5:53 PM, Richard Fontana fontana@sharpeleven.org wrote:
A GitHub person recently reported the following issue:
- begin -
IMHO one of the worst problems of the GPL is that it don't allows linking (static or dynamic) programs licensed under the GPL with some of the FSF/OSI approved licenses (OpenSSL,CDDL,PHP License...)
I think it will be a good idea to add an exception to this license that allows linking the software with ANY of the licenses considered as free software license by the FSF/OSI while at the same time forbids to link the software with any proprietary license.
Perhaps something like:
In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with any software licensed under a license that satisfies either the Free Software Definition, version 1.111, as published by the Free Software Foundation ("FSF") or the Open Source Definition, as published by the Open Source Initiative, and distribute linked combinations including the two.
Without reviewing the text deeply, the concept gets a strong +1 from me.
Luis
On Sat, Sep 01, 2012 at 08:53:16PM -0400, Richard Fontana wrote:
I think it will be a good idea to add an exception to this license that allows linking the software with ANY of the licenses considered as free software license by the FSF/OSI while at the same time forbids to link the software with any proprietary license.
I assume there will be some explanatory text making sure that it's understand that the permission has to come from both directions? (i.e., it might not be OK to statically link against code with a more restrictive license, even if it meets the criteria above).
Also, if you're going to forbid "link the software with any proprietary license", it would be nice to include an explicit definition of whether link encompasses a shared library link where the proprietary object is not distributed alongside the copyleft-licensed software, or an RPC call across the network, or when a propietary program sends data down a pipe to a copyleft-licensed program....
- Ted
On 09/01/2012 09:40 PM, Theodore Ts'o wrote:
On Sat, Sep 01, 2012 at 08:53:16PM -0400, Richard Fontana wrote:
I think it will be a good idea to add an exception to this license that allows linking the software with ANY of the licenses considered as free software license by the FSF/OSI while at the same time forbids to link the software with any proprietary license.
I assume there will be some explanatory text making sure that it's understand that the permission has to come from both directions? (i.e., it might not be OK to statically link against code with a more restrictive license, even if it meets the criteria above).
Also, if you're going to forbid "link the software with any proprietary license", it would be nice to include an explicit definition of whether link encompasses a shared library link where the proprietary object is not distributed alongside the copyleft-licensed software, or an RPC call across the network, or when a propietary program sends data down a pipe to a copyleft-licensed program....
- Ted
What about the divergence between the FSF and OSI at this point in what are termed free licenses? If memory serves, there are different lists of licenses at these locations:
http://www.gnu.org/licenses/license-list.html http://opensource.org/licenses/alphabetical
OSI merely lists licenses while the FSF page gives guidance as to compatibility and also recommending that certain licenses OSI lists not be used in any project. If we use FSF/OSI as a term, we would perhaps need to establish a list of licenses that are common to both lists for general purpose. I would prefer that we instead refer to just one so that varying definitions of free need not be resolved.
Stephen Michael Kellat
Or just use "or", as the proposed language does. On Sep 2, 2012 11:27 AM, "Stephen Michael Kellat" skellat@fastmail.net wrote:
On 09/01/2012 09:40 PM, Theodore Ts'o wrote:
On Sat, Sep 01, 2012 at 08:53:16PM -0400, Richard Fontana wrote:
I think it will be a good idea to add an exception to this license that allows linking the software with ANY of the licenses considered as free software license by the FSF/OSI while at the same time forbids to link the software with any proprietary license.
I assume there will be some explanatory text making sure that it's understand that the permission has to come from both directions? (i.e., it might not be OK to statically link against code with a more restrictive license, even if it meets the criteria above).
Also, if you're going to forbid "link the software with any proprietary license", it would be nice to include an explicit definition of whether link encompasses a shared library link where the proprietary object is not distributed alongside the copyleft-licensed software, or an RPC call across the network, or when a propietary program sends data down a pipe to a copyleft-licensed program....
- Ted
What about the divergence between the FSF and OSI at this point in what are termed free licenses? If memory serves, there are different lists of licenses at these locations:
http://www.gnu.org/licenses/license-list.html http://opensource.org/licenses/alphabetical
OSI merely lists licenses while the FSF page gives guidance as to compatibility and also recommending that certain licenses OSI lists not be used in any project. If we use FSF/OSI as a term, we would perhaps need to establish a list of licenses that are common to both lists for general purpose. I would prefer that we instead refer to just one so that varying definitions of free need not be resolved.
Stephen Michael Kellat
copyleft-next mailing list copyleft-next@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copyleft-next
I think this is a good idea. The question I have is are we discussing approved licenses or licenses that meet the FSF and/or OSI's definition. The thread subject and Richard's initial email suggest the former, but the suggested text would indicate the latter. As a philosophical matter, I'd prefer to allow any licenses that meet the relevant definition, even if said license has not been explicitly blessed. From a practical standpoint, this gets very messy since it leaves the ability to link code up to interpretation of both the license and the OSI or FSF definition.
On 09/01/2012 08:53 PM, Richard Fontana wrote:
A GitHub person recently reported the following issue:
- begin -
IMHO one of the worst problems of the GPL is that it don't allows linking (static or dynamic) programs licensed under the GPL with some of the FSF/OSI approved licenses (OpenSSL,CDDL,PHP License...)
I think it will be a good idea to add an exception to this license that allows linking the software with ANY of the licenses considered as free software license by the FSF/OSI while at the same time forbids to link the software with any proprietary license.
Perhaps something like:
In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with any software licensed under a license that satisfies either the Free Software Definition, version 1.111, as published by the Free Software Foundation ("FSF") or the Open Source Definition, as published by the Open Source Initiative, and distribute linked combinations including the two.
- end -
I'm not convinced this is a good idea overall (though I understand the general appeal). It's not the first such suggestion; I remember that someone outside of the FSF who had access to an early draft of GPLv3 suggested something similar. It is reminiscent of things like the MySQL "FLOSS License Exception".
As to the details, I would limit it to the FSF's Free Software Definition.
This proposal might make the most sense for licenses that are generally considered non-copyleft but GPL-incompatible (the proposed language seems modeled on things like the [I believe FSF-recommended] OpenSSL GPL linking exception). For copyleft licenses, it raises the same problem on a more general level that we dealt with when thinking about a clause that would achieve EPL compatibility.
- RF
copyleft-next@lists.fedorahosted.org