wine-devel

wine-devel@winehq.org

4 participants
84472 discussions

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Trying to claim, even though you didn't, that Winelib is > > effected is absurd since it is independent of the debugger. > > Distributing the debugger with WineLib is merly an aggregation > > nothing more. > > In theory any library that the debugger uses will also fall under the > GPL. In _theory_ yes, but hardly in pratices. No sane court would claim that, not even, would I dare say, the one of Judge Kaplan of DeCSS fame. Of course Microsoft (I can't remember the link but search on Slashdot) do claim it in their FUD campaign against the GPL but that doesn't make it true. Whether the GPL:ed is designed to be a "virus" or not is one thing that I will not argue for or against, but copyright law defintely isn't, so I will be quite hard for it to spread in the real world. > And someone shipping Wine binaries may not be aware that parts of > it need to be GPLed, and they will get flamed to death on Slashdot. That is a very convincing argument, yes. :-) > I mostly agree with you that the FSF stance on dynamic linking has no > basis in copyright law, but I'm not interested in providing the test > case. So if you want to use readline you can patch your local copy, > but I won't ship this in the main distribution. I was pretty sure that would be your answer.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

"Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > Alexandre, you are right that that code should be revised and duplications > must be remove. But since I'm not an expert in the win32 communications code, > I can't do it without risk to break a working code. This patch was mostly > inspired by the fact, that while USER exports 16-bit comm stuff, that stuff > is not in the USER code. Instead of doing an ugly thing exporting 16-bit comm > functions from KERNEL I decided to move the code around. Please consider the > applying of the patch as it is now. Code duplication can be removed later. No, I'm afraid it won't be fixed if it is moved to a separate file. Also the split is not going to help for dll separation anyway, since the 16-bit routines use the SERVICE_* functions that aren't exported. So if you want clean dll separation the only choice is to rewrite the 16-bit routines. Any volunteer? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > Trying to claim, even though you didn't, that Winelib is > effected is absurd since it is independent of the debugger. > Distributing the debugger with WineLib is merly an aggregation > nothing more. In theory any library that the debugger uses will also fall under the GPL. And someone shipping Wine binaries may not be aware that parts of it need to be GPLed, and they will get flamed to death on Slashdot. I mostly agree with you that the FSF stance on dynamic linking has no basis in copyright law, but I'm not interested in providing the test case. So if you want to use readline you can patch your local copy, but I won't ship this in the main distribution. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 19 Jun '01

19 Jun '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > No, it is enough that it is GPL compatible which the Wine > license is. > > But then the code can no longer be distributed under a non GPL > compatible license, while this is allowed by the Wine license. winedbg _binaries_ compiled with --enable-readline quite possibly. As far as the source code to winedbg is concerned maybe but probably not. It might depend on whether --enable-readline or --disable-readline is the default, but that remains to be tested in court, but it is not certain it matters at all. The court might quite reasonably rule that no linking to readline has taken place yet and thus no derived work can have been created and even if they hold that some sort of linking has taken place it might not consider it a derived work. In short linking, especially potential linking, do not always imply a derived work which is all that matters as far as the law is concerned. Also note that I'm not convinced that any court will hold that the GPL is different from the LGPL in any relevant way with the possible exception of in bad faith trying to circumvent the requirements by trying to be "clever". Of course it is a little unclear that you really can do unlawful circumvention of license requirements. This is a like claiming that somebody circumvented trespassing your land by moving around it. Either you trespass or you do not. Either you violate the license or you do not. The analogy is quite good even in other areas: Even if you are on somebodies land you do not nessary trespass either because of copyright like "fair use" requirements in the law of most countries. As a sidenote: In Sweden "fair use" concerning trespass is so extensive that I never heard about _any_ case concerning it. > I think the benefit of using readline in the debugger is much too > small to justify the potential license issues this would cause. Only the debugger (winedbg) links with readline => only the debugger can be effected. Trying to claim, even though you didn't, that Winelib is effected is absurd since it is independent of the debugger. Distributing the debugger with WineLib is merly an aggregation nothing more.

1 0

Re: PATCH: Move 16-bit COMM stuff to USER, where it belongs
by Alexandre Julliard 19 Jun '01

19 Jun '01

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Move 16-bit COMM stuff to USER, where it belongs. While the idea of the patch is correct, I think it would be much better to fix the huge code duplication while everything is in the same file. The 16-bit stuff should be implemented on top of the 32-bit stuff, instead of duplicating most of it. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Use the libreadline in Winedbg, if available
by Alexandre Julliard 19 Jun '01

19 Jun '01

Patrik Stridvall <ps(a)leissner.se> writes: > No, it is enough that it is GPL compatible which the Wine license is. But then the code can no longer be distributed under a non GPL compatible license, while this is allowed by the Wine license. I think the benefit of using readline in the debugger is much too small to justify the potential license issues this would cause. -- Alexandre Julliard julliard(a)winehq.com

1 0

Lost mail
by Alexandre Julliard 18 Jun '01

18 Jun '01

Folks, I have been forced to change ISPs over the week-end, and it seems the old and new ISP couldn't agree on when to do the switch, so any mail sent to me during the week-end probably got forwarded to /dev/null. Also could people who submitted a patch to wine-patches please send me a private copy? I know they are on the mailing list archive, but it makes my life a lot easier to have everything in my mail box. Thanks. -- Alexandre Julliard julliard(a)winehq.com

1 0

set_file_pointer and 64 bit file access
by Bill Medland 18 Jun '01

18 Jun '01

I see we are in the middle of converting set_file_pointer towards 64 bit file systems. Currently the code is confused as to when to change from unsigned to signed int for the low 32 bits. Should it happen in SetFilePointer before sending the request (which means we end up changing the request format) or should it happen within set_file_pointer (after changing the argument back to a signed int; this would also require work in SetFilePointer to get it to set up the request correctly). Any views? Bill

1 0

RE: Use the libreadline in Winedbg, if available
by Ove Kaaven 18 Jun '01

18 Jun '01

On Mon, 18 Jun 2001, Patrik Stridvall wrote: > A minor notice. Readline is GPL:ed (not LGPL:ed) which is not so good. > While it is without doubt legal for us to use and distribute, > it might cause trouble for other people. Not as long as it's optional (that patch even supported ./configure --without-readline, so no trouble, such people would just disable it).

1 0

RE: Use the libreadline in Winedbg, if available
by Patrik Stridvall 18 Jun '01

18 Jun '01

> On Mon, Jun 18, 2001 at 04:10:14PM +0200, Uwe Bonnes wrote: > > Hallo, > > > > at present, wine uses unconditionally a self supplied readline > > function. Appended patch tries to find out if libreadline > is available > > and uses libreadline if available. I configured with and without > > libreadline and successfully compiled winedbg on my system. > > libreadline is a static library on my system and winedbg > grew 90 kByte > > stripped and 110 kByte compiled with -g. > > You are not allowed to link readline aganst non GPL code to > my knowledge. No, it is enough that it is GPL compatible which the Wine license is. Whether we should is another matter though. Just linking it to the debugger is rather harmless IMHO though.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel