Re: logo license with debian - no warranty missing?
Hi! Am 27.06.2010 15:13, schrieb Ben Finney: [ SVG logo without no warranty waiver ] This does seem to be a valid concern. The SVG standard allows for documents to contain executable code for animation with ECMAScript URL:http://www.w3.org/TR/SVG11/animate.html#DOMAnimationExample. So that at least makes it plausible that an SVG image could contain dangerous code. Is this something we should change? Not worry about? Much Ado Nothing? I think it would be prudent to add a warranty disclaimer like those found in Expat license terms or similar. Why do we need a warranty waiver for a feature, we don't actually use? Best regards, Alexander -- 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/4c29cb33.7040...@debian.org
Providing an openssl-linked pycurl
Hi debian-legal, Some people, who submitted or commented on bug #515200 would like to have a version of pycurl linked with OpenSSL, mostly because of features provided. Before going ahead with that, the maintainer asked to have some opinion from -legal, so with this post I'm trying to solicit comments. According to my understandment: - OpenSSL is released under a license which is GPL incompatible, unless an exception to the GPL is used in the software compiled with it. Debian cannot distribute GPL software released under the unmodified GPL and linked against OpenSSL. - pycurl is released under the LGPL (2.1 or later) or a MIT/X derivative license based on the one of curl itself. Neither of these licenses is incompatible with OpenSSL, and as for curl itself we should be able to provide a version of pycurl which uses openssl. Am I correct up to here? Now, what would be the status of (unmodified) GPL python software which imports pycurl? Is this considered the same as linking, and would it have to make sure it uses the GNUTLS version, by depending on it? This might open discussions about how to provide the feature tecnically (different module names in python, conflicting packages, etc) and make sure legality is kept, but in the meantime we'd just like a legal opinion on what would or would not be ok. (also considering it's OK for a user to use GPL+OpenSSL software if he wants, it's just not OK for us to distribute it). Thanks a lot for your help and attention, Guido -- 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/20100629135724.ga15...@rx.tixteam.net
Re: logo license with debian - no warranty missing?
Hi! Am 29.06.2010 14:49, schrieb Ben Finney: [ SVG logo without no warranty waiver ] I think it would be prudent to add a warranty disclaimer like those found in Expat license terms or similar. Why do we need a warranty waiver for a feature, we don't actually use? Because we also allow modified works to be redistributed. Someone else could use that feature in a derived work, redistribute the result, thereby cause breakage. I still don't understand. Is it prudent to have such a clause, because someone else could embed a bad script, to be sure we are safe? (How could that happen, if someone else causes the problem and distributes that?) Or would it be prudent to do so, to allow / make it easier for others to embed code, as they would only like to do so, if they have such a clause? I'm sorry, I still don't get the point. Best regards, Alexander -- 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/4c2a1706.5030...@schmehl.info
Re: Re: logo license with debian - no warranty missing?
Hello, I understand the fact this feature isn't currently used and sounds like FUD, but why such a clause does exist for the logo without Debian? It assumes that in case of damages implying the use of the logo, the Debian Project do not provide any warranty like for any software as well as it can be written. Regards Pompee William -- 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/4c2a4598.3070...@gmail.com
Re: Re: logo license with debian - no warranty missing?
On Tue, Jun 29, 2010 at 21:12:24 +0200, Pompee William wrote: Hello, I understand the fact this feature isn't currently used and sounds like FUD, but why such a clause does exist for the logo without Debian? It assumes that in case of damages implying the use of the logo, the Debian Project do not provide any warranty like for any software as well as it can be written. Because it's the BSD license (or close enough), which traditionally carries that disclaimer. Cheers, Julien signature.asc Description: Digital signature
Re: logo license with debian - no warranty missing?
On Tue, 29 Jun 2010 20:58:13 +0100 Julien Cristau wrote: On Tue, Jun 29, 2010 at 21:12:24 +0200, Pompee William wrote: Hello, I understand the fact this feature isn't currently used and sounds like FUD, but why such a clause does exist for the logo without Debian? It assumes that in case of damages implying the use of the logo, the Debian Project do not provide any warranty like for any software as well as it can be written. Because it's the BSD license (or close enough), which traditionally carries that disclaimer. Well, actually, it's the Expat license, but anyway... -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpeEApiJynJh.pgp Description: PGP signature
Plugins for non-free software in orig.tar.gz
Hello,
(Please CC me in the replies, I'm not subscribed to the ML).
I packaged Aqsis recently: http://packages.debian.org/source/unstable/aqsis
and it contains a kind of plugin, adaptor or something like that for a
software called Houdini [1], which is a high-end 3D animation package
developed by Side Effects Software which headquartered in Toronto, Canada.
Its chief distinction from other packages is that it has been designed as a
purely procedural environment. A version of the product, called Houdini
Apprentice, is available as a free download for non-commercial use.
[1] http://en.wikipedia.org/wiki/Houdini_(software)
This kind of plugin is intended enable Houdini using Aqsis renderer.
I can disable it and not build it/install it in binary packace, this plugin
isn't very important at the moment (e.g. it's not important enough to create
a binary package for contrib/); but I don't know whether we can have it in
the original source package, or it has to be removed altogether from
orig.tar.{gz,bz2,whatever}.
Also, I don't know if in the latter case, I should name the orig.tar.gz or
the package in some other way (like appending 'dfsg' or so). The closest
documentation that I got so far is this one:
http://www.debian.org/doc/developers-reference/best-pkging-practices.html#bpp-origtargz
Any hints?
Cheers.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
--
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/20100638.01186.manuel.montez...@gmail.com
Re: logo license with debian - no warranty missing?
Alexander Reichle-Schmehl alexan...@schmehl.info writes: I still don't understand. Is it prudent to have such a clause, because someone else could embed a bad script, to be sure we are safe? That's what I'm saying. As I see it, the potential for legal confusion over who is implicitly warranting the embedded program is a greater risk than simply using a warranty disclaimer in the license terms. (How could that happen, if someone else causes the problem and distributes that?) I assume “how could that happen” there refers to the legal confusion. I don't pretend to be an expert, but “The Debian project is a major copyright holder in this work which caused damage to our systems, and there's no warranty disclaimer” isn't particularly implausible. Such a situation would predictably (not inevitably) lead to a court battle over who caused the damage; even if the Debian project knows that it's blameless, that could be expensive to prove in a court case. If a warranty disclaimer can nip that in the bud, by avoiding the need to discuss who did what, it seems like a simple and low-cost way to reduce the risk. I'm not insisting, but it seems that there is little downside to doing so, and a plausible risk is averted; which is why I say it would be prudent to do so. -- \ Eccles: “I just saw the Earth through the clouds!” Lew: “Did | `\ it look round?” Eccles: “Yes, but I don't think it saw me.” | _o__)—The Goon Show, _Wings Over Dagenham_ | Ben Finney -- 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/87fx05jwrr@benfinney.id.au
Re: Plugins for non-free software in orig.tar.gz
On Wed, 30 Jun 2010 00:08:00 +0200 Manuel A. Fernandez Montecelo wrote:
Hello,
Hello! :-)
(Please CC me in the replies, I'm not subscribed to the ML).
Done.
I packaged Aqsis recently: http://packages.debian.org/source/unstable/aqsis
Thank you for doing so: it looks like an interesting tool...
and it contains a kind of plugin, adaptor or something like that for a
software called Houdini [1], which is
[...]
available as a free download for non-commercial use.
[...]
This kind of plugin is intended enable Houdini using Aqsis renderer.
I can disable it and not build it/install it in binary packace, this plugin
isn't very important at the moment (e.g. it's not important enough to create
a binary package for contrib/); but I don't know whether we can have it in
the original source package, or it has to be removed altogether from
orig.tar.{gz,bz2,whatever}.
I think the key questions here are:
0) does the plugin itself comply with the DFSG?
1) does the plugin require anything outside of main for compilation?
2) does the plugin constitute a secondary feature of aqsis?
I suppose the answer to question number 2 is affirmative, since you say
that you can disable it, and that it's not that important...
Any hints?
Another question, before I forget.
The debian/copyright file for aqsis
http://packages.debian.org/changelogs/pool/main/a/aqsis/aqsis_1.6.0-1.1/aqsis.copyright
states:
| Copyright for 'sdcBMP/d_sdcBMP.cpp' and 'sdcWin32/d_sdcWin32.cpp' under
| 'tools/displays/' directory:
|
| COPYRIGHT
|
| Copyright 2000 by Schroff Development Corporation, Shawnee-Mission,
| Kansas, United States of America. All rights reserved.
|
|
|
| This Display Driver is distributed as freeware. There are no
| restrictions on its' usage.
|
|
|
| DISCLAIMER OF ALL WARRANTIES AND LIABILITY
|
| Schroff Development Corporation makes no warranties, either expressed
| or implied, with respect to the programs contained within this file, or
| with respect to software used in conjunction with these programs. The
| programs are distributed 'as is'. The entire risk as to its quality and
| performance is assumed by the purchaser. Schroff Development Corporation
| does not guarantee, warrant or make any representation regarding the
| use of, or the results of the use of the programs in terms of correctness,
| accuracy, reliability, or performance. Schroff Development Corporation
| assumes no liability for any direct, indirect, or consquential, special
| or exemplary damages, regardless of its having been advised of the
| possibility of such damage.
|
I cannot see any permission to distribute and/or sell these two files
(DFSG#1); also, I cannot see any permission to modify (DFSG#3).
Hence, it seems to me that those two files fail to comply with the
DFSG, and should consequently be removed from the package, if at all
possible, or substituted by DFSG-free replacements.
Or am I missing something?
--
http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
Need some pdebuild hook scripts?
. Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpgFjwV4oV62.pgp
Description: PGP signature
Re: logo license with debian - no warranty missing?
Le Wed, Jun 30, 2010 at 08:31:52AM +1000, Ben Finney a écrit : I assume “how could that happen” there refers to the legal confusion. I don't pretend to be an expert, but “The Debian project is a major copyright holder in this work which caused damage to our systems, and there's no warranty disclaimer” isn't particularly implausible. Such a situation would predictably (not inevitably) lead to a court battle over who caused the damage; even if the Debian project knows that it's blameless, that could be expensive to prove in a court case. Hi Ben and Pompee, it would be much more productive if this scenario would be accompanied with some data and facts about which law in which country make the non-warranty disclaimer necessary, exemplified by cases where these laws have successfully been used in court by the plaintiff. In the absence of such an analysis, the discussion is purely about fear, uncertainty and doubt. While it is true that most of the major players in the free software world have opted for having non-warranty disclaimers in their license, I think that we should do our best to base our actions on our understanding, not on the imitation of the others. It is the addition of extra clauses and vague disclaimers that sometimes make licenses non-free (clauses like ‘do not kill people with my software’), so let's resist to temptation of making our license statements longer than what is necessary. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100629235934.ga6...@kunpuu.plessy.org
Re: Plugins for non-free software in orig.tar.gz
Hi, On Wednesday 30 June 2010 00:48:45 Francesco Poli wrote: I packaged Aqsis recently: http://packages.debian.org/source/unstable/aqsis Thank you for doing so: it looks like an interesting tool... Actually it was already packaged long ago, I'm just packaging the latest version since the maintainer has been unattending it for years. I think the key questions here are: 0) does the plugin itself comply with the DFSG? It doesn't have any copyright line, other than: # This document is under CC-3.0 Attribution-Share Alike 3.0 # http://creativecommons.org/licenses/by-sa/3.0/ # Attribution: There is no requirement to attribute the author. # # Produced by: # Side Effects Software Inc # 123 Front Street West, Suite 1401 # Toronto, Ontario # Canada M5J 2M2 # 416-504-9876 in RIBaqsis1.6.py The author as far as I know is from Aqsis Team, everything is released under GPL or LGPL. 1) does the plugin require anything outside of main for compilation? It doesn't seem to need compilation, they're python scripts (or a variant called hython), .bat and .sh scripts... you can see everything under tools/neqsus in the source: http://aqsis.git.sourceforge.net/git/gitweb.cgi?p=aqsis/aqsis;a=tree;f=tools/neqsus/houdini;h=79987b52ff4275b2792a0328c8673e711c16424d;hb=HEAD The project leader told me: Leon will confirm, but I think it's a script to convert our slx output into something that Houdini can use to display shader parameters in the UI. 2) does the plugin constitute a secondary feature of aqsis? I suppose the answer to question number 2 is affirmative, since you say that you can disable it, and that it's not that important... Sure, the project leader told me also that there would be no problem in removing it... so the main question is how do I name orig.tar.gz, create the patches, if I have to name the binary packages like 'dfsg' or something similar. Any hints? Another question, before I forget. The debian/copyright file for aqsis http://packages.debian.org/changelogs/pool/main/a/aqsis/aqsis_1.6.0-1.1/a qsis.copyright states: | Copyright for 'sdcBMP/d_sdcBMP.cpp' and 'sdcWin32/d_sdcWin32.cpp' under | 'tools/displays/' directory: | --- | - COPYRIGHT | | Copyright 2000 by Schroff Development Corporation, Shawnee-Mission, | Kansas, United States of America. All rights reserved. | | * | *** | | This Display Driver is distributed as freeware. There are no | restrictions on its' usage. | | * | *** | | DISCLAIMER OF ALL WARRANTIES AND LIABILITY | | Schroff Development Corporation makes no warranties, either expressed | or implied, with respect to the programs contained within this file, or | with respect to software used in conjunction with these programs. The | programs are distributed 'as is'. The entire risk as to its quality | and performance is assumed by the purchaser. Schroff Development | Corporation does not guarantee, warrant or make any representation | regarding the use of, or the results of the use of the programs in | terms of correctness, accuracy, reliability, or performance. Schroff | Development Corporation assumes no liability for any direct, indirect, | or consquential, special or exemplary damages, regardless of its | having been advised of the possibility of such damage. | --- | - I cannot see any permission to distribute and/or sell these two files (DFSG#1); also, I cannot see any permission to modify (DFSG#3). Hence, it seems to me that those two files fail to comply with the DFSG, and should consequently be removed from
Re: logo license with debian - no warranty missing?
Charles Plessy ple...@debian.org writes: it would be much more productive if this scenario would be accompanied with some data and facts about which law in which country make the non-warranty disclaimer necessary, exemplified by cases where these laws have successfully been used in court by the plaintiff. I'll have to leave that work to others more motivated. I'm sufficiently convinced (by what I've explained earlier in this thread) that any work that *can* be interpreted as a functioning executable is an equally valid target for a warranty disclaimer. So, a software work that happens to be an SVG document needs a warranty disclaimer to the same extent that any other software work does. -- \ “My interest is in the future, as I am going to spend the rest | `\ of my life there.” —Charles F. Kettering | _o__) | Ben Finney -- 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/877hlhjm1t@benfinney.id.au
Re: Providing an openssl-linked pycurl
Guido Trotter wrote: According to my understandment: - OpenSSL is released under a license which is GPL incompatible, unless an exception to the GPL is used in the software compiled with it. Debian cannot distribute GPL software released under the unmodified GPL and linked against OpenSSL. - pycurl is released under the LGPL (2.1 or later) or a MIT/X derivative license based on the one of curl itself. Neither of these licenses is incompatible with OpenSSL, and as for curl itself we should be able to provide a version of pycurl which uses openssl. Am I correct up to here? http://packages.debian.org/changelogs/pool/main/p/pycurl/current/copyright suggests so. Now, what would be the status of (unmodified) GPL python software which imports pycurl? Is this considered the same as linking, and would it have to make sure it uses the GNUTLS version, by depending on it? What GNUTLS version? Oh, it looks like that's the current version. As I understand it, if the GPL python software were derived from openssl in some way, then there would be a problem. Otherwise, not. If it worked with a GNUTLS version of pycurl unmodified/interchangably, I think it's unlikely there's a problem. But then the GNUTLS version must exist to be sure things work, so why not use the GNUTLS version? In the case of bug 515200, the report about www1.banking.first-direct.com has a solution in bug 532752 (which maybe could be used by some setopt call in pycurl?), while the dynamic routing firewall problem awaits more information in bug 532752 since June 2009. If there are bugs in GNUTLS or remote servers, please try to help their maintainers to debug them, rather than rebuilding every single gnutls-using package to use openssl and spread a licensing can of worms which gnutls helps to keep closed. Also, is rebuilding even a proper fix for 515200? It looks like www1.banking.first-direct.com might have a problem and I suspect maybe if/when openssl supports whatever feature is causing connection problems (TLS1.1?), it might fail too then. This might open discussions about how to provide the feature tecnically (different module names in python, conflicting packages, etc) and make sure legality is kept, but in the meantime we'd just like a legal opinion on what would or would not be ok. (also considering it's OK for a user to use GPL+OpenSSL software if he wants, it's just not OK for us to distribute it). To be clear: I do not offer a legal opinion. I am not a lawyer. Ask one if you want legal opinion. If you want the debian project to ask, I think you need to persuade some official (ftp-master or leader seem most likely) to request it. Hope that explains, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- 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/20100630021105.d2986f7...@nail.towers.org.uk
