wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

>On Tue, Feb 12, 2002 at 04:21:59PM -0500, Roger Fujii wrote: > > Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html > > I don't think that LGPL and GPL differ in this regard. > > [Summary of link: discussion of whether including binary-only firmware in > the Linux kernel is a violation of the GPL.] > > In this regard, they do not differ. However, whereas the GPL is mostly > 'symmetric', placing the same limitations on anything that's linked to GPL > code (except for the "standard system facilities" exemption), the LGPL > quite explicitly only places limits on the licensing and > source-availability of other code on which the LGPLed code is made to > depend. it also restricts the ways and means of binary distribution. > To give a concrete technical example (but not an authoritative legal one, > as IANAL), it is my understanding of the LGPL that if someone has released > a library under the LGPL, a third party cannot distribute a modified > version of this library that has been linked against a proprietary > library[1]. I think because of the reduced scope of the LGPL, there's > also less room for ambiguity on questions of aggregation vs. derived > works. I believe your case falls under the "work as a whole" clause. The problem in the wine context is that it is NOT clear that any propriatary library doesn't fall under that clause unless you make it as a dropin replacement for something that's already there. And, if it's NEW functionality you're adding, you must do it in such a way that it can be removed at runtime. So, if your business model is to develop a value-add, LGPL is not your friend. > > yes, but studying can be done in a non 'open source' license too (like AFPL). > > This is why using the word "contribute" is really a misnomer which is > > why I said "show your work". > The difference is that in the case of the LGPL, a third party can only > erect certain limited sorts of technical barriers to reintegrating the > sources, at some cost to them in terms of programmer time; whereas under > the BSD license, a third party can erect legal barriers to reintegration. if you can make a propriatary extension, it holds that you can license the source code for it some other way too. If the point was that with enough effort, you can roll (some of) the changes back in, then I agree. But is this practical? > There is an important difference between LGPL/GPL and standard EULAs for > proprietary software. An EULA requires a user to give up freedoms they > would otherwise have; the LGPL and GPL give additional freedoms TO users > which under copyright law would normally be reserved for the author. this is a perceptual difference. the legal mechanism for both is simply conditions of the transfer of the copyright since neither case makes any difference to anyone who doesn't distribute what they have to the public. > If a third party does not accept the terms of the GPL, and they have been > granted no other license to modify/redistribute, then they're guilty of > copyright infringement -- and copyright infringement is far easier to > prosecute than tort or breach of contract. well, not according to that calif. ruling (in certain cases). > Eben Moglen has expounded on this point quite persuasively in the past. > Whatever flaws the xGPL licenses might have, I assure you that > unenforcability is not among them. I don't believe anyone has said there is NO legal basis. What has been said is that there is little legal PRECEDENT. There are various parts to *GPL that are quite arbitrary (like, why is it legal to link with a .so, but not a .a, or a .o? what is being linked is the same) and is not clear it will stand a good challenge. As such, it's pointless to argue what it means except in the cases that it's absolutely clear on. For all other cases, you are in untested territory. > To the question of the LGPL being unclear: your example at the top cites > discussion among a number of non-lawyers. The fact that they disagree > about the meaning of "aggregation" may merely be a reflection of the fact > that no party to that discussion is an expert in IP law. until there is case law, what those words mean in the software context is open to interpretation. "Aggregation" of books may not be considered the same as aggregation of programs. If you need convincing of this, look at the consent degree between the justice dept and M$ with IE in win98. > Any company that's considering working with Open Source software as any part of their > business model should seek legal advice; just because the BSD license > seems clear to most informed laymen doesn't guarantee that it's free from > legal pitfalls. would you care to enumerate one that is the result of the license? > So while an easily understandable license may be helpful > to some, it doesn't eliminate the need for corporate lawyers. you must know some INCREDIBLE lawyers. The ones I have dealt with always makes something simple really complicated. If you know of someone that can make something complicated simple, I'd like to have their #. > > > If the company is one like, say, Lindows.com, and they have a business > > > model based on selling a branded, enhanced version of Wine, there are > > > rational reasons for possibly not wanting to use an LGPLed code base. > > > There are several different options for such a company. Some might choose > > > to risk the LGPLity, and decide to see if they can make a profit just from > > > selling people something they can already get for free. This is not out > > > of the question; every Linux vendor is doing this today, and if 90% > > > marketing + 10% programming works for Microsoft, it should work for others > > > too, right? > > > a) M$ can charges for their work > > b) it works for linux (I presume you mean distributions) vendors because > > most others sell a propriatary value add (like transgaming) which does > > not fall under your description for this case. The linux vendors have > > an advantage that what they are replacing (nt, solaris, aix...) are > > a rather expensive. The problem wine solves (for most people) is the > > cost of a PC (US$400). There isn't much of a margin here. Can you > > show me any example of successful companies using this business model? > > Judging by his posts here, it sounds like Michael Robertson believes his > own company's business model is already very close to this. If lindows was just a branded version of wine, why are people getting so bent out of shape about them contributing? > I wonder if he would say Lindows.com's hopes for profitability stand on the ability to > maintain a competitive advantage over other Wine vendors by keeping their > changes proprietary, or on value-added features such as integration into > an easy-to-install product? I would presume a little of both. > There's still lots of room for proprietary value-add with an LGPL Wine; > and I'm not arguing that this is a bad thing. I just think that having > companies create value-added products by making closed-source > modifications to the Wine *core* is a bad thing. 'lots of'? I really think you are overstating the case. Gav doesn't think so. I think Michael Robertson has implied he didn't think so either - the pie just isn't that big... > > (I just love how people use 'steal' in reference to something freely > > given away - I guess the same people ask for interest when they do > > charity work) > As someone who gave his assent (however insignificant) to the current Wine > license, *I* do not use the word "steal" to refer to the actions of such > companies. you may not have, but this statement has either been said or implied by many in the *GPL camp. It is a pervasive attitude that always makes this topic more imflamatory than it needs to be. > > So, given the world of (using "contribute" meaning code that can be easily > > worked back into the common tree): > > 1) Evil companies that won't contribute no matter what > > 2) Companies that contribute some, but not all of what they do > > 3) Companies that contribute > > > The only thing a license change will do is stop #2. If this is what you want, > > we can stop arguing now. > > I disagree with this breakdown. Assuming there are "evil" companies > involved[2], they will find it more difficult to do evil things with Wine > under the LGPL than they would under the BSD license; this is a given, but they CAN still exist. The notion that LGPL will prevent that kind of behavior is just not true. > and at least some of the companies that don't contribute at all do so > because they're misguided, not because they're evil, so the LGPL would cause them to > contribute back to our mutual benefit. Both of these results are wins. the misguided ones I think (MHO) eventually will contribute back, for the very same reason you have stated (problems with keeping the trees synced). Regardless, the whole point boils down to this: Is the code you are going to coerce out worth the code that is lost by entities either unwilling or unable to abide by *GPL? There has been ample statements made saying that the latter part of the question is not insignificant. > [2] Not a very sustainable business model, btw; on the whole, being evil > is no more profitable than being altruistic. I agree that it's self-defeating, but there is nothing altruistic if you EXPECT to be paid, whether it's cash, or code. I haven't seen any arguments for *GPL made here on altruistic grounds (not to say that *GPL can't be used for such purposes - take quake from Id software for example, but this is when you take something propriatary and *GPL it). All I see are pretty selfish - which is fine, as long as it's not being passed as being altruistic. -r

