August 2007 - Wine-Devel - list.winehq.org

Re: Hmm. Cider and the LGPL

by Jason Green

> Hi Jason, > on the off chance the rest of Transgaming hasn't already > seen those two pages, please circulate the links. > One of the problems is that [to my knowledge,] we don't have any fluent German speakers in the company, so we wouldn't even know *how* to respond to those articles. :) > it'd be nice to have responses to questions like > "The LGPL seems to give users the right to remove > the LGPL'd portions of Cider from game A and use it > with other apps. The gamers who are currently doing this > are also copying proprietary parts of Cider, which isn't allowed. > How will Transgaming prevent the copying of the proprietary > parts of Cider without preventing the copying or modification > of the LGPL portions?". > The EULA included in all games which are shipped using Cider technology spells out how each of the pieces of the Cider framework are licensed. It includes the folders which have LGPL'd WineHQ code and lists all of the various MIT/BSD-style licenses for other components. Any components which require source re-distribution (such as those licensed under the LGPL) are available on the public CVS site. All of the license details can also be found on the public CVS site. We know that some people are creating their own "home-brew" Cider packages for other games, but they obviously cannot distribute these packages legally (in most countries, at least). It does take a fair bit of work to put together a custom package that actually works, and many of these apparently require hacked EXEs to get around other games' copy protection techniques. We do make customizations to the Cider engine and optimizations for each game that we port, so these "home-brew" games will never be as high quality as they could be. At the moment, there isn't much of a real issue to be worried about. People have pirated software on every platform that's ever been made, so I don't see why Macs would be any different. Not that we condone software piracy (ahem, *copyright violations*, that is) by any means, but in this case, it's mostly a non-issue. I'm not sure if that answers your question or not, but hopefully it clears it up a little bit. If a user wants to use only the LGPL parts of Cider, they will need to extract just those folders and leave the rest of the code alone. However, they'd probably have a hard time running a DirectX-based game without any of the D3D* libraries or many of the other non-LGPL pieces. > And maybe even get the answer back to the authors of those pages. > Anyone who speaks German is invited to respond to these types of articles and point them to our website and PR department. To my knowledge, I don't believe that these authors attempted to contact us prior to writing their articles. > That ought to calm the waters. > Nah, this is the Internet... there's always a storm brewing somewhere. ;-) Jason Green Developer, TransGaming, Inc.

Aug. 30, 2007

Re: Hmm. Cider and the LGPL

by Dan Kegel

On 8/30/07, Jason Green <jave27(a)gmail.com> wrote: > > http://www.linux-community.de/story?storyid=23294 and > > http://www.macnews.de/news/102145.html mention > > that some users are using Cider from one game > > to run a second game on the Mac. The game vendors > > are upset, and are saying they'll do something to make > > that harder. There is some question about whether Cider > > includes LGPL components of Wine, and whether there > > are any violations lurking there. > > I imagine our friends at Cedega would > > instinctively avoid such infringement, but accidents might > > happen. It'll be interesting to see if anybody finds a real problem. > > All of the LGPL Cedega/Cider source code is available on TransGaming's > public CVS server at http://www.cedega.com/cvs/. Any substantial > patches to LGPL'd components are typically submitted back to WineHQ. > There haven't been many recently since most of those components aren't > heavily used by games. One of my roles at TransGaming is to make sure > that patches to our LGPL'd folders make their way back here. Hi Jason, on the off chance the rest of Transgaming hasn't already seen those two pages, please circulate the links. it'd be nice to have responses to questions like "The LGPL seems to give users the right to remove the LGPL'd portions of Cider from game A and use it with other apps. The gamers who are currently doing this are also copying proprietary parts of Cider, which isn't allowed. How will Transgaming prevent the copying of the proprietary parts of Cider without preventing the copying or modification of the LGPL portions?". And maybe even get the answer back to the authors of those pages. That ought to calm the waters. Cheers, Dan

Aug. 30, 2007

Re: Hmm. Cider and the LGPL

by Jason Green

