Re: openssl vs. GPL question

[Michael K. Edwards]

(copied to debian-legal, where the discussion belongs; next person
please cut debian-mentors)

On 6/4/05, Dafydd Harries <[EMAIL PROTECTED]> wrote:
> I have a package Alexandria, written in Ruby, which will depend on a
> new library in the next version. This library, ruby-zoom, is an LGPL Ruby
> binding of libyaz. libyaz links to OpenSSL and is, as far as I can tell,
> under a 2-clause BSD licence. Everything fine so far.
> 
> But it seems to me that it will be impossible for Alexandria, which is
> under the GPL, to use ruby-zoom legally as, by doing so, it will be
> linking against OpenSSL, which is under a GPL-incompatible licence. Am I
> right in thinking so?

It is Debian's historical practice, and the FSF's stance, not to
permit this kind of dependency (direct or indirect).  I believe
strongly, and have adduced plenty of case law to demonstrate, that the
FSF's GPL FAQ is in error on this point.  I would not say, however,
that my opinion represents a debian-legal consensus.  See recent
debian-legal threads about Quagga, which is in a similar position.

> My understanding of this issue is based on reading this thread:
> 
> http://lists.debian.org/debian-legal/2002/10/msg00113.html
> 
> If there is indeed a licence problem here, I can see two main solutions:
> 
>  - Try to get libyaz in Debian to link against GnuTLS instead of
>OpenSSL.
> 
>  - Get the maintainer of Alexandria to make an exception for linking
>against OpenSSL.

The latter is probably a better choice (at least in the short term),
since the OpenSSL shim for GNU TLS was added to the GPL (not LGPL)
libgnutls-extra.  (It's possible that it has since been moved into the
LGPL portion, but I don't think so.)  While I don't believe in the
FSF's theories about linking causing "GPL violation" (especially in
the indirect scenario), it's the Debian way to request a clarification
from upstream.

> I notice that the Tellico package, which is GPL, already links against
> libyaz. Is this a licence violation?

No; but there again, it would probably be best to check with upstream
about whether they would mind adding an explicit "OpenSSL exemption". 
Wishlist bug?

Cheers,
- Michael
(IANAL, IANADD)

subscribe

[Søren Hansen]

subscribe
-- 
Søren Hansen <[EMAIL PROTECTED]>

Re: RFS: gephex 0.4.3

[Martin Bayer]

> Gephex is a realtime video processing and manipulation system for video
> installations and vj setups.

I forgot the [i386] only build dependency on nasm.  The 0.4.3-3 package
fixes this problem.

http://www.gephex.org/debian/dists/unstable/main/source/gephex_0.4.3.orig.tar.gz
http://www.gephex.org/debian/dists/unstable/main/source/gephex_0.4.3-3.dsc
http://www.gephex.org/debian/dists/unstable/main/source/gephex_0.4.3-3.diff.gz

Martin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

openssl vs. GPL question

[Dafydd Harries]

Hi,

I have a package Alexandria, written in Ruby, which will depend on a
new library in the next version. This library, ruby-zoom, is an LGPL Ruby
binding of libyaz. libyaz links to OpenSSL and is, as far as I can tell,
under a 2-clause BSD licence. Everything fine so far.

But it seems to me that it will be impossible for Alexandria, which is
under the GPL, to use ruby-zoom legally as, by doing so, it will be
linking against OpenSSL, which is under a GPL-incompatible licence. Am I
right in thinking so?

My understanding of this issue is based on reading this thread:

http://lists.debian.org/debian-legal/2002/10/msg00113.html

If there is indeed a licence problem here, I can see two main solutions:

 - Try to get libyaz in Debian to link against GnuTLS instead of
   OpenSSL.

 - Get the maintainer of Alexandria to make an exception for linking
   against OpenSSL.

I notice that the Tellico package, which is GPL, already links against
libyaz. Is this a licence violation?

-- 
Dafydd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: wmii -- lightweight, tiling and tabbed X11 window manager

[Christoph Wegscheider]

Ralph Amissah <[EMAIL PROTECTED]> wrote:
> ++ same here.
> Surprised this has taken so long to happen.
> I'd recommend wmi over all other window managers, except,
> well except ion3 and then, only if you are prepared to 
> spend the time to get to know it. (it takes all types :)
This RFS is not about wmi, but about its successor wmii (wmi2, upstream
chose a roman numbering style resulting in wmii). I tried to bring wmi
into debian, but lacking a sponsor for it. After the upstream author
stopped maintaining wmi it was no option to bring it into debian
anymore.

A DD already got in contact with me and is willing to sponsor the
package, so hopefully we will see it in debian soon :)

Christoph


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: wmii -- lightweight, tiling and tabbed X11 window manager

[Ralph Amissah]

++ same here.

Surprised this has taken so long to happen.

