On Wed, Jul 24, 2002 at 07:38:15AM -0600, Joe Moore wrote:
> It's due to adding an "SSL_initialize()" feature to libgnomevfs.
No, more than that: You are adding a body of code called "OpenSSL"
which comes with its own license restrictions. You are still free
to write a replacement for it, and use
Glenn Maynard wrote:
> On Tue, Jul 23, 2002 at 06:09:38PM -0500, Jeff Licquia wrote:
>> It's not so hard to imagine a similar situation outside of TeX-world.
>> To quote a recently seen example:
>>
>> nautilus -> libgnomevfs0
>>
>> If you rebuild libgnomevfs0 and link it to OpenSSL, then you cha
Scripsit "Joe Moore" <[EMAIL PROTECTED]>
> If the derived work is licensed under the LPPL, but does not provide an
> "easy" remapping facility, then the derived work is not DFSG-free.
In this case the easy remapping (or one of the easy remapping options)
is to simply provide a *freshly written* f
On Tue, 2002-07-23 at 18:34, Glenn Maynard wrote:
> On Tue, Jul 23, 2002 at 06:09:38PM -0500, Jeff Licquia wrote:
> > It's not so hard to imagine a similar situation outside of TeX-world.
> > To quote a recently seen example:
> >
> > nautilus -> libgnomevfs0
> >
> > If you rebuild libgnomevfs0 a
On Tue, Jul 23, 2002 at 06:09:38PM -0500, Jeff Licquia wrote:
> It's not so hard to imagine a similar situation outside of TeX-world.
> To quote a recently seen example:
>
> nautilus -> libgnomevfs0
>
> If you rebuild libgnomevfs0 and link it to OpenSSL, then you change the
> license status of n
On Tue, 2002-07-23 at 17:58, Glenn Maynard wrote:
> Now, a DFSG-free program only needs one DFSG-free version of all of its
> dependencies to be in main (and not contrib), but this is getting messy.
> If B depends on A, and either A or B can be modified in any way, but some
> modifications to A may
On Wed, Jul 24, 2002 at 12:03:46AM +0200, Frank Mittelbach wrote:
> > If I remove any given features from a BSD-licensed program, it remains
> > free.
>
> but the same would be true for the LPPL as proposed to be rewritten by me with
> the help of Jeff and others.
>
> I repeat the essential poi
On Tue, 2002-07-23 at 17:03, Richard Braakman wrote:
> Frank Mittelbach pointed out that the LPPL itself is not transitive,
> so the "code from an LPPL'ed work" can be placed under a license that
> says "do anything you want, but don't rename it back to Foo". I hadn't
> thought of that, and I thin
Glenn Maynard writes:
> If I remove any given features from a BSD-licensed program, it remains
> free.
but the same would be true for the LPPL as proposed to be rewritten by me with
the help of Jeff and others.
I repeat the essential point is that requirement to be able to apply LPPL
would be w
On Tue, Jul 23, 2002 at 03:58:55PM -0600, Joe Moore wrote:
> Richard Braakman wrote:
> > Well, one of the properties of free software is that you can change it
> > :)
>
> I thought the primary benefit was to have unending discussions about license
> issues... :)
That's another of the properties o
On Tue, Jul 23, 2002 at 03:58:55PM -0600, Joe Moore wrote:
> Are all derived works from DFSG-free packages DFSG-free?
>
> No. The BSD network stack is DFSG-free. But Microsoft's implementation of
> it is not.
But that's due to them licensing their changes under another, non-free
license, not du
Richard Braakman wrote:
> On Tue, Jul 23, 2002 at 08:06:29AM -0600, Joe Moore wrote:
>> What's wrong with the conditional statement (unproven assertion:)
>> "The LPPL-1.3 is DFSG-free, but only when applied to software which
>> makes
>> the file-renaming requirement easy"
>
> Well, one of the
12 matches
Mail list logo