On 8/30/07, Dan Kegel <dank(a)kegel.com> wrote: > http://www.linux-community.de/story?storyid=23294 and > http://www.macnews.de/news/102145.html mention > that some users are using Cider from one game > to run a second game on the Mac. The game vendors > are upset, and are saying they'll do something to make > that harder. There is some question about whether Cider > includes LGPL components of Wine, and whether there > are any violations lurking there. > I imagine our friends at Cedega would > instinctively avoid such infringement, but accidents might > happen. It'll be interesting to see if anybody finds a real problem. All of the LGPL Cedega/Cider source code is available on TransGaming's public CVS server at http://www.cedega.com/cvs/. Any substantial patches to LGPL'd components are typically submitted back to WineHQ. There haven't been many recently since most of those components aren't heavily used by games. One of my roles at TransGaming is to make sure that patches to our LGPL'd folders make their way back here. Jason Green Developer, TransGaming, Inc.

Aug. 30, 2007

Re: Hmm. Cider and the LGPL

by Scott Ritchie

On Thu, 2007-08-30 at 12:07 -0700, Dan Kegel wrote: > http://www.linux-community.de/story?storyid=23294 and > http://www.macnews.de/news/102145.html mention > that some users are using Cider from one game > to run a second game on the Mac. The game vendors > are upset, and are saying they'll do something to make > that harder. There is some question about whether Cider > includes LGPL components of Wine, and whether there > are any violations lurking there. > I imagine our friends at Cedega would > instinctively avoid such infringement, but accidents might > happen. It'll be interesting to see if anybody finds a real problem. > - Dan > Are there English versions of these articles? My German isn't so hot these days. Thanks, Scott Ritchie

Aug. 30, 2007

Hmm. Cider and the LGPL

by Dan Kegel

http://www.linux-community.de/story?storyid=23294 and http://www.macnews.de/news/102145.html mention that some users are using Cider from one game to run a second game on the Mac. The game vendors are upset, and are saying they'll do something to make that harder. There is some question about whether Cider includes LGPL components of Wine, and whether there are any violations lurking there. I imagine our friends at Cedega would instinctively avoid such infringement, but accidents might happen. It'll be interesting to see if anybody finds a real problem. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Aug. 30, 2007

Re: .NET support

by Roderick Colenbrander

On Thursday 30 August 2007 19:05, Jakob Eriksson wrote: > Roderick Colenbrander wrote: > > The main issues were related to using Wine as a sort of 'plugin'. They > > didn't want to use standard winelib. The Mono hack they proposed for it > > wasn't accepted and they didn't want to distribute their own Wine. > > Gdiplus was also an issue because they had to mix it with winex11.drv but > > that would have been fixable. > > OK. > > > Win32 mono will be able to work on Wine. After some more integration it > > might be able to embed lets say Win32 ActiveX controls and use win32 > > dlls. It will never be able to use gdi32/user32 to change the behavior of > > some of the drawing stuff. For that they would need to rewrite > > Windows.Forms to not render the controls themselves. They will never do > > that. (It also means restarting from about scratch) > > But is mono modular enough, that implementing a third party Windows.Forms > for Win32 mono is possible, that uses gdiplus/gdi32/user32? > > Or are there other, more intertwined dependencies? > > (If so, then not all is lost. A separate project may do this if > compatibility is needed. > This would of course lead to mono being more compatible both on Win32 > and Unix.) > > > regards, > Jakob Roughly speaking they are only using System.Drawing (gdiplus) for drawing. Moving over to legacy win32 dlls is too much work I think. Everything is designed for the current way of operating. (Note I haven't seen the SWF code in years) Roderick

Aug. 30, 2007

Fwd: Re: winmm: Change default driver order to be alsa, coreaudio, oss - try2

by Kuba Ober

