om a clean tarballz... and as i said, some apps works
fine. But nothing to do with installshield :-(
Thanks
Subject: Re: Installshield no way!
Date: Saturday 29 March 2003 11:54
From: Uwe Bonnes <[EMAIL PROTECTED]>
To: Davide Giannotti <[EMAIL PROTECTED]>
Cc: [EMAIL PRO
> "Davide" == Davide Giannotti <[EMAIL PROTECTED]> writes:
Davide> I give up, after 2 days of try.. Nothing to do with some
Davide> setups. I'm using latest wine on redhat 8.1 with glibc 2.3.1
Davide> recompiled for my processor (athlon xp).
Davide> Apps are launched with wi
Marcus Meissner wrote:
"Error Number: 0x80040706
Description: Object reference not set
Setup will now terminate."
I have seen this on and off, but I thought I fixed it.
Interestingly, under wine20020605, I am able to complete
the installation program. Thus we seem to have a regression.
Which
On Wed, Jan 22, 2003 at 01:50:36PM -0800, Dan Kegel wrote:
> Marcus Meissner wrote:
> IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
> windows to wine's system directory.
> >
> >I will add a large message suggesting that.
>
> Thanks. (I'm also looking forward to th
Marcus Meissner wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
windows to wine's system directory.
I will add a large message suggesting that.
Thanks. (I'm also looking forward to the possibility of
wine having its own stdole32.tlb soon.)
It looks like there's
Probably not, because locking is not impeleted into the server.
Note that you can do :
wine IKernel.exe
and in another terminal do :
mv IKernel.exe IKernel.exe_
> Subsequent runs of the installer produce the error "error installing
> iKernel.exe: (0x1400)"
> probably because iKernel.exe is locked,
On 22 Jan 2003, Mike Hearn wrote:
> Why not just use threads? Is there a particular advantage to using IPC
> in this instance? I'd guess that ikernel.exe is the program that does
> the installing, and the program you launch does the front end code?
It does use threads, and a lot of other things.
Ah, I meant from the perspective of the InstallShield developers rather
than how to hack around it in Wine. Well, they must have had their
reasons
On Wed, 2003-01-22 at 10:34, Greg Turner wrote:
> On Wednesday 22 January 2003 03:53 am, Mike Hearn wrote:
> > Why not just use threads? Is there a
On Wednesday 22 January 2003 03:53 am, Mike Hearn wrote:
> Why not just use threads? Is there a particular advantage to using
> IPC in this instance? I'd guess that ikernel.exe is the program that
> does the installing, and the program you launch does the front end
> code?
I don't know the full st
Why not just use threads? Is there a particular advantage to using IPC
in this instance? I'd guess that ikernel.exe is the program that does
the installing, and the program you launch does the front end code?
On Tue, 2003-01-21 at 16:48, Greg Turner wrote:
> On Tuesday 21 January 2003 04:38 am, Ma
On Tuesday 21 January 2003 04:38 am, Marcus Meissner wrote:
> On Tue, Jan 21, 2003 at 09:43:29AM +, Mike Hearn wrote:
> > Would this be fixed by the work that's being done on Wines RPC
> > implementation?
>
> This is a different implementation, when it is finished ... yes.
don't hold your brea
On Tue, Jan 21, 2003 at 04:26:28PM +0100, Sylvain Petreolle wrote:
> what are the missing functions that live in stdole2.tlb ?
> is someone trying to implement it ?
The TLB is a typelib file, which is compiled from a .IDL file.
So widl needs to generate it at one point.
Ciao, Marcus
On Tue, Jan 21, 2003 at 09:43:29AM +, Mike Hearn wrote:
> Would this be fixed by the work that's being done on Wines RPC
> implementation?
This is a different implementation, when it is finished ... yes.
The current implementation should be capable of doing that too.
> Why exactly does an in
what are the missing functions that live in stdole2.tlb ?
is someone trying to implement it ?
=
Sylvain Petreolle
[EMAIL PROTECTED]
Fight against Spam ! http://www.euro.cauce.org/en/index.html
ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___
Would this be fixed by the work that's being done on Wines RPC
implementation?
Why exactly does an installer require such complex parts of OLE anyway?
That seems like overkill for a self-extracting exe to me.
On Tue, 2003-01-21 at 03:39, Dan Kegel wrote:
> Bobby Bingham wrote:
> > IIRC, InstallSh
> "Dan" == Dan Kegel <[EMAIL PROTECTED]> writes:
Dan> Bobby Bingham wrote:
>> IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
>> windows to wine's system directory.
Dan> Yep, copying just that one file made things get a lot further!
Be sure to use builtin o
On Mon, Jan 20, 2003 at 11:12:29PM -0800, Dan Kegel wrote:
> Dan Kegel wrote:
> >Bobby Bingham wrote:
> >
> >>IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
> >>windows to wine's system directory.
I will add a large message suggesting that.
> >Yep, copying just that one fi
Dan Kegel wrote:
Bobby Bingham wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
windows to wine's system directory.
Yep, copying just that one file made things get a lot further!
After futzing around for half an hour, I finally convinced our
app to install. There a
doesnt seem to work happily if you use it with wcmd...
--- Duane Clark <[EMAIL PROTECTED]> a écrit : > Dan Kegel wrote:
> > ...
> > Copying and pasting from the wine debugger window
> > is beyond me; it seems totally broken...
>
> In ~/.wine/user.reg, look for the [Software\\Wine\\WineDbg] key an
Dan Kegel wrote:
...
Copying and pasting from the wine debugger window
is beyond me; it seems totally broken...
In ~/.wine/user.reg, look for the [Software\\Wine\\WineDbg] key and
change "UseXTerm"=dword: (yes, zero is true for some reason).
Then in ~/.wine/system.reg, look for [Softwa
Bobby Bingham wrote:
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
windows to wine's system directory.
Yep, copying just that one file made things get a lot further!
After futzing around for half an hour, I finally convinced our
app to install. There appear to be a lot o
IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real
windows to wine's system directory. maybe stdole.tlb and stdole2.tlb
too, but i don't know if they're needed or not, i just copy them just
in case.
Bobby Bingham
On Monday 20 January 2003 9:53 pm, Dan Kegel wrote:
> So, how's
> "Jeff" == Jeff Smith <[EMAIL PROTECTED]> writes:
Jeff> Trying to install the Music Ace Demo (harmonicvision.com), I get
Jeff> stopped by a messagethat "The InstallShield Engine (iKernel.exe)
Jeff> could not be installed. (0x20)"
Jeff> I think someone said DCOM98 needs to be
> On Fri, 21 Dec 2001, Patrik Stridvall wrote:
> [...]
> > > > However, just because it doesn't combine to something normal
> > > > doesn't mean that is doesn't combine.
> > >
> > >And how does it combine exactly? Both the book and the
> critic are
> > > available independently.
> > >
> > >
On Fri, 21 Dec 2001, Patrik Stridvall wrote:
[...]
> > > However, just because it doesn't combine to something normal
> > > doesn't mean that is doesn't combine.
> >
> >And how does it combine exactly? Both the book and the critic are
> > available independently.
> >
> > You can still read t
Ah yes, Mister Slade from the 'QuakeLives' project... Oddly enough, none
of us have heard a thing from him since.
Basically he was in very hot water for not releasing the source - and his
attempts to circumvent the GPL by pretending the patches he was
distributing were closed-source failed... aft
> On Fri, 21 Dec 2001, Patrik Stridvall wrote:
>
> > There are many thing that are important in the world not just one,
> > so it was just a reaction of your persistance that the spirit of
> > something is the only thing that matters.
>
> I focused on the spirit to put some sense in the discussi
On Fri, 21 Dec 2001, Patrik Stridvall wrote:
> There are many thing that are important in the world not just one,
> so it was just a reaction of your persistance that the spirit of
> something is the only thing that matters.
I focused on the spirit to put some sense in the discussion, go get to
On Fri, 21 Dec 2001, Patrik Stridvall wrote:
> > In fact, choosing the LGPL is a very nice way of hedging our
> > bets agains
> > future changes in copyright law. And this is so because of
> > the negative
> > feedback loop that the LGPL introduces agains the copyright
> > law. Brilliant.
>
>
> On Thu, 20 Dec 2001, Patrik Stridvall wrote:
>
> > Does it nessararily follow that you wish to accept any means to
> > achieve this? Including, say, to be really extreme:
> > "Nuke the middle east, then it will be peace there"
> > and after enough nukes it probably WILL be peace,
> > so it woul
> On Thu, 20 Dec 2001, Patrik Stridvall wrote:
>
> > No, its not irrelevant because it will effect the advise the company
> > lawyers give their clients.
>
> But know you are inconsistent with yourself. You've been
> claiming that it
> is the very spirit of the LGPL that would scare companies
> On Fri, 21 Dec 2001, Patrik Stridvall wrote:
> [...]
> > > - a critic's book about the original is not a derived piece
> > > of work. It
> > > is clearly specific to the original book but does not
> modify it and
> > > clearly does not combine with it to form a single piece of work.
> > >
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
> Does it nessararily follow that you wish to accept any means to
> achieve this? Including, say, to be really extreme:
> "Nuke the middle east, then it will be peace there"
> and after enough nukes it probably WILL be peace,
> so it would be entire in
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
> No, its not irrelevant because it will effect the advise the company
> lawyers give their clients.
But know you are inconsistent with yourself. You've been claiming that it
is the very spirit of the LGPL that would scare companies away, and I can
se
On Thu, 20 Dec 2001, Gavriels State wrote:
> Francois Gouget wrote:
> >I see exactly what you mean. You mean a binary patch that says
> > things like:
> > * delete bytes 2294 to 2297
> > * replace bytes 38455 to 39345 with ""
> > * insert "" at offset 41753
> >
> >Such a patch
Francois Gouget wrote:
>I see exactly what you mean. You mean a binary patch that says
> things like:
> * delete bytes 2294 to 2297
> * replace bytes 38455 to 39345 with ""
> * insert "" at offset 41753
>
>Such a patch is very specific to a given source version but does not
> i
On Fri, 21 Dec 2001, Patrik Stridvall wrote:
[...]
> > - a critic's book about the original is not a derived piece
> > of work. It
> > is clearly specific to the original book but does not modify it and
> > clearly does not combine with it to form a single piece of work.
> >(no real equivale
> > You forgot that the end user still need to legally get hold of
> > the work somehow. For normal commercial stuff this involves
> > paying for it and the author will get payed just like he did in
> > the old non-digital world for _each_ copy.
>
>I did not forget that.
Good because this is
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
[...]
> >Well, if you can legally use such a patch to work-around the LGPL
> > license, then you can use it to get past *any* license: GPL, AFPL, MS
> > shared-source, whatever. And this is not only true of
> > source files,
> > this is also t
>I see exactly what you mean. You mean a binary patch that says
> things like:
> * delete bytes 2294 to 2297
> * replace bytes 38455 to 39345 with ""
> * insert "" at offset 41753
Yes.
>Such a patch is very specific to a given source version
> but does not
> include any of t
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
> > Patrik Stridvall <[EMAIL PROTECTED]> writes:
> >
> > > But why should I do that?
> > > I can for example write a script that download Wine for the
> > end user user
> > > and apply the patch automatically.
> >
> > The patch would be considered a
> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > But why should I do that?
> > I can for example write a script that download Wine for the
> end user user
> > and apply the patch automatically.
>
> The patch would be considered a derivative work, so distributing it
> would also violate the
> On Thu, 20 Dec 2001, Patrik Stridvall wrote:
>
> > Sure it is true that what people (read: companies) believe
> is true is
> > more important than what really is true.
>
> So, in fact, you indirctly agree that arguing about the doctrine of
> derived work as part of this discussion is irreleva
Patrik Stridvall <[EMAIL PROTECTED]> writes:
> But why should I do that?
> I can for example write a script that download Wine for the end user user
> and apply the patch automatically.
The patch would be considered a derivative work, so distributing it
would also violate the LGPL.
> It is not
On Thu, 20 Dec 2001, Patrik Stridvall wrote:
> Sure it is true that what people (read: companies) believe is true is
> more important than what really is true.
So, in fact, you indirctly agree that arguing about the doctrine of
derived work as part of this discussion is irrelevant.
All you seem
> But, I hear you say, 'why change the license if it doesn't
> give you any
> protection?' Well, this is where your reasoning is flawed, because the
> LGPL gives you quite a bit of protection. And this is because
> there is at
> least a 50% chance that it is enforceable, and this is
> _good_eno
> David Elliott <[EMAIL PROTECTED]> writes:
>
> > Okay, that makes a bit more sense. Although couldn't one argue that
> > it still does work since it could fall back to the original LGPL
> > createwindow?
>
> Sure, if this is the case it's OK. You can perfectly provide a
> user32_better library
> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > So almost all functions would look like
> > void CryptFoo()
> > {
> > #if HAVE_LIBCRYPTO32
> > CRYPT32_CryptFoo();
> > #else
> > /* Old Wine code */
> > #endif
> > }
> >
> > with a few minor exception.
> >
> > So you mean that I ca
On Wed, 19 Dec 2001 22:45:43 -0500, "Dimitrie O. Paun"
<[EMAIL PROTECTED]> wrote:
>On Wed, 19 Dec 2001, Patrik Stridvall wrote:
>
>> They had a goal and I'm sure a lot of competent people did the best
>> they could be accieve it.
>>
>> However, you can do the impossible no matter how hard you tr
On Wed, 19 Dec 2001, Patrik Stridvall wrote:
> They had a goal and I'm sure a lot of competent people did the best
> they could be accieve it.
>
> However, you can do the impossible no matter how hard you try.
And this is precisely why your entire dissertation about the derived work
doctrine i
Patrik Stridvall <[EMAIL PROTECTED]> writes:
> So almost all functions would look like
> void CryptFoo()
> {
> #if HAVE_LIBCRYPTO32
> CRYPT32_CryptFoo();
> #else
> /* Old Wine code */
> #endif
> }
>
> with a few minor exception.
>
> So you mean that I can't legally do that despite
David Elliott <[EMAIL PROTECTED]> writes:
> Okay, that makes a bit more sense. Although couldn't one argue that
> it still does work since it could fall back to the original LGPL
> createwindow?
Sure, if this is the case it's OK. You can perfectly provide a
user32_better library that implements
On 2001.12.19 12:32 Alexandre Julliard wrote:
> David Elliott <[EMAIL PROTECTED]> writes:
>
> > Now, here's another something to mull over. We've pretty much
> > established that you could statically link something proprietary with
> > something LGPL. One question I have is how much of the libr
> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > For example:
> > void CryptFoo()
> > {
> > CRYPT32_CryptFoo();
> > }
> >
> > and release the code above under the LGPL.
>
> That's the square root example. If you do that, you have to make sure
> that the use of CRYPT32_CryptFoo is option
On 2001.12.19 12:22 Patrik Stridvall wrote:
[SNIP]
> > That is my argument that avoids all of
> > Patrick's doctrine
> > of derived work crap and gets right down to the fact that
> > it's trivially
> > easy to make your work fall under the work that uses the
> > library category,
> > so long as it
On 2001.12.19 11:43 Dan Kegel wrote:
[BIG SNIP]
> Thanks for explaining what Patrik has been going on about.
> In summary:
>
> Consider a proprietary application which ships as a proprietary library
> which is statically linked with LGPL libraries at install time in a way
> that lets users supply
Patrik Stridvall <[EMAIL PROTECTED]> writes:
> For example:
> void CryptFoo()
> {
> CRYPT32_CryptFoo();
> }
>
> and release the code above under the LGPL.
That's the square root example. If you do that, you have to make sure
that the use of CRYPT32_CryptFoo is optional and that the functi
> Patrik Stridvall <[EMAIL PROTECTED]> writes:
>
> > So what you basicly saying is that a Crypto API that is a
> part of ADVAPI32
> > can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can.
> >
> > Isn't that quite an absurd state to make? Or rather the
> perfect illustration
> > o
Alexandre Julliard wrote:
> You known, no matter how much you may disagree with the FSF or their
> license, they are not a bunch of idiots. They have been through this
> long before you, and have spent a lot of time (and lawyers) to make
> sure that it worked as they wanted.
Exactly. They WANT
Hi, I'm following this list for a while, and even if I still haven't
found time to devote to the project itself, I've seen few things in this
thread that I would like to comment on.
Please note that I will be referring to the 2.1 version of the LGPL.
Il mer, 2001-12-19 alle 07:41, David Elli
Patrik Stridvall <[EMAIL PROTECTED]> writes:
> So what you basicly saying is that a Crypto API that is a part of ADVAPI32
> can't call ADVAPI32 functions but a Crypto API in say CRYTPO32 can.
>
> Isn't that quite an absurd state to make? Or rather the perfect illustration
> of the absurdities of
> David Elliott <[EMAIL PROTECTED]> writes:
>
> > Now, here's another something to mull over. We've pretty much
> > established that you could statically link something
> proprietary with
> > something LGPL. One question I have is how much of the library are
> > you allowed to use. Alexandre
[David Elliott explaination snipped]
> Thanks for explaining what Patrik has been going on about.
Yes, it was quite a good explaination.
However...
> In summary:
>
> Consider a proprietary application which ships as a
> proprietary library
> which is statically linked with LGPL libraries at
David Elliott <[EMAIL PROTECTED]> writes:
> Now, here's another something to mull over. We've pretty much
> established that you could statically link something proprietary with
> something LGPL. One question I have is how much of the library are
> you allowed to use. Alexandre mentioned that
> Now, here's another something to mull over. We've pretty
> much established
> that you could statically link something proprietary with
> something LGPL.
> One question I have is how much of the library are you
> allowed to use.
> Alexandre mentioned that while the CryptoAPI example wou
Roger Fujii wrote:
> It *appears* like a process to the user in the ui (ps has separate PIDs).
> The problem is that words like "process" and "linking" really require some
> context around them and it's hard to codify that in a document.
Yes.
> > Perhaps it would be clearer if I said 'address sp
Dan Kegel wrote:
> Roger Fujii wrote:
> > > If they are in separate files, and one calls the other via a function call
> > > that crosses process boundaries (i.e. uses a remote procedure call protocol),
> > > there is no linking, at least not by current standards (and I bet this
> > > will not cha
David Elliott wrote:
> Dimitrie, this is exactly what Patrick and I have been trying to argue
> against. If you read the LGPL it does state that you can statically link
> as long as you provide the means for your users to statically link with a
> newer version. One way to do this would be to pro
Roger Fujii wrote:
> > If they are in separate files, and one calls the other via a function call
> > that crosses process boundaries (i.e. uses a remote procedure call protocol),
> > there is no linking, at least not by current standards (and I bet this
> > will not change).
>
> so, given that l
> On Tue, 18 Dec 2001, Patrik Stridvall wrote:
>
> > The problem is the doctrine of derived works. Nothing else.
>
> And to you truly believe that our choice for Wine's license
> will have any
> influence over the doctrine of derived works?
Of course not. But it _will_ effect our abillity to
> On Tue, 18 Dec 2001, Patrik Stridvall wrote:
>
> > I'm against the fact that the GPL or to a smaller extent LGPL
> > tries use the doctrine of derived work as a weapon to achieve
> > their goals. It is a very dangerous weapon, since if the courts
> > or the policitians decide that a strong doct
> On Tue, 18 Dec 2001, Patrik Stridvall wrote:
>
> > > Note that I said "_small_ improvements" because of the
> > > modular nature of Wine. If the improvements are big, the DLL
> > > separation would allow them to keep those changes proprietary.
> >
> > I don't think small improvements is a pro
> On Tue, 18 Dec 2001, Patrik Stridvall wrote:
>
> > You forget that some "independent"(*) parts like the Crypto API are
> > parts of other DLL:s (like ADVAPI32.DLL) for no particular reason.
>
> This is ridiculous: it is one of the few exceptions, it is
> simply silly to
> bring the Crypto API
> On 2001.12.18 05:09 Patrik Stridvall wrote:
> [snip]
> > Dimitrie O. Paun wrote:
> > > Stop for a movement and tell me: are you against the letter
> > > or the spirit
> > > of the LGPL.
> >
> > Asking that question is like asking whether I support the spirit of
> > Communism:
> > "From each acc
Dan Kegel wrote:
> Patrik Stridvall wrote:
> > > Which is my response to Rogers comment above - sure the GPL
> > > prohibits linking with a nonfree component.
> >
> > Yes, but what is linking?
> >
> > Don't you understand it is the vagueness of linking that is the problem.
>
> I don't think it's
Patrik Stridvall wrote:
> > Which is my response to Rogers comment above - sure the GPL
> > prohibits linking with a nonfree component.
>
> Yes, but what is linking?
>
> Don't you understand it is the vagueness of linking that is the problem.
I don't think it's vague. We can define it quite we
Alexandre Julliard wrote:
> > We do have a bit of merge work pending for non-3D components, which
> > we hope to get to soon. The delays there have nothing to do with
> > licensing issues though - they're more about development process and
> > CVS policy.
>
> It may be a good idea for yo
On 2001.12.18 23:43 Dimitrie O. Paun wrote:
> On Tue, 18 Dec 2001, Roger Fujii wrote:
>
> > "Dimitrie O. Paun" wrote:
> >
> > > Technicalities aside, the LGPL spirit seems to be accepted by most
> people.
> >
> > I have no problems with the 'spirit' of the GPL (or at least, how most
> > (ie, minu
On Tue, 18 Dec 2001, Roger Fujii wrote:
> lee wrote:
> >
> > > > At this point, I would like to know if people agree up to this point.
> > >
> > > Try reading section 2C of the LGPL and tell me how it's good for commercial
> > > companies.
> > > If LGPL is so clean, simple and nice, why does moz
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
> The problem is the doctrine of derived works. Nothing else.
And to you truly believe that our choice for Wine's license will have any
influence over the doctrine of derived works? If not, there really is no
point in discussing this any further. If y
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
> I'm against the fact that the GPL or to a smaller extent LGPL
> tries use the doctrine of derived work as a weapon to achieve
> their goals. It is a very dangerous weapon, since if the courts
> or the policitians decide that a strong doctrine of deri
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
> > Note that I said "_small_ improvements" because of the
> > modular nature of Wine. If the improvements are big, the DLL
> > separation would allow them to keep those changes proprietary.
>
> I don't think small improvements is a problem anyway an
On Tue, 18 Dec 2001, Roger Fujii wrote:
> "Dimitrie O. Paun" wrote:
>
> > Technicalities aside, the LGPL spirit seems to be accepted by most people.
>
> I have no problems with the 'spirit' of the GPL (or at least, how most
> (ie, minus rms) people sees it).
Excellent. In fact, I disagree with
On Tue, 18 Dec 2001, Patrik Stridvall wrote:
> You forget that some "independent"(*) parts like the Crypto API are
> parts of other DLL:s (like ADVAPI32.DLL) for no particular reason.
This is ridiculous: it is one of the few exceptions, it is simply silly to
bring the Crypto API into this discus
On 2001.12.18 06:13 Geoff Thorpe wrote:
[BIG SNIP]
> The rest of the suggestion I would like to make may seem somewhat
> surprising; dual license this BSD+adv-clause with the GPL. Not LGPL, but
> GPL. GPL is an enormous hunk of trouble I know, but under a dual license
> you're only bound by it if
On 2001.12.18 05:09 Patrik Stridvall wrote:
[snip]
> Dimitrie O. Paun wrote:
> > Stop for a movement and tell me: are you against the letter
> > or the spirit
> > of the LGPL.
>
> Asking that question is like asking whether I support the spirit of
> Communism:
> "From each according to his abilit
Gavriels State <[EMAIL PROTECTED]> writes:
> We do have a bit of merge work pending for non-3D components, which
> we hope to get to soon. The delays there have nothing to do with
> licensing issues though - they're more about development process and
> CVS policy.
It may be a good idea
lee wrote:
>
> > > At this point, I would like to know if people agree up to this point.
> >
> > Try reading section 2C of the LGPL and tell me how it's good for commercial
> > companies.
> > If LGPL is so clean, simple and nice, why does mozilla/openoffice/apache/perl
> > not use it?
> it would
> Patrik Stridvall wrote:
> >
> > > Patrik,
> > >
> > > The more I read your posts, the less I understand what you
> > > are trying to say. You argued over many hundreds of lines
> > > over weird technical details and various dubious assumptions
> > > about what courts will do in the future.
> >
> > At this point, I would like to know if people agree up to this point.
>
> Try reading section 2C of the LGPL and tell me how it's good for commercial
> companies.
> If LGPL is so clean, simple and nice, why does mozilla/openoffice/apache/perl
> not use it?
>
it would appear thats changing and
> >> MS Word (to use an example) might have to dynamically link in
> >> a special MS Word component to process specifics in my
> >> document, it doesn't mean my document is "linked" with the
> >> MS Word component does it?
> >
> > Ah, you are beginning to see the problem. :-)
>
> What problem? A
> > The main point is that what is legal allow is very unclear.
>
> Hogwash. I feel the LGPL is extremely clear. It allows
> you to dynamically link to LGPL code without worries. Full stop.
You want to see a really clear license and short one? look at MS
shared-source license. Only 1 page and
Patrik Stridvall wrote:
>
> > Patrik,
> >
> > The more I read your posts, the less I understand what you
> > are trying to say. You argued over many hundreds of lines
> > over weird technical details and various dubious assumptions
> > about what courts will do in the future.
>
> The main point
> > But most apps wine will run *cannot* use a GPLed component. GPL
> > expressly forbids being linked to a nonGPLed component.
> *GPL does not
> > only cover the source, but rather the USE of the components
> as well.
> > Read the
> > license. It's quite an eye opener.
>
> I'd argue (thoug
On Wednesday 19 December 2001 00:34, Roger Fujii wrote:
> Geoff Thorpe wrote:
> > However, if I might wax extreme for a moment, my out-there suggestion
> > would be to stick with a BSD style license but to put an advertising
> > clause *in*.
>
> The problem with this is that it would make it incom
Geoff Thorpe wrote:
> However, if I might wax extreme for a moment, my out-there suggestion would
> be to stick with a BSD style license but to put an advertising clause *in*.
The problem with this is that it would make it incompatible with *GPLed
components as an ad clause conflicts with an Ope
Hi there,
I have been watching this thread quietly for some time now but I feel I
should probably put my opinion forward ... now or never. Warning - it's
longish and covers a few things that might be considered a little bit "left
field".
I have worked at more than one company in the capacity
> Did anybody mention that if wine moved to an LGPL license, we would be
> able to borrow code from a wider variety of other projects?
>
> That would include KDE, libXML, Bochs, OpenOffice, GTK+, Atheos, jCIFS
> and any other LGPL (or compatable) projects.
Sure, but I would much rather use them
> On Mon, 17 Dec 2001, Patrik Stridvall wrote:
>
> > > This has been my argument against Patrick exactly. Some
> > > protection is better than none at all.
> >
> > As a general rule, yes.
> >
> > However this time the protection comes with a price.
>
> And what might that price be? You fear
> Patrik,
>
> The more I read your posts, the less I understand what you
> are trying to
> say. You argued over many hundreds of lines over weird
> technical details
> and various dubious assumptions about what courts will do in
> the future.
The main point is that what is legal allow is very
1 - 100 of 211 matches
Mail list logo
