On Fri, Jan 28, 2005 at 12:47:21PM -0800, Josh Triplett wrote:
Good luck proving your replacement isn't a derived work after you've
studied the GPLed work you are replacing.
Actually, he has a point there. There has to be significantly more going
on than read the GPLed work for some other work
I'll respond to most of this later (I'll be traveling for a few days),
but I just had to say:
How is the technical issue of your inability to build a piece of
software on a particular proprietary OS remotely relevant? The license
certainly doesn't stop you from doing so.
I'm on an older
On Wed, 26 Jan 2005 12:33:35 -0800, Josh Triplett [EMAIL PROTECTED] wrote:
Michael K. Edwards wrote:
[snip]
Of course it is possible for proprietary software to compete with free
software without employing GPL components. It's also possible for one
commercial spreadsheet to compete with
On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote:
If the public benefit of interoperability outweighs the harm done to a
copyright holder by permitting competitive use of the interface they
created, how can it not outweigh the harm to him of permitting
cooperative use?
Why
On Thu, Jan 27, 2005 at 02:18:48PM -0800, Michael K. Edwards wrote:
I do want my government and my cellphone to run on Free Software,
and neither will happen in my lifetime if there isn't a commercially
viable transition strategy.
If you want to work towards a situation where everything is
Why assume that interoperability is the only benefit from release under
copyleft?
On Thu, Jan 27, 2005 at 07:45:29PM -0800, Michael K. Edwards wrote:
I'm not assuming that. I'm saying that the public benefit of
interoperability, used in a number of the decisions that I've cited to
justify
On Wed, Jan 26, 2005 at 09:38:19AM -0500, Raul Miller wrote:
If I understand you correctly, you could address all your company's
concerns by licensing the headers and build files needed to compile your
libraries under BSD (or maybe LGPL) and license the rest of your content
under GPL.
Or is
On Wed, 26 Jan 2005 09:38:19 -0500, Raul Miller [EMAIL PROTECTED] wrote:
[snip]
Because all public interfaces is too general a concept.
Too general for what? Not too general for the precedents and public
policy imperatives to be applicable. Not too general to describe
clearly. Not too general
On Wed, 26 Jan 2005 09:38:19 -0500, Raul Miller [EMAIL PROTECTED] wrote:
Because all public interfaces is too general a concept.
On Wed, Jan 26, 2005 at 03:03:57PM -0800, Michael K. Edwards wrote:
Too general for what?
That is indeed a good question.
Once we settle what it is that we're
On Wed, Jan 26, 2005 at 03:09:58PM -0800, Michael K. Edwards wrote:
Great. Except either this interpretation isn't part of the contract,
and therefore doesn't bind other contributors, or else I've created
another little almost-GPL fiefdom, and any bit of code that turns out
to have been
On Tue, Jan 25, 2005 at 01:41:02PM -0800, Michael K. Edwards wrote:
I'm focusing on a simple case. Pre-existing GPL library, shipped
unaltered, or with any bug fixes and enhancements contributed
upstream. New application (PEOTL) written to use the library.
Tested and shipped together, with
On Tue, 25 Jan 2005 17:19:43 -0500, Raul Miller [EMAIL PROTECTED] wrote:
On Tue, Jan 25, 2005 at 01:41:02PM -0800, Michael K. Edwards wrote:
I'm focusing on a simple case. Pre-existing GPL library, shipped
unaltered, or with any bug fixes and enhancements contributed
upstream. New
On Tue, 25 Jan 2005 19:11:27 -0500, Raul Miller [EMAIL PROTECTED] wrote:
[snip]
You think the bright line which has yet to be drawn is not far from
the theory articulated in lotus an lexmark? That's... a fairly murky
way of thinking...
I think that a bright line could be drawn substantially
On Thu, Jan 20, 2005 at 08:51:46PM -0800, Michael K. Edwards wrote:
We seem to be talking past one another. Maybe it's just that I'm
implicitly assuming a separation between library source code and
program source code, and saying that the latter is only a derivative
work of the former if it
On Thu, 20 Jan 2005 11:53:37 -0500, Raul Miller [EMAIL PROTECTED] wrote:
[snip]
I'd say this differently. The program is not a derivative work of
the library if it was written without any of the relevant copyrighted
material of that library.
No, it's not a derivative work if it was written
Grzegorz B. Prokopski [EMAIL PROTECTED] writes:
Your implementation creates a huge loophole in GPL, that I do not
believe is there. Let's continue your way of seeing interepter
features and see what would be the consequences.
An example. I am writing an app. A GPL-incompatible or even
Grzegorz B. Prokopski wrote:
I would then just take the GPLed code of this GC library, GPLed code
of readline, cut out the pieces I need, integrate into my interepreter
and call it interepter features. Thus, according to you, my
GPL-incompatible program would be able to use GPLed code thanks to
On Fri, 14 Jan 2005 22:12:56 +, Andrew Suffield
[EMAIL PROTECTED] wrote:
[snip]
Some of those python scripts may be derivatives of GNU readline. Most
are probably not. Those that are must be licensed under the GPL. The
rest do not have to be. All this interpreter crud in between is
On Thu, 2005-13-01 at 23:42 -0500, Brian Thomas Sniffen wrote:
Grzegorz B. Prokopski [EMAIL PROTECTED] writes:
These facilities include class loading, class instantiation,
synchronization, garbage collection (ie. you can trigger GC from within
your program), reflection (ie. you can ask VM
Grzegorz B. Prokopski [EMAIL PROTECTED] writes:
Your implementation creates a huge loophole in GPL, that I do not
believe is there. Let's continue your way of seeing interepter
features and see what would be the consequences.
An example. I am writing an app. A GPL-incompatible or even
On Fri, Jan 14, 2005 at 04:42:44PM -0500, Brian Thomas Sniffen wrote:
An example. I am writing an app. A GPL-incompatible or even
closed-source one. I'd love to use this conservative garbage collector
library, but it's under GPL, so I cannot. I'd also love to use
libreadline, but I
Grzegorz B. Prokopski wrote:
I would then just take the GPLed code of this GC library, GPLed code
of readline, cut out the pieces I need, integrate into my interepreter
and call it interepter features. Thus, according to you, my
GPL-incompatible program would be able to use GPLed code thanks
On Fri, 14 Jan 2005 22:12:56 +, Andrew Suffield
[EMAIL PROTECTED] wrote:
[snip]
Some of those python scripts may be derivatives of GNU readline. Most
are probably not. Those that are must be licensed under the GPL. The
rest do not have to be. All this interpreter crud in between is
On Thu, 2005-13-01 at 17:24 -0500, Raul Miller wrote:
On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote:
But was Kaffe _extended_ to provide such bindings for Eclipse 3.0?
This FAQ entry discusses 2 cases. One is when we have an interpreter,
that basically goes over
Is this relevant to Eclipse? I was under the impression that Eclipse
was pure java -- that it did not use JNI at all.
If Eclipse does use JNI, would still a question about whether or not
Kaffe's JNI implementation constitute some kind of extension designed
to work around the GPL or
Grzegorz B. Prokopski [EMAIL PROTECTED] writes:
These facilities include class loading, class instantiation,
synchronization, garbage collection (ie. you can trigger GC from within
your program), reflection (ie. you can ask VM what are methods that
this class have?).
Those are features of
On Thu, 2005-13-01 at 17:24 -0500, Raul Miller wrote:
On Thu, Jan 13, 2005 at 04:35:50PM -0500, Grzegorz B. Prokopski wrote:
But was Kaffe _extended_ to provide such bindings for Eclipse 3.0?
This FAQ entry discusses 2 cases. One is when we have an interpreter,
that basically goes over
Is this relevant to Eclipse? I was under the impression that Eclipse
was pure java -- that it did not use JNI at all.
If Eclipse does use JNI, would still a question about whether or not
Kaffe's JNI implementation constitute some kind of extension designed
to work around the GPL or
28 matches
Mail list logo
