SecurVille
Se não visualizar correctamente esta mensagem, clique aqui. Para não receber mais emails da Securitas, clique aqui.
Re: distributing a restricted branding icon OK?
Gabriel Burt writes: > Is changing http://www.emusic.com/favicon.ico to a PNG "modifying" it? > > Assume it's not, would we be OK including that image in our Debian > package of Banshee? The way iceweasel handles non-free search engine logos is to download them into the user's local profile when needed. Hendrik -- 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/878vwgvtph@mid.gienah.enyo.de
Re: distributing a restricted branding icon OK?
Le mardi 15 mars 2011 à 11:54 -0500, Gabriel Burt a écrit : > Is changing http://www.emusic.com/favicon.ico to a PNG "modifying" it? > > Assume it's not, would we be OK including that image in our Debian > package of Banshee? No, it would not. This icon is not free, in terms of copyright - and that’s regardless of any trademark issues. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1300210196.30617.179.camel@meh
distributing a restricted branding icon OK?
We are working on an eMusic.com extension to Banshee. They allow use (http://www.emusic.com/affiliate/affiliate_faq.html#9) of their unmodified logo. Bruce said back in 2005 (on http://lists.debian.org/debian-project/2005/08/msg00069.html): When creating the DFSG, I recognized, and respected, the right of authors to manage their own brand using trademarks, and to restrict the use of those trademarks in derived works as long as DFSG-compliant use of the software would be possible after a brand substitution. Is changing http://www.emusic.com/favicon.ico to a PNG "modifying" it? Assume it's not, would we be OK including that image in our Debian package of Banshee? Thanks, Gabriel -- 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/AANLkTikKKvgHQH_t=uaSLE=swhxgiegobr7qi9yjx...@mail.gmail.com
Re: GPL applications using Python (OpenSSL issue?)
2011/3/7 Ulrik Sverdrup : > Can GPLv3+ applications written in Python exist in Debian main? The > applications in question do not use an openssl exception. > > Python uses OpenSSL so the moment the application starts, it is linking > against it too: > > $ objdump -p /usr/bin/python2.6 | grep NEEDED > NEEDED libpthread.so.0 > NEEDED libdl.so.2 > NEEDED libutil.so.1 > NEEDED libssl.so.0.9.8 > NEEDED libcrypto.so.0.9.8 > NEEDED libz.so.1 > NEEDED libm.so.6 > NEEDED libc.so.6 > > In my case I am talking about a GPLv3+ package that exists in Debian -- > kupfer > > Where do I draw the line for using/linking against ssl? > > a) Using Python2.6 > b) Unintentionally introducing _ssl or ssl into the imported modules > (import any of urllib, httplib, socket etc!) > c) Unintentionally using ssl (use urllib.urlopen on URL provided by > user -- if it's https we are using openssl) > d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection > and verify certificates) > > Kupfer is today at (c) in the debian archive. It exists in development > version at (d). > > Clearly (d) has provoked thought but upon investigation I see that > "import ssl" only triggers "import _ssl" which in turn is an almost > no-op because _ssl is a built-in module in Python 2.6. > > Is this easier to answer than I think it is? I don't think this is easy to resolve. It's not the developer's (mine) issue, it's not the users issue but it's the distributors issue. FYI, it was briefly discussed on Python-dev: http://mail.python.org/pipermail/python-dev/2011-March/109032.html Of course kupfer (example app) can work without ssl. But the thread finds another problem, the inavailablity of hashlib (thus md5 and sha1): http://mail.python.org/pipermail/python-dev/2011-March/109051.html > But you're also left with not being able to 'import hashlib'. While python > has fallback > code, those modules (_md5, _sha, _sha256, _sha512) aren't built if openssl > was found > at build time. So you can't just select at runtime that you didn't want to > use openssl. > Not being able to import hashlib unfortunately makes urllib2 (and a lot of > 3rd party > packages) fail to import. md5 and sha1 are used in many desktop programs, for example to locate file thumbnails. Ulrik -- 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/AANLkTik=_+Q�dy93wuzpmsgudbdxo63dzq0xyuw...@mail.gmail.com
Re: scientific paper in package only in postscript form non-free?
tag 614525 - pending thanks Hi Joerg On Tue, Mar 15, 2011 at 09:26:33AM +0100, Joerg Jaspert wrote: > >> [...] It is doubtful that the PostScript files are > >> the source code referred to by DFSG item 2. More likely is that the > >> source files are TeX documents. > > > Cool, where is the agreed clearer version of DFSG 2 that says what it > > means by source code? > > > I feel it's a grey area, so if the PS files aren't too difficult to > > reconstruct, I'd still let them stay. > > Wouldnt pass NEW with *those* .ps only. Yes, PS can be source/preferred > form for modification for stuff to, there are those people who write it > directly, and thats fine. But in this case its pretty clear the > source/preferred > form for modification is a tex document, so we would request that. Ok, thanks for too the point of view from ftp-masters. I have not checked, it yet, but then the same problem may arise for 'multimix', which I encountered as it FTBFS too due to missing 'ghostscript' for ps2pdf in Build-Depends [1]. [1] http://bugs.debian.org/618031 I have cancelled the NMU for the moment. Bests Salvatore signature.asc Description: Digital signature
Re: scientific paper in package only in postscript form non-free?
>> [...] It is doubtful that the PostScript files are >> the source code referred to by DFSG item 2. More likely is that the >> source files are TeX documents. > Cool, where is the agreed clearer version of DFSG 2 that says what it > means by source code? > I feel it's a grey area, so if the PS files aren't too difficult to > reconstruct, I'd still let them stay. Wouldnt pass NEW with *those* .ps only. Yes, PS can be source/preferred form for modification for stuff to, there are those people who write it directly, and thats fine. But in this case its pretty clear the source/preferred form for modification is a tex document, so we would request that. -- bye, Joerg >From a NM after doing the license stuff: I am glad that I am not a lawyer! What a miserable way to earn a living. -- 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/87vczk6b7q@gkar.ganneff.de