1 0

DirectX implementation on top of OpenGL
by Jakob Eriksson 13 Feb '02

13 Feb '02

DirectX on OpenGL. http://sourceforge.net/project/showfiles.php?group_id=44365&release_id=70636 Seems to BSD style license, but only some files say that. Most files have no copyright information. Warning: a whole slew of files are Copyright Microsoft. (Only include files though.) regards, Jakob Eriksson

1 0

Re: Wine license change
by Roger Fujii 13 Feb '02

13 Feb '02

> The LGPL and the GPL have different restrictions on the creation of > certain types of derivative works. The thing about Wine is that it's not > *a* library, it's a *set* of libraries -- reimplementations of DLLs. How is this any different from the linux kernel and its device drivers? Read: http://www.uwsg.iu.edu/hypermail/linux/kernel/0105.3/0203.html I don't think that LGPL and GPL differ in this regard. > > I have no clue what you are talking about. I didn't say anything until > > the "Here we go again". And Yes, I have read the *GPL, many, many, many > > times. > > 'Effectively license your software to the FSF'. The LGPL, as a license, > is designed to be idempotent, just as the BSD license is; under each > license, everyone is granted the *same* freedoms. There's nothing in the > text of the LGPL that can be interpreted as licensing your software to the > FSF that isn't already present with the existing license. I can change the BSD license. I cannot (or at least, not without a fair amount of work) do this with *GPL. It forces me, the copyright holder of the contributions, to contribute as *GPL, even if I may prefer a freer license. This lack of ability of changing the license is why I say "effectively license to the FSF". > > This AFAIK, fulfills the technical requirement > > of the *GPL, but it certainly isn't a usable form. > In that respect, you're correct that no one has to release the source > code in a form that's easily reintegratable with the main Wine tree. And > if someone wanted to be spiteful, they could do what you describe -- but > they would still have to release the source code in the form that THEY use > it when working on and compiling Wine, which means their changes are still > visible for others to study. yes, but studying can be done in a non 'open source' license too (like AFPL). This is why using the word "contribute" is really a misnomer which is why I said "show your work". > > we can quibble about what "free" means, but saying GPL is "more free" than > > X11/BSD doesn't make any sense. Given the current license is X11/BSD and > > the argument is for changing it to LGPL, I can't see how one can use the > > "freedom" argument in this case. > > > geez. no need to get bent out of shape. I'll rephrase and say BSD is > > MORE free than GPL. Happy? > > I don't believe anyone has argued that Wine should be placed under the > LGPL because the LGPL is more free than the BSD license. er, that was what I was responding to - someone did. > I disagree with the idea that what users are allowed to do with the code is the only > metric of freedom that's important to consider, but since this relicensing > discussion wasn't brought about by concerns that the current license is > non-free, I don't think it's relevant, either. You're correct that the > BSD license is more free than the GPL per this particular metric. The claim that moving to *GPL would make it MORE free (which implies that the current license is LESS free). My point is that this is a non-argument (and you seem to be agreeing with me here) > > The problem with that particular argument is that it makes the fundamental > > assumption that all people who don't contribute back NOW is evil foreever. > > You just don't know what will happen in the future. Maybe Sun/IBM buys out > > lindows.com in 6 months when they are broke, and opens the source. Or, > > maybe in a year, they have a change of heart (has happened before with other > > companies). The point is that it's arguably better to have more players. > > Actually, I don't think that assumption is key to my argument. Consider > that a company which takes without giving back will either spend a lot of > developer time re-merging upstream fixes into their local product, or will > create a product which diverges significantly from the main tree. Either > scenario, when considered by itself (that is to say, setting aside any > reasons this might be profitable), constitutes an inefficient use of > programmer time; the cost of keeping a private tree is higher than the > cost of letting the community maintain the tree for you. ok.. but this argument works for the current license too.... > If the company is one like Corel, who profits not by selling Wine but by > selling products that run under Wine, then trying to keep their changes > private is misguided -- most such companies would still see the advantage > of a Windows implementation that they didn't control exclusively, so long > as Microsoft didn't control it either, and would not be turned off by the > LGPL -- in fact, both we and they would benefit from the LGPL, because of > the more efficient use of developer time. this is still true for the current license. > Other companies in that situation might indeed shy away from an LGPLed Wine; > but I can't think of a rational reason for doing so, and companies that make irrational > business decisions don't strike me as a good reason to avoid a licensing > choice that benefits the rest of us. here is where we differ. The problem with *gpled stuff is that because certain things are unclear, even well meaning people can end up in violation. If you read the kernel arguement at the beginning, we see that there is a difference in interpretation between alan cox and the FSF. It is not irrational to say that the legal risks are greater than the economic gain. And for those of you who say *GPL is on strong legal ground, look at slashdot today. A calif court just threw out a significant section of a EULA and may affect the GPL. Don't know if it is going to be upheld (might make it to the supreme court), but the point is that it is definitely not in settled law. > If the company is one like, say, Lindows.com, and they have a business > model based on selling a branded, enhanced version of Wine, there are > rational reasons for possibly not wanting to use an LGPLed code base. > There are several different options for such a company. Some might choose > to risk the LGPLity, and decide to see if they can make a profit just from > selling people something they can already get for free. This is not out > of the question; every Linux vendor is doing this today, and if 90% > marketing + 10% programming works for Microsoft, it should work for others > too, right? a) M$ can charges for their work b) it works for linux (I presume you mean distributions) vendors because most others sell a propriatary value add (like transgaming) which does not fall under your description for this case. The linux vendors have an advantage that what they are replacing (nt, solaris, aix...) are a rather expensive. The problem wine solves (for most people) is the cost of a PC (US$400). There isn't much of a margin here. Can you show me any example of successful companies using this business model? [snip] > This leaves the last possibility; that such a company chooses not to enter > the market, or fails to come into being, because they can't find numbers > that make sense using either a slightly-older, BSD-licensed Wine or an > up-to-date LGPL-licensed Wine. And we do lose something by not having > such companies around, particularly if they happened to have a 'change of > heart' down the road and freed their source code. or have their participation in current development. Most well meaning companies will send in patches to parts that they are not trying to hold propriatary. You're making the assumption that companies that hold ANY software back will hold ALL the changes. > Does the loss of such companies as players in the Wine community outweigh > all of the other potential advantages described above, including the > advantage of some otherwise closed-source companies choosing to open > their source as a result? I don't think it does. I think that today, if > we look at nothing more than raw lines of code that Codeweavers > contributes to Wine that we are told would not available for use in a > BSD-licensed tree going forward, it makes sense to switch to the LGPL; and > I think the benefits only go up from there. As I said before, if you don't care about other commercial input, go *GPL. But at least be honest and say, "we don't care about companies like transgaming". It's utter nonsense to say that the license change will only affect "the evil companies that steal our source code" (I just love how people use 'steal' in reference to something freely given away - I guess the same people ask for interest when they do charity work) or that wine will benefit because evil companies will now 'contribute'. If they are that evil, they will run the obfuscator and make the merge difficult, if not impossible. So, given the world of (using "contribute" meaning code that can be easily worked back into the common tree): 1) Evil companies that won't contribute no matter what 2) Companies that contribute some, but not all of what they do 3) Companies that contribute The only thing a license change will do is stop #2. If this is what you want, we can stop arguing now. -r

