RE: Installshield 6 (inter-proc) patches
Alexandre Julliard wrote:
Gavriel State <gav(a)transgaming.com> writes:
There are several factors to that equation, and I'm
afraid we don't have
a firm ETA yet.
Well, this worries me. It sounds like you are planning to do the same thing you did with your DirectX stuff: by making the code available on your site, and promising to release it at some hypothetical future date, you remove all incentive for other people to spend time improving the main Wine, thus ensuring that it always lacks some features. I don't like this at all.
If you can't/don't want to release your code, I'd strongly suggest that you reconsider your strategy of making it publicly available. If it was only available to paying customers, there would at least be a reason for other people to work on a free implementation. But if everybody who needs some feature in Wine can simply download WineX instead, no one will spend time re-implementing that feature. This is beginning to seriously hurt the project, and we need to find a way to address this issue.
The DCOM issues had been ignored by other Wine developers for YEARS before we came along.
Yes, but that is because it hasn't been needed for anything but obscure application until now.
It's not at all clear that our work there has discouraged anyone else from working in that area.
Granted.
To say that our work is preventing anyone from doing a free version of DCOM is completely incorrect. To the contrary: we have already contributed substantial amounts of this code to the public tree - thousands of lines, in fact. That can only help anyone with a sudden and unexpected interest in recreating our work.
That is absolutly true and would make any decision not to release it under a free license even more strange. Note however that I'm not accusing you of not releasing it. Not yet, but I reserve the right to do so in the future. Anyway, see below.
Now, it is our firm desire to see *all* of that code end up in the main version of Wine. The fact is, unfortunately, that we simply cannot afford to give everything away as soon as we write it. We only got a minimal implementation of the DCOM code working six weeks ago. We are not a rich company, with millions in VC funding to burn; this means that our DCOM work has to remain under the AFPL until we can find a sponsor willing to defray some of the tens of thousands of dollars it cost us to develop it.
I think that you look a things the wrong way. Think of the expense as an extra cost you pay for being early to the market. Sure it won't make your accountant much happier but thats life. :-) What I mean by that is that the DCOM code aiming to get InstallShield to work is not really something that has very much to do with the product you that your customers want to buy. Installation is done only once and can be made in the real Windows if you dual boat and beside it is really something that Wine should have supported already. In short, it was something you had to do because Wine was not mature, because you wanted to be early to market and holding it as proprietary code are unlikely to give you any advantage for very long. If you won't release it somebody else will implement it before long.
Furthermore, we are committed to writing quality, robust code. We don't think it's in anyone's best interest for the current version of the code, which is effectively limited to the requirements of InstallShield, to be used as the basis of future DCOM related work. We in the midsts of working on a much more flexible architecture which will permit more than just typelib based proxying.
I don't really think this affects individual users at all. They can simply download and use the code from our website, or apply the necessary patch to WineHQ wine. They can even redistribute it all non-commercially should they wish.
Without a doubt, we are committed to the Wine project and have already contributed a great deal of code to support it. However, to maintain the quality and integrity of the project, we stand by our decision of only contributing code when it makes sense to do so (in order to allow us to continue developing quality code) and when it reaches a certain minimal degree of quality.
Yes, I fully understand that, I'm grateful for all you have done and I'm not making any accusations right now. However I reserve the right to do so in the future.
Publicly questioning our ethics is certainly not the right solution nor is it in the spirit of the project, especially given how much we have supported it to-date. We believe that we ARE doing the Wine user and developer community a service and propelling it further.
I don't think Alexandre is questioning your ethics. I think he is question what relation the Wine project should have with you based on praticial issues and not on ethical issues at all. In short: Should the Wine project wait until you release or should it not?
The only people that our lack of haste in contributing code back really affects are organizations that want to make immediate commercial use of the code. These organizations include the one you work for, and its clients. If you want to see the DCOM code Wine-licensed soon, you need to talk to your boss and your clients, not me.
:-) I fully understand that you wish to take every opportunity to get some extra income but I think your analysis is partly wrong. Sure it is possible you might get some sort of one time payment from somebody if you are a little clever, but realize the following. A significant part of your potential customers consists of, I guess, people who would very much like to not to dual boot any longer and their first priority is that their normal productivity applications installs and works. Games are their second priority and so as long InstallShield doesn't work in normal Wine you risk losing them since they will continue to dual boot and presumably continue to play their games in Windows.
At this point, I think it would be best if we were to take this discussion off-line so that we can determine a solution that works for everyone.
For any discussion concerning milking some money out of CodeWeavers or their clients, absolutely. Not my problem. :-) However one important problem that really can't be discussed off-line, is what your relation you wish to have to the Wine project. In fact, it can't be discussed at all, only your actions can determine it. I will be blunt: Do you see yourselves as a complement to Wine or a competitor to Wine? Because not releasing important core code like code needed to install important applications especially non-games might be interpreted as really wish to compete with Wine instead of being a completement. Note again (the third(?) time) that I'm not accusing you of anything, at least not yet, but I wish to point out that it might hurt your public image if people see as a competitor instead of a complement to Wine. Being vague and saying: "There are several factors to that equation, and I'm afraid we don't have a firm ETA yet." will not help your image.
Patrik Stridvall <ps(a)leissner.se> writes:
In short: Should the Wine project wait until you release or should it not?
That's certainly a question we have to think about, but I think there is a deeper issue: should we continue to release under a license that allows people to use our own code to hurt the project? My concern is not so much about Transgaming, I trust that Gav means to do the right thing, even if I don't entirely agree with his methods. But I'm worried that if Transgaming succeeds, it will set a precedent that others will follow, who may have no desire at all to do the right thing for Wine. What will happen if 5 different dlls are improved and released by 5 different companies under 5 different non-free licenses? -- Alexandre Julliard julliard(a)winehq.com
On Thu, Dec 13, 2001 at 09:41:56AM -0800, Alexandre Julliard wrote:
Patrik Stridvall <ps(a)leissner.se> writes:
In short: Should the Wine project wait until you release or should it not?
That's certainly a question we have to think about, but I think there is a deeper issue: should we continue to release under a license that allows people to use our own code to hurt the project?
Actually this was our original idea of using the BSD license as far as I remember, making it possible for companies to take the code and do things they want with it. This was taking into account they kept it for themselves so not hurting our own incentive to do program missing things. It appears that we did not consider someone else releasing it under a pseudo OpenSource license. (pseudo as in one-way free migration of sourcecode). Probably a license change to the LGPL would be a choice. Companies can do their own seperate additions (like a complete DirectX replacement), but can't just 'fix' library parts and keep those changes for themselves. Hmm, I don't really know. I wouldn't mind changing my code to LGPL though. Ciao, Marcus
"Alexandre Julliard" <julliard(a)winehq.com> wrote in message news:874rmvggpn.fsf(a)mail.wine.dyndns.org...
Patrik Stridvall <ps(a)leissner.se> writes:
In short: Should the Wine project wait until you release or should it not?
That's certainly a question we have to think about, but I think there is a deeper issue: should we continue to release under a license that allows people to use our own code to hurt the project?
My concern is not so much about Transgaming, I trust that Gav means to do the right thing, even if I don't entirely agree with his methods. But I'm worried that if Transgaming succeeds, it will set a precedent that others will follow, who may have no desire at all to do the right thing for Wine. What will happen if 5 different dlls are improved and released by 5 different companies under 5 different non-free licenses?
It's been quite fascinating watching this discussion; it's nice to see that such issues are covered. It raises two issues for me: 1. Where does Lindows fit into all this? Does anyone know what's happening there? 2. Is the current wine license as loose as it appears to me? My understanding is that "the license" is the file "LICENSE" at the root of the cvs tree and basically allows anyone to do anything with it provided they keep the license in there (and respect copyright). I keep seeing quotes and things that suggest wine is under GPL, LGPL, BSD etc.; I presume that they are simple ill-informed. Bill
I probably am going to regret starting this conversation, but luckly I havn't seen any of the traditional flame-war mentality sneaking in yet. My 5c: I -have- had to deal with companies stealing my GPL code and releasing it in on-the-shelf commercial products. The GPL protected my rights very well when said companies were confonted. The GPL is only weak in that most people using the GPL do not have resources to enforce it. If it came to that (which I doubt it will, as the GPL does have a large part in the fact it discourages being stolen... for the PR points if nothing else!) I'm sure the WINE project could find the ability to enforce it. Meanwhile, I do agree that changing the fundemental wine license for libraries to LGPL is a good thing. Legally, wine is entitled to do so. Anybody submitting code back to wine has done so under the modified BSD license, from modified versions of code originally copyrighted to Wine, thusly transfering licence rights back to the original owner under a GPL-compatable license. The LGPL will protect WINEs fundemental core. Naturally, Transgaming currently use a BSD licensed version, and may continue to do so. If they wish to import any new modifications from a LGPL'ed wine however - they must accept the new licence on the library they are importing code to/from. If Transgaming, or a third party, develop a whole new library from scratch, which is a .so or other dynamically loaded library, the LGPL allows them to do so with no repocusion. It's all-in-all a win/win situation. Transgaming can protect their IP, and Wine can protect poaching of their code from other sources for things which do not benefit the wine core. Let's look at the legality.. the clause below protects a large portion of the objections most people may have with WINE becoming LGPL'ed: d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. This protects many operations of WINEs functionality. In good faith, we have tried to provide alternate functionality to allow the program to operate without the presence of external files. In the case of embedded systems, there are many libdl replacements out there. I know not of a single embedded system that wine could EVER feasibly run on that doesn't include some way of getting dynamic linking capability. As another issue, Lindows can simply be considered another distribution. Fundementally it uses Linux, Wine and other free software (under GPL, LGPL and BSD licences). They have already stated they will respect the respective licenses, and open source to the components of thier code that IS under a license requiring such. Thus there is no conflict. Regards, | Any significantly advanced technology is indistinguishable from | a perl script. Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Thu, 13 Dec 2001, Bill Medland wrote:
Date: Thu, 13 Dec 2001 14:51:51 -0800 From: Bill Medland <medbi01_1(a)accpac.com> To: wine-devel(a)winehq.com Subject: Re: Installshield 6 (inter-proc) patches
"Alexandre Julliard" <julliard(a)winehq.com> wrote in message news:874rmvggpn.fsf(a)mail.wine.dyndns.org...
Patrik Stridvall <ps(a)leissner.se> writes:
In short: Should the Wine project wait until you release or should it not?
That's certainly a question we have to think about, but I think there is a deeper issue: should we continue to release under a license that allows people to use our own code to hurt the project?
My concern is not so much about Transgaming, I trust that Gav means to do the right thing, even if I don't entirely agree with his methods. But I'm worried that if Transgaming succeeds, it will set a precedent that others will follow, who may have no desire at all to do the right thing for Wine. What will happen if 5 different dlls are improved and released by 5 different companies under 5 different non-free licenses?
It's been quite fascinating watching this discussion; it's nice to see that such issues are covered. It raises two issues for me: 1. Where does Lindows fit into all this? Does anyone know what's happening there? 2. Is the current wine license as loose as it appears to me? My understanding is that "the license" is the file "LICENSE" at the root of the cvs tree and basically allows anyone to do anything with it provided they keep the license in there (and respect copyright). I keep seeing quotes and things that suggest wine is under GPL, LGPL, BSD etc.; I presume that they are simple ill-informed.
Bill
On 2001.12.13 12:41 Alexandre Julliard wrote:
Patrik Stridvall <ps(a)leissner.se> writes:
In short: Should the Wine project wait until you release or should it not?
That's certainly a question we have to think about, but I think there is a deeper issue: should we continue to release under a license that allows people to use our own code to hurt the project?
Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it. LGPL would have been ideal except several people pointed out that because it disallows static linking it would be unsuitable for systems without a dynamic linker (e.g. embedded systems). In hindsight maybe we should have gone with LGPL with exceptions to allow static linking like some other projects have recently done. Although I remember something about if you are going to allow static linking you might as well allow people to do what they will with the code because if you can statically link it you pretty much can do what you will with the code.
My concern is not so much about Transgaming, I trust that Gav means to do the right thing, even if I don't entirely agree with his methods. But I'm worried that if Transgaming succeeds, it will set a precedent that others will follow, who may have no desire at all to do the right thing for Wine. What will happen if 5 different dlls are improved and released by 5 different companies under 5 different non-free licenses?
This is so true. Of course now that the cat is out of the bag maybe a more pertinent question is what happens if we make new code LGPL or some such? Do we still have companies using Wine code but using the older versions under the X11 license? Then we'd really have a mess. Would dual-licensing under LGPL and original BSD make sense? That way other open source projects could use the code, but closed source projects would have to put in advertising for Wine. Of course really, what is the difference. Is anyone going to care that e.g. Lindows uses Wine. Honestly I don't know what to say. On the one hand you have the FSF licenses geared towards promoting free software development. On the other hand you have the current license geared towards allowing everyone to use the code for whatever. Wine is a reimplementation of an existing API. Do we really want to send the message that in order to use the wine code your program must be free software? Or would we rather stick with the current situation that we'd rather have you using our code than Microsoft's? I cannot come up with a reasonable choice here. Either way has drawbacks. We've been through this before and went with the X11 license. Maybe it's time to rethink that decision... maybe not. All I can say is that I for one would like to know how current developers stand on this issue. Has anyone's thoughts/opinions changed significantly? -Dave
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 13 December 2001 18:44, David Elliott wrote:
Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it.
LGPL would have been ideal except several people pointed out that because it disallows static linking it would be unsuitable for systems without a dynamic linker (e.g. embedded systems).
I think it's worth pointing out that the LGPL doesn't force you to distribute shared libraries. You can statically link your own work with a library covered by the LGPL, as long as you provide object code (or source) of your work, allowing a user to relink the LGPL library with your work. You must also allow modifications to your work, and reverse engineering for debugging the modifications. That, at least, is my reading of the license. Ori Pessach -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.oripessach.com iD8DBQE8GV6szA/uWWyw6uQRAu2qAKCXXwAAKNMtX1zO92v4AkfcgyYNtQCcCoDH p0DmKvx6EJDymKADuO5/HsE= =CXt9 -----END PGP SIGNATURE----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
On 2001.12.13 21:06 Ori Pessach wrote:
On Thursday 13 December 2001 18:44, David Elliott wrote:
Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it.
LGPL would have been ideal except several people pointed out that because it disallows static linking it would be unsuitable for systems without a dynamic linker (e.g. embedded systems).
I think it's worth pointing out that the LGPL doesn't force you to distribute shared libraries. You can statically link your own work with a library covered by the LGPL, as long as you provide object code (or source) of your work, allowing a user to relink the LGPL library with your work.
Hmm... I remember the LGPL stating that the end-user must be able to relink the application with a newer version of the library. For some reason I also thought it stipulated that in order to achieve that it must be dynamically linked. Although you are correct from a technical standpoint that someone could distribute an object file that is the app minus the LPGL part which would then allow one to relink with a modified version of the LPGL part. Okay, I just read the license and you are indeed correct. So that pretty much gets rid of the argument that the LGPL is unsuited for embedded systems because of the need to statically link sometimes.
You must also allow modifications to your work, and reverse engineering for debugging the modifications.
Hmm, in other words no EULA clauses stating you can't modify or reverse engineer the binary. I think that is a very acceptable stipulation.
That, at least, is my reading of the license.
Ori Pessach
Thank you for enlightening me about the LGPL. -Dave
David Elliott <dfe(a)tgwbd.org> writes:
Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it.
The original license was pretty much the same way except for technicalities.
This is so true. Of course now that the cat is out of the bag maybe a more pertinent question is what happens if we make new code LGPL or some such? Do we still have companies using Wine code but using the older versions under the X11 license? Then we'd really have a mess.
Not really; people using Wine and who don't want to switch to the new license would simply have to avoid merging in new code. Note that if we go LGPL, each dll would be considered a separate library, so companies could choose which ones they want to merge. For instance Transgaming could freely merge into their tree any new code that doesn't touch the DirectX dlls; of course they would then have to release the dlls they merged under the LGPL, but they could still keep the DirectX ones proprietary. The license change would only take full effect in the long term, when the current versions of Wine are too obsolete to be a reasonable option for someone starting a new project.
[...] Do we really want to send the message that in order to use the wine code your program must be free software?
This would be the message if we were to use the GPL, which I think we all agree would not be really possible if we still want to be able to run proprietary applications. With the LGPL the message would be that you can use the code pretty much as you want, but if you change it you have to release the changes.
I cannot come up with a reasonable choice here. Either way has drawbacks. We've been through this before and went with the X11 license. Maybe it's time to rethink that decision... maybe not. All I can say is that I for one would like to know how current developers stand on this issue. Has anyone's thoughts/opinions changed significantly?
Mine at least yes... I used to think that proprietary versions of Wine wouldn't matter, since we already have to compete against the ultimate proprietary Wine (the one from Redmond). But I see now that there are ways to make the code kind-of-proprietary that can actually cause more harm to Wine than purely proprietary ones, and I think we should do something to address this issue. What do others think? -- Alexandre Julliard julliard(a)winehq.com
On 13 Dec 2001 19:47:42 -0800, Alexandre Julliard <julliard(a)winehq.com> wrote:
David Elliott <dfe(a)tgwbd.org> writes:
Umm, do I sense a little Deja Vu here. IIRC Wine's original license had some issues that meant it wasn't GPL compatible. The new license, which I understand is a modified BSD or an X11 license, basically says do whatever you want with it.
The original license was pretty much the same way except for technicalities.
This is so true. Of course now that the cat is out of the bag maybe a more pertinent question is what happens if we make new code LGPL or some such? Do we still have companies using Wine code but using the older versions under the X11 license? Then we'd really have a mess.
Not really; people using Wine and who don't want to switch to the new license would simply have to avoid merging in new code. Note that if we go LGPL, each dll would be considered a separate library, so companies could choose which ones they want to merge. For instance Transgaming could freely merge into their tree any new code that doesn't touch the DirectX dlls; of course they would then have to release the dlls they merged under the LGPL, but they could still keep the DirectX ones proprietary.
The license change would only take full effect in the long term, when the current versions of Wine are too obsolete to be a reasonable option for someone starting a new project.
[...] Do we really want to send the message that in order to use the wine code your program must be free software?
This would be the message if we were to use the GPL, which I think we all agree would not be really possible if we still want to be able to run proprietary applications. With the LGPL the message would be that you can use the code pretty much as you want, but if you change it you have to release the changes.
I cannot come up with a reasonable choice here. Either way has drawbacks. We've been through this before and went with the X11 license. Maybe it's time to rethink that decision... maybe not. All I can say is that I for one would like to know how current developers stand on this issue. Has anyone's thoughts/opinions changed significantly?
Mine at least yes... I used to think that proprietary versions of Wine wouldn't matter, since we already have to compete against the ultimate proprietary Wine (the one from Redmond). But I see now that there are ways to make the code kind-of-proprietary that can actually cause more harm to Wine than purely proprietary ones, and I think we should do something to address this issue.
What do others think?
One possible trap to getting toward a GPL. If I remember right, the last time, you had to get consensus. If "pseudo-open-source" company had contributed code, you would need their permission and they don't have to agree. john
On Thu, 13 Dec 2001, John Alvord wrote: [...]
What do others think?
One possible trap to getting toward a GPL. If I remember right, the last time, you had to get consensus. If "pseudo-open-source" company had contributed code, you would need their permission and they don't have to agree.
Just honestly asking the question: are you sure about that? As I see it, Transgaming took the Wine source, called it WineX and released it under the APFL (it's the APFL right? doesn't really matter). So what prevents someone else from taking Wine, call it Vino and release it under the GPL? My current understanding is that the legality of such a move depends on the license you start from and that the current Wine license would allow it: Permission is hereby granted ... to ... sublicense ... After all we know Wine can be used as the basis of proprietary products so it seems like you should be able to re-release it under the GPL. The only restriction I see is that: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Now what such permissions mean once you tack on the GPL or a proprietary license, I'm not sure. As far as I can tell, they would be pretty hollow. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
On Thu, 13 Dec 2001 22:30:07 -0800 (PST), Francois Gouget <fgouget(a)free.fr> wrote:
On Thu, 13 Dec 2001, John Alvord wrote: [...]
What do others think?
One possible trap to getting toward a GPL. If I remember right, the last time, you had to get consensus. If "pseudo-open-source" company had contributed code, you would need their permission and they don't have to agree.
Just honestly asking the question: are you sure about that?
As I see it, Transgaming took the Wine source, called it WineX and released it under the APFL (it's the APFL right? doesn't really matter).
So what prevents someone else from taking Wine, call it Vino and release it under the GPL?
My current understanding is that the legality of such a move depends on the license you start from and that the current Wine license would allow it:
Permission is hereby granted ... to ... sublicense ...
After all we know Wine can be used as the basis of proprietary products so it seems like you should be able to re-release it under the GPL. The only restriction I see is that:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Now what such permissions mean once you tack on the GPL or a proprietary license, I'm not sure. As far as I can tell, they would be pretty hollow.
[I meant a LGPL license, of course.] Just random, out of the box, spectulation. john
Permission is hereby granted ... to ... sublicense ...
Actually: "sublicense: A license giving rights of production or marketing of products or services to a person or company that is not the primary holder of such rights." That doesn't actually mean, in the context of the BSD license, they could legally change the license from that given by the primary copyright holder. It only means they are given the right to attach a EULA, or suplementary license, to the product. - Ender
On Fri, 14 Dec 2001, J.Brown (Ender/Amigo) wrote:
Permission is hereby granted ... to ... sublicense ...
Actually:
"sublicense: A license giving rights of production or marketing of products or services to a person or company that is not the primary holder of such rights."
That doesn't actually mean, in the context of the BSD license, they could legally change the license from that given by the primary copyright holder. It only means they are given the right to attach a EULA, or suplementary license, to the product.
Thanks for the correction. It is interesting and gave me an idea for modifying the current license. So I'm just throwing it out there for what it's worth: [...] Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: [...] Or, in traditional unified diff form :-) : Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the -"Software"), to deal in the Software without restriction, including -without limitation the rights to use, copy, modify, merge, publish, +"Software"), to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: Pros: 1. AFAIU, it makes it impossible to change the Wine license to something else (e.g. the AFPL since this is what started it) 2. it should be equivalent to the current license in all other respects: - companies can still make proprietary derivatives to port their applications or differenciate themselves - no 'viral' wording or linking issues that could frighten companies 3. intermediate between the original X11 and the LGPL Cons: 1. it's a non-standard license. As such it needs to be reviewed in detail and submitted to the OSI to make sure it is 'open-source' compliant. 2. it may be possible to publish the source and still restrict what users can do with it via a EULA. I'm not entirely sure about that so it should be investigated. 3. it makes it hard to change the Wine license (yeah, it's both a pro and a con, see pro 1). 4. it does not prevent the fragmentation of Wine into multiple proprietary variants (yes, this too is both good and bad, see pro 2.1) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une bêta...
Now what such permissions mean once you tack on the GPL or a proprietary license, I'm not sure. As far as I can tell, they would be pretty hollow.
The LGPL does not grant the right of re-licence LGPL components. However, as a license it does not prohibit sublicensing - nor can it, as the primary license is that of the main program a LGPL component is used in. Remember that the LGPL was written for libraries, to allow code which is fundementally GPL to be linked to propritery licenses. In the definition of sublicencing, technically from a legal point even transgaming are not allowed to newt the fundemental sublicencing right of the Wine code (as they do, in the AFPL). They can remove the sublicencing right on their own code, however, as that belongs under different copyright. This is all conjecture, of course, and I deny being any kind of legal expert, only someone who has been involved in court-cases over this kind of thing in the past. I'm sure transgaming is only attempting to protect their own IP rights. - Ender
John Alvord <jalvo(a)mbay.net> writes:
One possible trap to getting toward a GPL. If I remember right, the last time, you had to get consensus. If "pseudo-open-source" company had contributed code, you would need their permission and they don't have to agree.
Consensus is only needed to make incompatible changes. Switching to a license whose restrictions are compatible with the current one doesn't require special agreement from anybody, since the agreement is implicit in the current license. GPL, LGPL, BSD, and just about all free or non-free licenses are compatible with the X11 one, so that wouldn't be a problem. Anybody can take the existing Wine and release it under the LGPL; but of course this is useless if developers don't agree to use the new license for future developments. -- Alexandre Julliard julliard(a)winehq.com
On Thu, Dec 13, 2001 at 07:47:42PM -0800, Alexandre Julliard wrote:
I cannot come up with a reasonable choice here. Either way has drawbacks. We've been through this before and went with the X11 license. Maybe it's time to rethink that decision... maybe not. All I can say is that I for one would like to know how current developers stand on this issue. Has anyone's thoughts/opinions changed significantly?
Mine at least yes... I used to think that proprietary versions of Wine wouldn't matter, since we already have to compete against the ultimate proprietary Wine (the one from Redmond). But I see now that there are ways to make the code kind-of-proprietary that can actually cause more harm to Wine than purely proprietary ones, and I think we should do something to address this issue.
What do others think?
I might not have contributed much (one measily patch), but as far as I can see the only hurt that potentially can get done is less incentive to work on core wine, and less to use it by users (and thus maybe less incentive to develop etc etc). I'm not sure how much this allready has happened, for all I know it has been WineX where the d3d, Installshield and other "game related" stuff has been happening. Of course, that may be because I'm relatively new to the development. Personally I believe TransGaming will channel all this back, maybe they can do certain parts (IS) before they reach their goals as set out in their Business Model, which has happened before I believe. In the relationship with TransGaming it would be nice if these "premature" submissions could be made known, scheduled, or some such so that the rest of us knows what is going on. Knowing there is code growing that makes certain "juicy" bits work is exciting (to me at least), and knowing that it isn't totally free dampens that excitement a bit. I am not commercially involved with wine, so that is pretty much all I feel. I have no idea how this will work when they have their subscriber base, as subscribers can cancel their account a month later (I think, I have no real knowledge of how this works). So directly working on core wine might not be a sensible idea (then again, I have no real business knowledge either :). Something along the line of monthly merges mayhaps ? And probally pieces of coherent code (say, d3d8). Anyway, this is something for TransGaming to establish, and I hope they reach 20,000 subscribers soon. More on a theoretical train of thought, other companies (has anyone had contact with Lindows yet ?) might do this also, and with not so good motives. I don't think the threat of one of those overtaking wine in popularity is big, and there will always be loyal supportes of the core wine (the hurd is not dead) so we should be able to plug along and implement everything ourselves. I personally do not care much for marketshare, having more people switch to open source OSes does appeal to me, but I would be content also when it would be just me and other free-software freaks *cough*. To conclude this rather long rant, I think the current license is ok.
-- Alexandre Julliard julliard(a)winehq.com
LarstiQ / Wouter van Heyst
participants (10)
-
Alexandre Julliard -
Bill Medland -
David Elliott -
Francois Gouget -
J.Brown (Ender/Amigo) -
John Alvord -
LarstiQ -
Marcus Meissner -
Ori Pessach -
Patrik Stridvall