Greetings,
I've been lurking on the list for a bit, haven't seen this come up, and
am unaware of a FAQ or list archive, so I'm going to go ahead and fire
off a few questions related to the LGPL and the possible development of
an LGPL-derived license - my apologies if it's an old topic.
MITRE
Ian Lance Taylor wrote:
Date: Wed, 01 Nov 2000 11:13:38 -0500
From: Bryan George [EMAIL PROTECTED]
As I said, that is how the LGPL _appears_. However, a close reading of
the license text reveals what again appears to be a poison pill where
commercial interests are
Date: Wed, 01 Nov 2000 12:37:07 -0500
From: Bryan George [EMAIL PROTECTED]
The LGPL is basically designed to support shared libraries. If you
can distribute your package as a shared library, then the LGPL does
not put any restrictions on the program which uses the library.
On 1 Nov 2000, Ian Lance Taylor wrote:
The LGPL puts restrictions on P when it is linked with L. But so
what? That linking will only happen on the end user system. The
typical effect is that the end user is not permitted to distribute the
executable now found in memory, because it is
begin [EMAIL PROTECTED] quotation:
In addition to the two examples given, the Linux kernel itself contains
an exception to allow linking of proprietary drivers (in non-source
form) directly with the Linux kernel.
That is my recollection, as well -- except my recollection was that it
Ian Lance Taylor wrote:
- Assuming I'm interpreting the LGPL text correctly, are there any
reasonable circumstances under which a company might be able to develop
and deploy a binary executable without being subject to the stated
conditions?
Distribute
I need an open source license; trouble is, I don't know whether one
that suits my specific requirements already exists or not. Here's the
situation; do any of you guys have any suggestions?
A friend and I intend to write an application that has some commercial
utility. In particular, similar
Ken Arromdee wrote:
On 1 Nov 2000, Ian Lance Taylor wrote:
The LGPL puts restrictions on P when it is linked with L. But so
what? That linking will only happen on the end user system. The
typical effect is that the end user is not permitted to distribute the
executable now found in
That's an interesting notion - let's follow it:
If I create and distribute a license which is a "derivative work" based
on the LGPL without permission from the FSF, I could be sued for
copyright violation. I couldn't claim "fair use" exemption either,
since the license would benefit commercial
[EMAIL PROTECTED] wrote:
I'd be interested in seeing a discussion of the relative merits of a
BSD/GPL dual license for cases like this. The rationale is as follows.
rationale omitted
This is an idea I've been rolling around for a while, there are a couple
of possible holes in it, but I'd be
Nearest thing I can think of is to start off with the GPL, then add a
rider along the lines of "if you sell this software or derived works, or
if you sell any service based on this software, then with every fee-
carrying transaction you must notify the customer of the full text of
this license,
Bryan George wrote:
If I create and distribute a license which is a "derivative work" based
on the LGPL without permission from the FSF, I could be sued for
copyright violation. I couldn't claim "fair use" exemption either,
since the license would benefit commercial interests.
Right.
From: Bryan George [SMTP:[EMAIL PROTECTED]]
[DJW:] IANAL
Under current copyright law, reproducing a similar concept, even using
different language, would be a violation once I've been exposed to the
[DJW:] Are you sure of this. I thought that this
was one of the
Naturally, I thought about the CVW license, but since the alternatives
are the MPL, which FSF specifically doesn't like, and GPL, which
precludes binary distribution sans code under any circumstances, it
doesn't quite hit the spot.
I'm beginning to settle in on the notion of invoking GPL +
Date: Wed, 1 Nov 2000 11:52:01 -0800 (PST)
From: Ken Arromdee [EMAIL PROTECTED]
On Wed, 1 Nov 2000, Bryan George wrote:
The LGPL puts restrictions on P when it is linked with L. But so
what? That linking will only happen on the end user system. ...
But the LGPL puts
Ian Lance Taylor wrote:
Date: Wed, 01 Nov 2000 13:19:57 -0500
From: Bryan George [EMAIL PROTECTED]
At any rate, I think this particular discussion thread is largely
academic. In the .com world, you have to make a strong case to convince
management that it's worth
Ian Lance Taylor wrote:
Date: Wed, 1 Nov 2000 11:52:01 -0800 (PST)
From: Ken Arromdee [EMAIL PROTECTED]
RMS's analysis is not directly about the GPL, but about what "derivative
work" means. If he's correct, he's correct independently of the actual
license; *any* license
On Wednesday 01 November 2000 06:04 pm, Ken Arromdee wrote:
But the LGPL puts no restrictions on the distribution of P, which is
what the proprietary user cares about.
That is not, however, what RMS believes. If there is only one shared
library that exists, he considers P to be
On Wednesday 01 November 2000 05:35 pm, Charlie Stross wrote:
What we want to do is make our application available under a license
that complies with the open source definition (as a minimum -- the
FSF's definitions would be better), but that makes it difficult for a
commercial entity to
On Wednesday 01 November 2000 07:02 pm, Mark Hatch wrote:
The intention here sounds similar to the Open Motif Public License (sic)
and the QPL. The OMPL requires royalties for use on non-"open systems" and
the original QPL was open source only for non-commercial uses. The OMPL is
*not* an
On Wednesday 01 November 2000 06:57 pm, Bryan George wrote:
Under current copyright law, reproducing a similar concept, even using
different language, would be a violation once I've been exposed to the
original work, so I couldn't write a license from scratch that resembled
the LGPL either
21 matches
Mail list logo
