> ok,> This is something I want to ask for some time now :)> Does this mean that License issues works with wine as it > works with the Linux kernel?> The Linux kernel is GPLed, however if a module (driver) is > dynamic loadable, it can have a proprietary license.> Is this the way it works with wine? The core (wine itself) > is LGPL, however its modules (builtin dlls in this case) could > have a different license.> If this is true, I think it would make things easier for everyone.> As an example, winex specific code (COM support, DX, ...) would be able > to just plug into a regular wine. It would also benefits winex as it would > have a more consistent core which would help sove common problems for wine > > (codeweavers) > and winex faster (as the dll separation stuff).> []'s > Raul Diasevery dll in wine can have its own license. This is already done a long time for example: wineX has been using AFPL dll's since they started. and we sometime's need to load windows dll's and they have a different license too. ( but i guess you already knew that ) But i do think that we want to keep as much as we can under the same license. since that makes it easier to move stuff around. Mark Hannessen oh... If someone want's to look at the wineX cvs that contains the LGPL licened stuff.. this is the syntax: ( thanks to Rizsanyi Zsolt ) cvs -d:pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex checkout -r winex-2-1 wine
Mark Hannessen <msh104.mymail@12move.nl> wrote: <SNIP>>every dll in wine can have its own license. > >This is already done a long time >for example: wineX has been using AFPL dll's since they started.Yes, but in that "long time" wine had a X11/MIT/BSD style license that allows that.>and we sometime's need to load windows dll's and they have a >different license too. ( but i guess you already knew that )So this still true to the LGPLed wine. This makes me wonder if things wouldn't be really easy for every one if winex take advantage of this. It wouldn't be necessary to keep ReWind as the "official" wine already let their dlls and dll enhancements to have a different license (as they state). []'s Raul Dias
> So this still true to the LGPLed wine.> This makes me wonder if things wouldn't be really easy > for every one if winex take advantage of this.I would like nothing more than see wineX using the LGPL wine core. The more of their software is LGPL licensed, the more gets commited back to wine.> It wouldn't be necessary to keep ReWind as the "official" wine > already let their dlls and dll enhancements to have a different > license (as they state).If their is ever going to be anyone willing to use wine in a way other developers do not want, he has the right to use the rewind cvs to start with. so the rewind cvs will have to exist for all eternity. by the way... what do you mean with rewind being the "official" wine. ain't the LGPL licensed wine the official one now ?
>>by the way... >>what do you mean with rewind being the "official" wine. >>ain't the LGPL licensed wine the official one now ?> Sorry,> I meant: > It wouldn't be necessary to keep ReWind, if the "official" (LGPL) wine > already let their dlls and dll enhancements to have a different > license (as they state).not true if anyone would want to alter the wine core, for any reason he has the right to use the "rewind core". ( for example: to create or a not open-source commercial product ) so if someone has the right to do something, he should also be able to do it, so rewind needs to be availible somewhere. like i already mentioned before, rewind is also used for something you might call "patch trading" wineX can not use Patches that are LGPL licened in there AFPL dll's, so people who think wineX is doing a good job submit patches to both wine and rewind ( dual license ) wineX then picks these patches out of rewind and uses them. Mark Hannessen
> My point about winex is that all this patching trading > would not be necessary if they were using wine from > winehq (and not from rewind) and letting their implementation of > d3d, safe disc to be just as mudules/dlls to the wine. > > All required changes to the "core" wine would have to be LGPLed > but this wouldn't be a problem, would it? >I agree with d3d. but i'am not sure about copy protection. is that entirely done on dll level ?? if so.. it would surely be a nice thing to ask transgaming what they think about this hole LGPL "core" story. having transgaming, codeweavers and all the "might be future wine" versions using the same core is surely in our advantage. ( and in theirs too ) it would boost develepment of the wine "core" by "i don't know how many percent" !! and it also make's sure that most thinks will stay compatible. right now, wineX can not submit some patches directly to wine because both core's are becoming incompatible. Mark Hannessen