Re: scientific paper in package only in postscript form non-free?

2011-03-15 Thread Joerg Jaspert
 [...] 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



Re: scientific paper in package only in postscript form non-free?

2011-03-15 Thread Salvatore Bonaccorso
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: GPL applications using Python (OpenSSL issue?)

2011-03-15 Thread Ulrik Sverdrup
2011/3/7 Ulrik Sverdrup ulrik.sverd...@gmail.com:
 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



distributing a restricted branding icon OK?

2011-03-15 Thread Gabriel Burt
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: distributing a restricted branding icon OK?

2011-03-15 Thread Josselin Mouette
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



Re: distributing a restricted branding icon OK?

2011-03-15 Thread Hendrik Weimer
Gabriel Burt gabriel.b...@gmail.com 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



SecurVille

2011-03-15 Thread Securitas









Se natilde;o visualizar correctamente esta mensagem, 
clique aqui.








































nbsp;Para natilde;o receber mais emails da Securitas, 
clique aqui.







nbsp;