3 2

Re: Copyright, derivative works, and truly free licensing (Was:
by Rolf Kalbermatter 13 Feb '02

13 Feb '02

Brett Glass <brett(a)lariat.org> wrote: >I agree wholeheartedly that such discussion shouldn't be a constant distraction >or devolve into a "flame war." I have taken great pains to express my point >of view very carefully and to make sure that nothing I've posted could be >construed as "flamage." Well, I for myself can only say that you have certainly failed in this. For me, your posts had from the first beginning the character of somone on a crusade against RMS, the FSF and anything connected with it. Although some of your remarks would have been at least interesting, that fanaticism in wording your opinion about xGPL, making claims about what someone elses intentions "doubtlessly" are, and trying to come up with the worst doom scenarios, made it virtually impossible for me to accept and listen to any of your other more serious statements. The subject of what direction Wine should go, seemed obviosly just the coat hanger on which you continued this, your personal crusade! So as far as I'm concerned you have certainly not reached your goal. I'm certainly not a xGPL fanatic, but it personally feels not right to me that people spend their time on something to work on and any company can come in and take whatever there is and make profit out of it, without contributing something back. And with that I don't mean the questionable marketing hype of letting those people say: "Hey you know, they made their great product out of our project and I'm so proud that I have spent months and months of my own time to allow them to earn big bucks!" And don't say that they earn the money only for the additional value that company has put in. If it wouldn't be for the developer in the project, that company would not have a product at all to sell as you have actually also agreed on. >I agree, as I have said above, that the developers have the right to make >the decision. But because they are doing the entire project for the benefit >of users as well as for themselves, they certainly should care about how >users feel. What's more, if they are seeking bug fixes or help with >development, they certainly should care how potential contributors feel. >Finally, they should care about how advocates of the project feel. While >advocacy does not expand the code base, it does expand the base of users >and testers. Hence, it plays an important role in any collaborative >software project. You should have started the whole discussion more in this style. This would have helped a lot more than trying to bring in your personal feelings about the FSF and xGPL. Even if the FSF is what you say, it does really not help to bring that topic up in such an emotional tone. It only polarizes everyone, and hinders the solution of the original problem, which might cause the person who is responsible to take a decision out of frustration rather than out of great consideration. >I agree. If anyone has considered any of my messages to be a "flame" rather >than rational discussion, I apologize; nothing I've written was meant to be >a "flame." I really do want to be able to continue to work with, advocate, >and (hopefully) contribute to, WINE, and this has been the reason for the >volume of passionate messages I've posted over the past few days. Well I did actually. This is probably my problem, but your apology is accepted anyhow ;-) And now I go back and continue to work on my first of hopefully a series of contributions to Wine! Rolf Kalbermatter

2 1

Re: Licensing response and an idea
by Lean Fuglsang 12 Feb '02

12 Feb '02

Thanks for an enlightening post, Gav. //DISCLAIMER - I AM JUST AN ORDINARY USER - SO DON'T READ IF YOU DON'T FEEL LIKE I am not a developer (yet). But I truly believe in the spirit of OpenSource Free software. I have reported some bug reports, but I would really like to contribute more. When I first heard about a (very) possible licens change to GPL I thought it was a great Idea, because I hate companies who take code and don't contribute back. With the current license this is possible. But I also think it would be a shame for companies with good intentions (as Transgaming) who (maybe:) will contribute all there code back, and make very fast directed code to wine. I would also be very delighted to pay money directly to the wine project because I like it and use it. An important note is that this is what I do with everything that I buy. When I by music, it is because I like it and have heard it and want's to support the artist. Same with movies. I know this is not the way the corporate world works at the moment, but I can pirate music/video/software very easily and therefore they have to trust me to pay for what I want's to pay to. Phew, hope I didn't confuse all of you (like I confused my self:) But the point is, I really like to make contribution to a gratis project if it is GPL'ed or dual licensed (for 'good' corporations). Many of the people I know has the same 'Ideology' as me, and don't pirate things they think aren't sh**t. And after I have changed to linux and opensource, I have actually pirated a lot less, because all stuff are free, and the things that aren't 'stands out', so to speak. Just my .02$ (and maybe more if it goes as I hope:) //lean Ps. Hope I send this mail to the right place

1 0

Direct 3D 8.0 Wrapper for OpenGL Open Sourced
by Damjan Lango 12 Feb '02

12 Feb '02

Hi, Just found this on http://www.osnews.com/: Direct 3D 8.0 Wrapper for OpenGL Open Sourced http://www.osnews.com/story.php?news_id=613 Not sure what is the license, but maybe it could be incorporated to wine as an alternative to the transgaming's version. ciao Damjan

3 2

wine license vote
by Shane Shields 12 Feb '02

12 Feb '02

hello after having contributed a couple patches (more to come im working on getCalenderInfo now) i feel i can say a couple of words. i have been following the current "discussion" on the license change with avid interest (not to mention a few laughs). just to make sure im not speaking out of a red hat (i compiled my own linux) i downloaded a copy of the licenses in question and compared them side by side. as everything that i wanted to ask has been discussed on the list with good points from both sides of the fence im not going to go over old ground. i think that the lgpl license would be a better choice for WINE than the bsd license. i know that some would disagree and some would agree thats the way the cookie crumbles. but i think that the most important thing is for people to make a decision for themselves and not to try to convince people that dont want to be convinced. its a waste of programming time and cpu cycles (sound familier m$). Shane Shields -- To drink the WINE of success you must first seek the sayings of source _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

2 1

Greetings and a question
by Michael Cardenas 12 Feb '02

12 Feb '02

Hello everyone. My name is Michael Cardenas and I'm working on Wine for Lindows.com. I'd like to start a lot more communication with all of you and I have a couple of questions. I'm working on an app that uses a custom dll which requires msvcp60.dll to be loaded at launch time and won't launch without it. Currently there's no implementation of msvcp60.dll in wine. Is that just because no one has needed it yet? Or has someone looked into this and seen that it's too large to do? Or is it just not needed and there's some substitute dll? Doing some research, I see that on a fresh install of Windows98, the dll is present, so it seems to be a common windows dll. MSDN mentions the dll in this article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html… "A good example of this is the Microsoft Visual C++ Runtime assembly, which includes atl.dll, mfc42.dll, mfc42u.dll, and msvcp60.dll." Also, there's been basically no discussion of this dll on this mailing list. So, to proceed, I'm going to create a stub dll and hope the app will launch and not need many functions from that dll. I'd like to know if there's a good way to make a complete stub for the dll. Right now, I just made a stub dll with one function. Thanks, Michael

4 3

ping
by lawson_whitney＠juno.com 12 Feb '02

12 Feb '02

Good day! Anybody know a current email address for Mike McCormack? Did he ever show up at Codeweavers? Regards, Lawson

2 1

Re: RFC: Re: Problem with COM (fwd)
by Gerard Patel 12 Feb '02

12 Feb '02

At 10:05 PM 2/11/02 -0500, you wrote: <snip> (original poster) >I must use 5726, 5760 and 9600. My app need this to work. On 4800 >and 9600 I got error. <snip> (Lawson) >Now nobody is going to convince me there is any software that will make >a normal 16550a run at 5726 <snip> You still don't have access to the world wide web ? If you have access to Google, search for the following Usenet posting, for example : UnHy6.600095$JT5.16435354(a)news20.bellglobal.com If you can't use Google, you could see that this is a common request under Windows. quite a few programmers need to access devices with non-standard crystals, or even non 8251 chips with specific drivers. In this post, you could see that SetCommState accepts any baud rate up to 9600 bauds, and that over 9600 bauds the idea is that the Windows driver should accept values that are inside a +-1% interval of the 'correct' value (although the poster says that the calculation is bugged and works only for negative differences). The Windows code for the 8251 family is probably always rounding to the next integer value under 9600, and if the wanted rate falls to +-1% of the 'normal' value over 9600. As I understand it, the 1% tolerance is explained because such a small difference don't matter for asynchronous serial communication. Gerard

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