---------- Forwarded Message ---------- Subject: Re: winmm: Change default driver order to be alsa,coreaudio,oss - try2 Date: Tuesday 21 August 2007 From: Kuba Ober <kuba(a)mareimbrium.org> To: wine-devel(a)winehq.org On Sunday 19 August 2007, Vitaliy Margolen wrote: > Maarten Lankhorst wrote: > > Forgot to remove the strlen check. > > Isn't this a bit premature? ALSA still does not support proper sound > capture, working mixer, and not stable enough on some configurations. In fact, for whatever it's worth, on some machines running either CentOS5 or FC6, for me alsa is completely broken (choppy sound output from linux alsa applications, etc). :( Cheers, Kuba -------------------------------------------------------

Aug. 30, 2007

Re: .NET support

by Jakob Eriksson

Roderick Colenbrander wrote: > The main issues were related to using Wine as a sort of 'plugin'. They didn't > want to use standard winelib. The Mono hack they proposed for it wasn't > accepted and they didn't want to distribute their own Wine. Gdiplus was also > an issue because they had to mix it with winex11.drv but that would have been > fixable. > OK. > Win32 mono will be able to work on Wine. After some more integration it might > be able to embed lets say Win32 ActiveX controls and use win32 dlls. It will > never be able to use gdi32/user32 to change the behavior of some of the > drawing stuff. For that they would need to rewrite Windows.Forms to not > render the controls themselves. They will never do that. (It also means > restarting from about scratch) > But is mono modular enough, that implementing a third party Windows.Forms for Win32 mono is possible, that uses gdiplus/gdi32/user32? Or are there other, more intertwined dependencies? (If so, then not all is lost. A separate project may do this if compatibility is needed. This would of course lead to mono being more compatible both on Win32 and Unix.) regards, Jakob

Aug. 30, 2007

Re: .NET support

by Roderick Colenbrander

On Thursday 30 August 2007 18:41, Jakob Eriksson wrote: > Roderick Colenbrander wrote: > > O > > I think the incompatibilities you mean are for instance that in case of > > Mono you can mix Windows.Forms with win32 calls. If you don't like the > > behavior of something you can call a standard gdi32/user32 function and > > change some stuff. > > Yes! Thank you, I didn't know 100% what I was talking about. > > > Things like that work because I think the .NET version of Windows.Forms > > maps to win32 controls. Mono renders everything itself through > > System.Drawing. I don't think a different gdiplus.dll will make any > > difference for this. To allow mixing of Windows.Forms with gdi32 stuff > > everything needs to be rendered using native controls. That's what mono > > attempted years ago using Wine but they had various Wine integration > > troubles and we didn't come to a good solution for it. > > And wasn't one of those troubles that there was not gdiplus DLL? > I was hoping an integration was coming closer. > > regards, > Jakob The main issues were related to using Wine as a sort of 'plugin'. They didn't want to use standard winelib. The Mono hack they proposed for it wasn't accepted and they didn't want to distribute their own Wine. Gdiplus was also an issue because they had to mix it with winex11.drv but that would have been fixable. Win32 mono will be able to work on Wine. After some more integration it might be able to embed lets say Win32 ActiveX controls and use win32 dlls. It will never be able to use gdi32/user32 to change the behavior of some of the drawing stuff. For that they would need to rewrite Windows.Forms to not render the controls themselves. They will never do that. (It also means restarting from about scratch) Roderick

Aug. 30, 2007

Re: .NET support

by Jakob Eriksson

Roderick Colenbrander wrote: > O > I think the incompatibilities you mean are for instance that in case of Mono > you can mix Windows.Forms with win32 calls. If you don't like the behavior of > something you can call a standard gdi32/user32 function and change some > stuff. > Yes! Thank you, I didn't know 100% what I was talking about. > Things like that work because I think the .NET version of Windows.Forms maps > to win32 controls. Mono renders everything itself through System.Drawing. I > don't think a different gdiplus.dll will make any difference for this. To > allow mixing of Windows.Forms with gdi32 stuff everything needs to be > rendered using native controls. That's what mono attempted years ago using > Wine but they had various Wine integration troubles and we didn't come to a > good solution for it. > And wasn't one of those troubles that there was not gdiplus DLL? I was hoping an integration was coming closer. regards, Jakob

Aug. 30, 2007