On Mon, Mar 07, 2005 at 09:21:22AM +0100, Eduard Bloch wrote:
> > I just realized that the problem doesn't exist, since the fuse _library_
> > is under LGPL (since version 1.1). The kernel module is obviously
> > GPL, but nobody links against that except the kernel.
>
> Eeks. That means that Debi
On Mon, Mar 07, 2005 at 08:28:31AM +0100, Miklos Szeredi wrote:
> > That would be better. I am not the fuse maintainer (he is be'ing Cc'ed),
> > but normaly I would request at least a GPG signed mail for license
> > changes.
>
> I just realized that the problem doesn't exist, since the fuse _libra
#include
* Miklos Szeredi [Mon, Mar 07 2005, 08:28:31AM]:
> I just realized that the problem doesn't exist, since the fuse _library_
> is under LGPL (since version 1.1). The kernel module is obviously
> GPL, but nobody links against that except the kernel.
Eeks. That means that Debian's copyrig
> I've just asked on #debian-devel and here's what I got:
>
> http://lists.debian.org/debian-legal/2004/05/msg00595.html
> http://www.gnome.org/~markmc/openssl-and-the-gpl.html
>
> Also if there were some contributions (and according to changelog there
> were) you should ask contributors for the
> > > - replace openssl with gcrypt or such
> > > - add an exception to the GPL license of fuse (permission to link with
> > >OpenSSL)
> >
> > Permission granted :)
> >
> > Do I need to put it in some magic licence file in future releases?
>
> That would be better. I am not the fuse maint
On Sun, Mar 06, 2005 at 04:18:56PM +0100, Miklos Szeredi wrote:
> > PS: I see trouble coming. The package uses openssl but also the fuse
> > library which is licensed under the GPL (without the OpenSSL remark). So
> > the only way around this is:
> >
> > - replace openssl with gcrypt or such
> >
#include
* Miklos Szeredi [Sun, Mar 06 2005, 04:18:56PM]:
> > - replace openssl with gcrypt or such
> > - add an exception to the GPL license of fuse (permission to link with
> >OpenSSL)
>
> Permission granted :)
>
> Do I need to put it in some magic licence file in future releases?
That
> > I (lufs-cryptofs maintainer) support it! lufs-cryptofs is nice but needs
> > to be audited and I do not like the code, especially because LUFS is
> > dead upstream. encfs seems to be much better, and I want to get rid of
> > CFS (that I currently use) RSN.
>
> PS: I see trouble coming. The pac
On Sun, Mar 06, 2005 at 03:55:07PM +0100, Eduard Bloch wrote:
> > As a fuse maintainer all I can say that _right now_ encfs can't be
> > packaged, cause it needs 2.2 version of fuse which is waiting for
> > ftp-master approval for more than two months now.
>
> Do you have those packages somewhere
#include
* Bartosz Fenski aka fEnIo [Sun, Mar 06 2005, 03:05:20PM]:
> On Sun, Mar 06, 2005 at 02:43:49PM +0100, Eduard Bloch wrote:
> > I (lufs-cryptofs maintainer) support it! lufs-cryptofs is nice but needs
> > to be audited and I do not like the code, especially because LUFS is
> > dead upstrea
On Sun, Mar 06, 2005 at 02:43:49PM +0100, Eduard Bloch wrote:
> I (lufs-cryptofs maintainer) support it! lufs-cryptofs is nice but needs
> to be audited and I do not like the code, especially because LUFS is
> dead upstream. encfs seems to be much better, and I want to get rid of
> CFS (that I curr
#include
* Eduard Bloch [Sun, Mar 06 2005, 02:43:49PM]:
> I (lufs-cryptofs maintainer) support it! lufs-cryptofs is nice but needs
> to be audited and I do not like the code, especially because LUFS is
> dead upstream. encfs seems to be much better, and I want to get rid of
> CFS (that I currentl
Hello
I (lufs-cryptofs maintainer) support it! lufs-cryptofs is nice but needs
to be audited and I do not like the code, especially because LUFS is
dead upstream. encfs seems to be much better, and I want to get rid of
CFS (that I currently use) RSN.
So someone should step out and package encfs.
13 matches
Mail list logo
