kamailio tls module and GPL openssl linking exception
Hello, I'm the maintainer of the Kamailio package and I would like to push the inclusion of the openssl linking exception to upstream but I'm not sure about what parts of the upstream program should be changed in order to satisfy the GPL. Kamailio is a project with more that 10 years of existence and it's almost impossible to contact every single author of every single part of the program, but AFAIK it's quite possible to be able to add the exception to the core of the program. Kamailio runs with a core process that loads the user's configured plugins. The tls module is the only module that needs openssl to run. This module provides the ability to use a TLS transport and the core process is the one that creates and maintains the different transports. For sure that any plugin can use the provided transports, but all of them are using the core functions/structures to connect. They never connect directly to the tls module by themselves. Modules are being packaged by groups and the tls module will have it's own package. The kamailio program can be used without the tls module. Upstream is willing to add the openssl exception to core files but we want to be sure that this is enough to satisfy the GPL. Thanks in advance, Victor Seva http://people.gnome.org/~markmc/openssl-and-the-gpl.html http://lists.debian.org/debian-legal/2004/05/msg00595.html http://lists.debian.org/debian-legal/2004/07/msg00754.html http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caagy_vmcjypvrplr0yntbumo3bjgwl-g3sx4ztqo-w_3oc1...@mail.gmail.com
Re: dxsamples: New upstream version 4.4.0 available
Hi Debian Legal The previous maintainer of dxsamples felt that the license of some of the examples added in more recent versions made it unsuitable for distribution in Debian. Below is the license of one of the new files, util/biorad-pic. I would appreciate your opinion on this matter please. The full source (7.8MB) can be downloaded after filling in a registration form from opendx.org [1], or from one of the other distributions that package OpenDX samples, e.g. Fedora [2], FreeBSD, or Gentoo. The file should have the md5 sum e8f43722ca0a66282608bded7c0e4f93. Regards Graham [1] http://www.opendx.org/dlSource.html [2] http://pkgs.fedoraproject.org/repo/pkgs/dx-samples/dxsamples-4.4.0.tar.gz/ /* * (C) Visualization and Imagery Solutions, Inc. 2002 * * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose and without fee is hereby granted, * provided that the above copyright notice appear in all copies and that * both that copyright notice and this permission notice appear in * supporting documentation, and that the name of VIS not be * used in advertising or publicity pertaining to distribution of the * software without specific prior written permission. * * THE SOFTWARE IS PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND, * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. * * VIS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING * ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE. IN NO EVENT SHALL VIS BE LIABLE FOR ANY SPECIAL, INDIRECT * OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE * OR PERFORMANCE OF THIS SOFTWARE. */ -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52820655.8050...@nerve.org.za
Re: dxsamples: New upstream version 4.4.0 available
On 12/11/13 10:43, Graham Inggs wrote: The previous maintainer of dxsamples felt that the license of some of the examples added in more recent versions made it unsuitable for distribution in Debian. I don't see a license problem with what you quoted. It would be nice if the copyright holder had used a more common form of the MIT-style license (the Expat license is the closest thing there is to a canonical MIT/X11 license, and is the one in the OSI license list), but it appears to be DFSG-compliant and GPL-compatible. The maintainer will have to copy this license into debian/copyright in order to satisfy both Debian policy and the ... in supporting documentation ... clause. * (C) Visualization and Imagery Solutions, Inc. 2002 * * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose and without fee is hereby granted, * provided that the above copyright notice appear in all copies and that * both that copyright notice and this permission notice appear in * supporting documentation, and that the name of VIS not be * used in advertising or publicity pertaining to distribution of the * software without specific prior written permission. This is the first paragraph of what https://fedoraproject.org/wiki/Licensing:MIT calls Old Style with legal disclaimer, with s/M.I.T./VIS/ and the last sentence (mini-warranty-disclaimer) removed. Seems fine to me. * THE SOFTWARE IS PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND, * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This disclaimer of warranty looks fine to me, and is similar to the one recommended for use with the GPL. * VIS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING * ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE. IN NO EVENT SHALL VIS BE LIABLE FOR ANY SPECIAL, INDIRECT * OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE * OR PERFORMANCE OF THIS SOFTWARE. This is back to what https://fedoraproject.org/wiki/Licensing:MIT calls Old Style with legal disclaimer. Also looks fine to me. S -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5282109c.2090...@debian.org
Re: dxsamples: New upstream version 4.4.0 available
Thanks for clearing that up. I will include the license in debian/copyright before uploading the new version. Quoting response from Simon McVittie s...@debian.org [1] below for the bug report. [1] http://lists.debian.org/debian-legal/2013/11/msg00024.html On 12/11/13 10:43, Graham Inggs wrote: The previous maintainer of dxsamples felt that the license of some of the examples added in more recent versions made it unsuitable for distribution in Debian. I don't see a license problem with what you quoted. It would be nice if the copyright holder had used a more common form of the MIT-style license (the Expat license is the closest thing there is to a canonical MIT/X11 license, and is the one in the OSI license list), but it appears to be DFSG-compliant and GPL-compatible. The maintainer will have to copy this license into debian/copyright in order to satisfy both Debian policy and the ... in supporting documentation ... clause. * (C) Visualization and Imagery Solutions, Inc. 2002 * * Permission to use, copy, modify, and distribute this software and its * documentation for any purpose and without fee is hereby granted, * provided that the above copyright notice appear in all copies and that * both that copyright notice and this permission notice appear in * supporting documentation, and that the name of VIS not be * used in advertising or publicity pertaining to distribution of the * software without specific prior written permission. This is the first paragraph of what https://fedoraproject.org/wiki/Licensing:MIT calls Old Style with legal disclaimer, with s/M.I.T./VIS/ and the last sentence (mini-warranty-disclaimer) removed. Seems fine to me. * THE SOFTWARE IS PROVIDED AS-IS AND WITHOUT WARRANTY OF ANY KIND, * EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY * WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This disclaimer of warranty looks fine to me, and is similar to the one recommended for use with the GPL. * VIS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING * ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE. IN NO EVENT SHALL VIS BE LIABLE FOR ANY SPECIAL, INDIRECT * OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE * OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE * OR PERFORMANCE OF THIS SOFTWARE. This is back to what https://fedoraproject.org/wiki/Licensing:MIT calls Old Style with legal disclaimer. Also looks fine to me. S -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/528217cc@nerve.org.za
Re: kamailio tls module and GPL openssl linking exception
Hi Victor, On Tue, Nov 12, 2013 at 11:22:08AM +0100, Victor Seva wrote: I'm the maintainer of the Kamailio package and I would like to push the inclusion of the openssl linking exception to upstream but I'm not sure about what parts of the upstream program should be changed in order to satisfy the GPL. Kamailio is a project with more that 10 years of existence and it's almost impossible to contact every single author of every single part of the program, but AFAIK it's quite possible to be able to add the exception to the core of the program. Kamailio runs with a core process that loads the user's configured plugins. The tls module is the only module that needs openssl to run. This module provides the ability to use a TLS transport and the core process is the one that creates and maintains the different transports. For sure that any plugin can use the provided transports, but all of them are using the core functions/structures to connect. They never connect directly to the tls module by themselves. Modules are being packaged by groups and the tls module will have it's own package. The kamailio program can be used without the tls module. Upstream is willing to add the openssl exception to core files but we want to be sure that this is enough to satisfy the GPL. The only bits of the code that you need an OpenSSL exception on are the bits that are linked to OpenSSL out of the box. However, the meaning of linked isn't the most obvious one. If you're only providing the tls module as an optional, never-installed-by-default plugin, then it's just a plugin and only the plugin code needs to have an OpenSSL exception attached to it. If, however, you are enabling the tls plugin *by default* - for instance, by providing a metapackage that pulls the two separate packages in together, or by having a Recommends: that automatically pulls the tls module in and automatically activates it - then effectively, you as the maintainers are creating the combined work which links against OpenSSL. You can then no longer rely on it being a plugin to keep it at arm's length, and you would need an OpenSSL exception on /all/ of the code. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: kamailio tls module and GPL openssl linking exception
Hi Steve, Thanks for your quick reply. 2013/11/12 Steve Langasek vor...@debian.org: If, however, you are enabling the tls plugin *by default* - for instance, by providing a metapackage that pulls the two separate packages in together, or by having a Recommends: that automatically pulls the tls module in and automatically activates it Ok. But in this case installing the module *by default* via Recommends will *not* get the module active nor loaded. The user has to change the default configuration file and explicitly activate the tls module in order to get the tls loaded. Is is then ok to have the tls module in Recommneds? Thanks in advance, Victor Seva -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAgy_VkBweQZy7qfmr8f4PU7=ES7=YxtWi=xbvxbqyzvyrd...@mail.gmail.com
Re: [sr-dev] kamailio tls module and GPL openssl linking exception
Hello, The tls module is not the only module that needs OpenSSL to run. The following modules also need OpenSSL: - auth_ephemeral - auth_identity - osp - outbound - websocket I am happy for the exception to be added to the modules I authored and maintain (that's, auth_ephemeral, outbound, and websocket). That leaves auth_identity and osp (and of course, tls itself). Regards, Peter On 12 November 2013 10:22, Victor Seva linuxman...@torreviejawireless.orgwrote: Hello, I'm the maintainer of the Kamailio package and I would like to push the inclusion of the openssl linking exception to upstream but I'm not sure about what parts of the upstream program should be changed in order to satisfy the GPL. Kamailio is a project with more that 10 years of existence and it's almost impossible to contact every single author of every single part of the program, but AFAIK it's quite possible to be able to add the exception to the core of the program. Kamailio runs with a core process that loads the user's configured plugins. The tls module is the only module that needs openssl to run. This module provides the ability to use a TLS transport and the core process is the one that creates and maintains the different transports. For sure that any plugin can use the provided transports, but all of them are using the core functions/structures to connect. They never connect directly to the tls module by themselves. Modules are being packaged by groups and the tls module will have it's own package. The kamailio program can be used without the tls module. Upstream is willing to add the openssl exception to core files but we want to be sure that this is enough to satisfy the GPL. Thanks in advance, Victor Seva http://people.gnome.org/~markmc/openssl-and-the-gpl.html http://lists.debian.org/debian-legal/2004/05/msg00595.html http://lists.debian.org/debian-legal/2004/07/msg00754.html http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins ___ sr-dev mailing list sr-...@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Peter Dunkley Technical Director Crocodile RCS Ltd
Re: kamailio tls module and GPL openssl linking exception
On Tue, Nov 12, 2013 at 10:10:58PM +0100, Victor Seva wrote: Hi Steve, Thanks for your quick reply. 2013/11/12 Steve Langasek vor...@debian.org: If, however, you are enabling the tls plugin *by default* - for instance, by providing a metapackage that pulls the two separate packages in together, or by having a Recommends: that automatically pulls the tls module in and automatically activates it Ok. But in this case installing the module *by default* via Recommends will *not* get the module active nor loaded. The user has to change the default configuration file and explicitly activate the tls module in order to get the tls loaded. Is is then ok to have the tls module in Recommneds? In that case, yes: because combining the plugin into a single program is an action taken by the user (by modifying the config), not by the maintainer. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: kamailio tls module and GPL openssl linking exception
2013/11/12 Steve Langasek vor...@debian.org: On Tue, Nov 12, 2013 at 10:10:58PM +0100, Victor Seva wrote: Is is then ok to have the tls module in Recommneds? In that case, yes: because combining the plugin into a single program is an action taken by the user (by modifying the config), not by the maintainer. OK. Now it's clear to me. Thank you so much Steve, Victor Seva -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caagy_vmm1xwme_bvuxyo1hmvfpsv7e0r4svqiq4fmajztfd...@mail.gmail.com