I'd recommend wmi over all other window managers, except,
well except ion3 and then, only if you are prepared to 
spend the time to get to know it. (it takes all types :)

Do make this happen.

Thanks,
Ralph

On 6/3/05, Nico Golde <[EMAIL PROTECTED]> wrote:
> Hello Christoph,
> 
> * Christoph Wegscheider <[EMAIL PROTECTED]> [2005-06-03 17:24]:
> > I'm seeking a sponsor for:
> >
> > * Package name: wmii
> >   Version : 1
> >   Upstream Author : Anselm R. Garbe 
> > * URL : http://wmi.modprobe.de/
> > * License : MIT/X
> >   Description : lightweight, tiling and tabbed X11 window manager
> 
> [...]
> I`d like to see this great wm in debian too.
> Regards Nico
> --
> Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
> http://www.ngolde.de | http://www.muttng.org | http://grml.org
> VIM has two modes - the one in which it beeps
> and the one in which it doesn't -- encrypted mail preferred
> 
> 
> 


-- 
email:  [EMAIL PROTECTED]
.: [EMAIL PROTECTED]
SiSU:   http://www.jus.uio.no/sisu

Re: splitting a package's source

[Jeroen van Wolffelaar]

On Sat, Jun 04, 2005 at 12:18:47PM +0300, Shachar Shemesh wrote:
> Hi all,
> 
> I am both the maintainer and upstream for a package called "rsyncrypto". 
> It's an encryption program for files with a twist (rsync friendly).
> 
> Putting on my upstream hat, I am trying to make sure the package keeps 
> on consistently conforming to previous versions. To that end I have 
> created a regression testing infrastructure. It's a bunch of files 
> pre-encrypted and with their keys. It also has a script that checks that 
> the current version can still decrypt the original files in the 
> regression test suite.
> 
> Here's the problem, though. These tests are binary files, that make CVS 
> sluggish and unresponsive. I simply cannot keep them on the same CVS 
> tree as the sources for rsyncrypto. As such, I want to split the 
> regression tests to a separate source file.
> 
> Removing my upstream hat, and putting on my maintainer hat, I would 
> still like that building rsyncrypto will be able to "make test" and run 
> the regression test suite on the files. In effect, I need rsyncrypto to 
> be built from two source files. My question is, "is this possible"?
> 
> One way I thought of doing it is to create a Debian package called 
> "rsyncrypto-regtest", and have rsyncrypto build-depend on it. That is 
> probably the best way to solve my specific problem, and will be what 
> I'll do, but I'm wondering whether there isn't another way of doing it. 
> Is it possible to have two source files build the same package?

You talk separate source *file*, I'm sure you mean separate source
.tar.gz? If not, I don't understand you, as a source package consists of
lots of files in a .tar.gz.

I consider an extra package for this quite unneeded bloat. Putting
on your upstream hat, I see no reason to not provide one tarball which
includes those binaries next to the source files, and using some script
to make your release tarballs that will convert for example
base64-encoded binary files from CVS into real binaries at
tarball-build-time. Fwiw, I never noticed CVS really being sluggish with
binary files, but if so, you might want to resolve that in some way (by
moving to a different version control system?). Or just do it mostly the
way you do now, just create the release tarballs from the two sources
together.


It's good to have regression tests at build time, and they certainly
should be enabled when available at build time (and the build fails if
the regression test fails). Working around version control difficulties
by making another Debian package is not really a nice way to do it, and
for what it's worth, if that's indeed the only reason you have a second
binary package, chances are high your package would get rejected for
that reason when you upload it to the archive.

I hope this helps, good luck!
--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help Requested for testing a Game on a PowerPC Architecture

[Miriam Ruiz]

Lots of thanks Roger!

I'll tell upstream author about the warnings and the sound, but I'm glad it
works. Lots of thanks, really :)

Greetings,
Miry




__ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: splitting a package's source

[Shachar Shemesh]

Nigel Jones wrote:


If there are other custom build tools, you may just want to consider a
rsyncrypto-dev package, otherwise you might just want to settle with
rsyncrypto-test (people may not understand what regtest is a reference
to, I actually thought for a moment it expanded to "registration
test".
 


Ok.


As for Build-Depend, I doubt that, why not make -test a completely
seperate package,


That's what I was talking about.


have a rsyncryptotest binary to run the test
commands, and have that Depend on "rsyncrypto", that means you are
giving X user the option to run the test suite, by doing this, it
means that users who don't care (many sadly don't) aren't forced to
test something they don't want to.
 

I was aiming for something else, really. I was aiming for having a "make 
test" as part of the make process. This way, if rsyncrypto suddenly 
failed to work on PPC platform, I would get notified without having to 
hope that the porting group would get around to it. The thing is that 
I'm trying to put that into the standard rsyncrypto build system.


I was thinking of having rsyncrypto-test recommend rsyncrypto. This will 
also be useful for users who build their own versions of rsyncrypto 
(i.e. - without a deb). So I would have:

rsyncrypto suggests rsyncrypto-test, as well as build-depends on it.
rsyncrypto-test which recommends rsyncrypto.

The build process for rsyncrypto-test would only package files, not 
actually compile anything.
The build process for rsyncrypto would run make-test after make, so that 
if something went wrong I (debian maintainer) will know about it, even 
if it's not for my platform.



It also means that users can easily verify any prebuilt binaries
quickly and easily.
 

They can do that with this scheme. I guess the main question is "should 
debian/rules run make test, if upstream provided one"?


 Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Help Requested for testing a Game on a PowerPC Architecture

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Miriam Ruiz <[EMAIL PROTECTED]> writes:

> Latest version of the game Holotz's Castle crashed on powerpc due to endianess
> problems ( http://bugs.debian.org/304715 ). According to upstream author this
> is solved now, but neither he nor me have a powerpc availabe in which we can
> test it, so we cannot be sure of it.

It Worked For Me™.  I started a new game, and played for a few
screens without problems.  There wasn't any sound, though.


- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCoZiPVcFcaSW/uEgRAkn1AKCj8+Vs0Bq64LFNyeaYMwB+Ytf26gCg6KSv
gnv/TizsFhHN0+Kp71Jbrz4=
=/x+e
-END PGP SIGNATURE-

Re: splitting a package's source

[Nigel Jones]

On 04/06/05, Shachar Shemesh <[EMAIL PROTECTED]> wrote:
> Hi all,
> 
> I am both the maintainer and upstream for a package called "rsyncrypto".
> It's an encryption program for files with a twist (rsync friendly).
> 
> Putting on my upstream hat, I am trying to make sure the package keeps
> on consistently conforming to previous versions. To that end I have
> created a regression testing infrastructure. It's a bunch of files
> pre-encrypted and with their keys. It also has a script that checks that
> the current version can still decrypt the original files in the
> regression test suite.
> 
> Here's the problem, though. These tests are binary files, that make CVS
> sluggish and unresponsive. I simply cannot keep them on the same CVS
> tree as the sources for rsyncrypto. As such, I want to split the
> regression tests to a separate source file.
> 
> Removing my upstream hat, and putting on my maintainer hat, I would
> still like that building rsyncrypto will be able to "make test" and run
> the regression test suite on the files. In effect, I need rsyncrypto to
> be built from two source files. My question is, "is this possible"?
> 
> One way I thought of doing it is to create a Debian package called
> "rsyncrypto-regtest", and have rsyncrypto build-depend on it. That is
If there are other custom build tools, you may just want to consider a
rsyncrypto-dev package, otherwise you might just want to settle with
rsyncrypto-test (people may not understand what regtest is a reference
to, I actually thought for a moment it expanded to "registration
test".

As for Build-Depend, I doubt that, why not make -test a completely
seperate package, have a rsyncryptotest binary to run the test
commands, and have that Depend on "rsyncrypto", that means you are
giving X user the option to run the test suite, by doing this, it
means that users who don't care (many sadly don't) aren't forced to
test something they don't want to.

It also means that users can easily verify any prebuilt binaries
quickly and easily.

> probably the best way to solve my specific problem, and will be what
> I'll do, but I'm wondering whether there isn't another way of doing it.
> Is it possible to have two source files build the same package?
> 
> Thanks,
>Shachar
> 
> --
> Shachar Shemesh
> Lingnu Open Source Consulting ltd.
> Have you backed up today's work? http://www.lingnu.com/backup.html
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
> 


-- 
N Jones

splitting a package's source

[Shachar Shemesh]

Hi all,

I am both the maintainer and upstream for a package called "rsyncrypto". 
It's an encryption program for files with a twist (rsync friendly).


Putting on my upstream hat, I am trying to make sure the package keeps 
on consistently conforming to previous versions. To that end I have 
created a regression testing infrastructure. It's a bunch of files 
pre-encrypted and with their keys. It also has a script that checks that 
the current version can still decrypt the original files in the 
regression test suite.


Here's the problem, though. These tests are binary files, that make CVS 
sluggish and unresponsive. I simply cannot keep them on the same CVS 
tree as the sources for rsyncrypto. As such, I want to split the 
regression tests to a separate source file.


Removing my upstream hat, and putting on my maintainer hat, I would 
still like that building rsyncrypto will be able to "make test" and run 
the regression test suite on the files. In effect, I need rsyncrypto to 
be built from two source files. My question is, "is this possible"?


One way I thought of doing it is to create a Debian package called 
"rsyncrypto-regtest", and have rsyncrypto build-depend on it. That is 
probably the best way to solve my specific problem, and will be what 
I'll do, but I'm wondering whether there isn't another way of doing it. 
Is it possible to have two source files build the same package?


Thanks,
  Shachar

--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]