- wine-devel - winehq.org

RE: Wine build system tech info
by Patrik Stridvall 13 Feb '02

13 Feb '02

> As part of a private investigation I noticed that both > WINE and LINUX kernel > build systems have a mkdep utility which generates in > clude file > dependencies. What I am looking for is to understand > the reasons behind this > decision for the two very popular projects instead the > recipe > suggested by GNU make documentation. For us because we do not wish to depend on GNU Make. For Linux kernel, no idea.

2 1

RE: DLL specific defines
by Patrik Stridvall 13 Feb '02

13 Feb '02

> > With the patch below this is added as EXTRADEFS > > flags so I can pick it up from the Makefile_in's > > and convert to .dsp compile rules. > wouldn't it be better to add them to another specific define > (like EXTRAWINDEFS or something) just to really know what > they are for ? If you wish. I don't care either way. I just want the defines somewhere so I can find them in the Makefile.in to .dsp/.dsw convertor.

1 0

Re: DLL specific defines
by Eric Pouech 13 Feb '02

13 Feb '02

> With the patch below this is added as EXTRADEFS > flags so I can pick it up from the Makefile_in's > and convert to .dsp compile rules. wouldn't it be better to add them to another specific define (like EXTRAWINDEFS or something) just to really know what they are for ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: Wine license change
by Brett Glass 13 Feb '02

13 Feb '02

At 12:09 PM 2/13/2002, Paul Millar wrote: >This is the crux of the issue. What if the business model relies upon >retaining the IP-rights associated with the in-house written code? There >the cost/benefit balance would be tipped towards non-disclosure. It's hard to conceive of a rational business model that did not recognize the advantage of offloading maintenance of non-strategic code to an open source team. --Brett Glass

2 1

Modified makedep to handle #include <>
by Patrik Stridvall 13 Feb '02

13 Feb '02

I have been working some more on a Makefile.in to .dsp/.dsw converter for working in Microsoft Developer studio and it is comming along fine. Anyway one of the the problems compiling with MSVC using the Microsoft headers is that all Wine only includes in wine/include can't use for example: #include "windef.h" it must use #include <windef.h> otherwise Wine's windef.h in the same directory is used. The problem as you pointed out is that makedep.c can't handle this. Here is a patch so it can. BTW. If you apply this patch or a similar should all .h and .c files be converted or should I just do the absolute minimum ie the Wine specific include (.h files) under wine/include. Files like heap.h for example. * tools/makedep.c: Modified makedep to handle #include <> for the Windows includes correctly. ---8<--- Index: wine/tools/makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.7 diff -u -u -r1.7 makedep.c --- wine/tools/makedep.c 2000/12/13 21:27:26 1.7 +++ wine/tools/makedep.c 2002/02/13 16:40:21 @@ -4,6 +4,8 @@ * Copyright 1996 Alexandre Julliard */ +#include <sys/types.h> +#include <sys/stat.h> #include <ctype.h> #include <stdio.h> #include <stdlib.h> @@ -185,6 +187,31 @@ return file; } +/******************************************************************* + * find_include_file + */ +static int find_include_file(char *name) +{ + INCL_PATH *path; + int found = 0; + + for (path = firstPath; path; path = path->next) + { + struct stat buf; + char *filename = xmalloc(strlen(path->name) + strlen(name) + 2); + strcpy( filename, path->name ); + strcat( filename, "/" ); + strcat( filename, name ); + if (!stat( filename, &buf )) + { + found = 1; + } + free( filename ); + if(found) break; + } + return found; +} + /******************************************************************* * open_include_file @@ -260,6 +287,7 @@ while (fgets( buffer, sizeof(buffer)-1, file )) { + char qoute; char *p = buffer; line++; while (*p && isspace(*p)) p++; @@ -268,9 +296,11 @@ if (strncmp( p, "include", 7 )) continue; p += 7; while (*p && isspace(*p)) p++; - if (*p++ != '\"') continue; + if (*p != '\"' && *p != '<' ) continue; + qoute = *p++; + if(qoute == '<') qoute = '>'; include = p; - while (*p && (*p != '\"')) p++; + while (*p && (*p != qoute)) p++; if (!*p) { fprintf( stderr, "%s:%d: Malformed #include directive\n", @@ -278,7 +308,9 @@ exit(1); } *p = 0; - add_include( pFile, include, line ); + if (qoute == '\"' || find_include_file(include)) { + add_include( pFile, include, line ); + } } fclose(file); }

1 0

wineconf 2002 user submitted agenda topics
by Michael Robertson 13 Feb '02

13 Feb '02

Here's a list of some of the suggestions people have sent in for wineconf 2002. http://www.lindows.com/wineconf It demonstrates where people's interest is and not a confirmation of the agenda or that the proposed speaker has even confirmed. Some have not responded to my email (like Dr. Ulrich Weigand). As you can see, there's no shortage of interesting topics. Please keep sending me your input and I'll incorporate. I haven't made it through everyone's suggestions yet. Company Presentations: ---------------------- Transgaming, Success To Date [Transgaming/State] ReactOS - Where it's at, where it's going [ReactOS/Filby] Corel, A Look Back [Xandros/Tranter] Crossover Strategy [Codeweavers/JW] Macadamian - Making It As A Software House [Macadamian/???] Business -------- WINE's "Most Wanted": Features To Make WINE Great [???] Developer Funding, Who Pays The Rent [???] Future of WINE licensing [CW/White] Technical --------- Development Model [CW/AJ] NORM - The secret weapon [Codeweavers/???] Making Fonts Not Look Like Crap [CW/Timoshkov/Davies] Multimedia And WINE [eric.pouech(a)wanadoo.fr] Regression Testing [???] How To Improve The Debugger [Meissner/marcus(a)jet.franken.de] Maximizing performance of WINE [???] Package streamlining of WINE [???] WinNT APIs (Odin, ReactOS, winNT wine, WINE) [???] DirectX [Transgaming/Kaaven] WINE as a porting tool [Macadamian/Jacques] Native user.dll [Dr. Ulrich Weigand] API Standardization [???] Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

6 5

Licensing response and an idea
by Gavriel State 13 Feb '02

13 Feb '02

Hi everyone, As I mentioned, I have been considering the license issue for the last several days. It is a matter very near to my heart, as I believe that it affects not only TransGaming, but really the entire software industry. This posting is somewhat lengthy, but please bear with me. Open Source software has made enormous strides in the last several years, and incredible amounts of great code have been produced. At the same time, it has been unable to compete effectively with proprietary software vendors like Microsoft, except in those areas where sufficient well financed companies have been able to direct full-time developer resources to the problem. With the wellspring of dot com VC funding going dry, the question arises: where will the money come from to pay full-time Open Source developers? Just imagine where Wine would be without the code contributed by the half-dozen or so companies that have been involved. Imagine where Linux would be without the efforts of the companies paying for dozens of full-time Kernel hackers. And imagine where we could be if just one or two percent of Microsoft's annual $25 Billion in revenue were being directed at Open Source projects. The business models capable of supporting traditional Open Source projects are really rather limited: consulting services, technical support, and selling ancilary products with the software. None of these come close to delivering the levels of revenue that traditional mass-market shrinkwrap software can. So far, it is unclear whether they can support much profit at all for their proponents: RedHat, VA, and others bear witness to that. TransGaming, for one, is working with some new ideas on how to do things differently, and profitably. There are a number of interesting possible approaches out there, and it is important to the entire world that we find models that work. Otherwise we are going to be stuck with the kind of information police states envisioned by the RIAAs, MPAAs, and Microsoft's of this world. Now we are all here because we think that there are better ways to do software than the wholly proprietary approach. We want to be able to look at the code, tear it apart, fix the bugs, and make it cooler. And we want others to have the freedom to do the same. Ultimately, the questions that need answering are these: o What freedoms are important to the community? o Can those freedoms be achieved without sacrificing other goals? o What is the best mechanism for ensuring those freedoms, and ensuring the continued development of the code? The Wine X11-style license essentially allows the code to be used anywhere, in any way. Users don't need to pay, Developers can take bits and pieces as they deem appropriate, and corporations can sell the product in whatever way they feel like. But it also has no legal mechanism to try to coerce further development of the project. Current proponents of an LGPL license switch believe that a legal mechanism is important to protect the project. Frankly, I am at a loss to understand the reasoning behind such a switch. I don't see any way in which any company could maintain their own fully proprietary fork of Wine without doing periodic merges into the public project. It's hard enough for TransGaming to do it despite the fact that we deal mostly in very specific areas. And even if someone was able to do so, how does it affect the Wine project any more than the existence of Windows or MainWin does? At most, it would affect the userbase, but in the current model that doesn't matter, since that userbase doesn't contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop. Marcus Meissner has already shown that the existance of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute that code back, and now we may have no way to recoup our investment. We still have a 2nd pass, more complete DCOM implementation under development, so it is possible that we be able to get a sponsor for that. But regardless, it clearly shows that having code outside the WineHQ tree is no impediment to the community reimplementing it if necessary. The LGPL would severely limit a number of possible commercial applications of Wine, such as: o Companies or groups that might want to take a small bit of Wine code here and there without taking the whole thing. IE: Corel's Mac porting work, or projects like MicroWindows or Odin (similar projects like Xine and ReactOS use parts of Wine this way, though they're GPLed, and thus would not be affected). o Porting Wine to platforms with NDAed APIs. Or commercially oriented ports to other platforms which might not be viable under the LGPL. o The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work. o New business models like TransGaming's, with conditional-future- release of code. While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back. I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code. I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about. Here's the quick and dirty version: o A new non-profit company is created: WineCorp o Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases. o WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed. o WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things: - Releases source modifications to WineCorp immediately. - Releases source modifications within a preset timeframe (maybe one year). - Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit). - Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development o For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL. o WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's. One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion. Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests. Food for though, anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

3 3

Re: Licensing response and an idea
by Roger Fujii 13 Feb '02

13 Feb '02

Gavriel State <gav(a)transgaming.com> wrote: > > You did not mention whether you want to have this > > license only or to have Wine licensed also with some > > open-source license? > > > > I think in this case even GPL can be a choice for the > > second license. > > Under the WineCorp approach, the AFPL + an allowance > for commercial redistribution if Wine code is returned is > essentially equivalent to the LGPL. It's more flexible though, > since it allows for the possibility of other unforseen ways in > which commercial redistribution without immediate release > of source would be possible. > > It would also be possible for the WineCorp to allow certain > portions or all of the code to be dual-licensed under the LGPL > and mixed with other GPL or LGPLed projects. I think that you'll find considerable resistance from the *GPL people, but you do bring up a good point. If there is going to be a license change, it would probably be wise to require that the copyright of future submissions go to a single (or small #) of people. That way, you can revert the licensing terms if you change your mind. -r

1 0

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

Lindows.com and open source
by Michael Robertson 12 Feb '02

12 Feb '02

Claude, >From: Claus Fischer ("claus.fischer(a)clausfischer.com) >If the current license allows Lindows to make proprietary >modifications and not give anything back, it certainly >allows Codeweavers/whoever to make proprietary modifications >and give back under LGPL. > >Those who don't want to even read LGPL code for reasons of >'contamination' just shouldn't read it. You can't read Lindows >code either. > >Why should Codeweavers be morally pressured to contribute under a >steal-me license when steal-it companies don't contribute at all? Just to set the record straight. Lindows.com has had a partner company producing the majority of our WINE code. The vast majority of the code that came from that partnership is in the public tree already. Lindows.com has contributed code to open source projects. We have hired open source companies (spending over 500K) to help us reach our goals with the majority of the code going back to open source. Lindows.com has given financial support to several open source initiatives (such as KDE). Lindows.com has made significant investments in linux companies. All told, we've spent about 2 million in the 5 months that we've been a company. Linux (and all the other pieces) does 95% of what people want to do today, but only has 1% market share. Our belief is that the code is largely not the limiting factor for adoption now. It's all the pieces that go around the code. It's education, it's marketing, it's lobbying, it's business development, etc. These are big tasks which are critical to success, even more so than the code itself (think AOL). I know this won't be a popular thing to stay on a mailing list with "devel" in the title, but it's where we believe linux is and what we believe needs to happen to get to the next level. This doesn't mean the code isn't important, it is but there are other critical elements. We need Lindows.com and 10 more thriving companies to help with the expense of educating, lobbying, marketing, etc. desktop solutions. It's expensive to do those things and a burden that needs to be shared by several companies because the job is so enormous and the competitor so strong. The Linux community, especially the desktop community needs healthy ongoing companies to put in capital, organization, and other support. If we can put a few million more people running Linux on the desktop, then magical things will happen. Drivers for linux will be available, higher quality linux software will emerge, more OEMs will offer linux as an option, devices will have linux interfaces, governments will view linux differently, etc. There are some small, but meaningful for-profit companies out there today in linux (such as codeweavers and transgaming). The more companies in the linux desktop space there are, the more companies that will be able to pay their rates on an ongoing basis and hire them to code great products. There's tremendous opportunity and the more companies out there the better. As for our marketing message, it's designed for my Grandma. Anytime there's a word on the website she doesn't understand she calls me up. Try explaining a recursive acronym to your Grandma. Yikes. Our goal with Lindows.com is to bring Linux to the segment of the world who thinks linux is spelled with a 'y' and is a small bobcat. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 2

Keep filling my mailbox please
by Alexandre Julliard 12 Feb '02

12 Feb '02

Folks, First I thank everybody who mailed me in reply to Jeremy's request, I now have a clearer picture of where the community wants to go. However, I still haven't heard from a number of contributors; so if you haven't sent me your opinion yet, please do it now, so that we can reach a conclusion soon and hopefully return wine-devel to its original purpose. As a reminder, the question Jeremy asked is the following: > Should the Wine project switch to a license which has as > its goal to attempt to secure some form of Copyleft > protection for Wine while still permitting proprietary > software to link and bind with Wine? Just let me know privately whether you agree with that or not. If you don't care either way, or aren't decided yet, please tell me that too, I want to make sure I know where everybody stands on this issue. Thanks. Note: everybody is welcome to send me their opinion, even people who didn't contribute code. Of course the opinion of people who have contributed will carry more weight in the final decision, but I think everybody should have a voice. -- Alexandre Julliard julliard(a)winehq.com

4 3

RE: Direct 3D 8.0 Wrapper for OpenGL Open Sourced
by Patrik Stridvall 12 Feb '02

12 Feb '02

> 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. Some of the file have the following copyright: ; * Copyright © Realtech VR 2001 ; * ; * Permission to use, copy, modify, distribute and sell this software ; * and its documentation for any purpose is hereby granted without fee, ; * provided that the above copyright notice appear in all copies and ; * that both that copyright notice and this permission notice appear ; * in supporting documentation. Realtech makes no representations ; * about the suitability of this software for any purpose. ; * It is provided "as is" without express or implied warranty. But some of the files have another copyright: * Copyright (C) 1995-2001 Microsoft Corporation. All Rights Reserved. Yet some files contains no copyright notice at all. I wonder the license status of the whole thing really is. We should be very careful before including something like this. Beside it is for most parts in C++. That can of course be fixed but it would require some work.

1 0

RE: Wine license change
by Patrik Stridvall 12 Feb '02

12 Feb '02

> Patrik Stridvall wrote: > > > > > Francois describes the central issue well: the LGPL will > > > provide a way for the vendors to trust each other. > > > > > > Let those of us who understand this simply start releasing > > > our Wine changes under the LGPL, regardless of what anyone > > > else does. That should make it clear which way the main > > > tree should go. > > > > First of all what "those of us"? You mean "those of you"? > > Searching the mailing lists I see that you from time to > > time have provided various testing, suggestions or > > other information but I can see no patches. > > Ask Jeremy White if he thinks I've been contributing to the cause > lately; I bet he considers the stuff I've written lately to > be helpful, > even if it doesn't appear in the tree. OK. I got a little carried away. Sorry. > > Secondly understand what? > > Understand that the LGPL enables competitors to trust each other. Yes, I understand that you think the LGPL will enable competitors to trust each other. However if wrapper libraries are allowed all such bets are off. You could just implement whatever you think gives you the competative advantage in a seperate library under a proprietary license and just release the wrappers. In fact some things actually makes sense to have in a seperate library maintained seperately from Wine. Of course it would be preferable if such library was under a Open Source license, but then if the LGPL can't enforce this then I can see how you can claim that any trust must exists. Consequently you must believe that the LGPL can enforce this and since you claimed not only you believed that it would, but used the word understand, I assumed that you REALLY understand how the LGPL works. But from the statement below it seems that you don't, do you? > I can't address your and Roger's concerns about the LGPL > effectively because we seem to have such different world > views that communication is difficult. My apologies; I'm > just not a good communicator sometimes. What different worlds view? If the LGPL in unambigeous it means one and only one thing in the world of law, the only world that counts. So never mind what I believe or see the world, explain what the LGPL means the world of law. You said you understand it enforces trust, so please explain why? Never mind that you seems to believe that we wouldn't understand it. Please explain it to the world, I'm sure somebody will understand it.

1 0

Re: Lindows.com and open source
by Michael Robertson 12 Feb '02

12 Feb '02

>John Alvord <jalvo(a)mbay.net> At 02:11 PM 2/11/2002 -0800, you wrote: >Maybe you could shed some light on the current License flamefest. >Would BSD versus LGPL have made any difference to you progress as a >company? You have contributed so much in the past, a formal statement >of intentions could reduce the perceived problem... I'm not sure Lindows.com has earned a voice in the license debate yet or even if we had a voice could add anything meaningful that hasn't already been said. There are many others who have for years shepherded WINE to this stage. I'm confident they'll do the right thing. Licensing is a topic on the wineconf 2002 agenda. I'll be sending a list of topics to the list shortly for feedback. Thanks to those who have offered suggestions. From a more general perspective though, I believe there needs to be much more investment in many areas of WINE and more broadly Linux to get to the next level (say from 1% penetration to 10%). Anything that gets more people involved, more organization, more developers, more capital, more companies, and more ideas will ultimately be a good thing. When I was at MP3.com, we had the MP3 summit every year. We invited everyone including our direct competitors, tangentially related industries and even our antagonists. We'd not only invite them, but also encourage them to speak. Our thinking was the more people that we got making "neural connections", the more success MP3 would have (and ultimately MP3.com). Companies were created, merged, and bought because of the MP3 Summit. Products were dreamed up and built because of the MP3 Summit. It wasn't about our company, it was about bringing all the smart, passionate people together (even if they had opposing viewpoints) and watching the magic happen. I believe Linux and WINE (at least on the desktop) are at similar stages. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

2 1

RFC: Re: Problem with COM (fwd)
by lawson_whitney＠juno.com 12 Feb '02

12 Feb '02

---------- Forwarded message ---------- Date: Sun, 10 Feb 2002 21:32:31 +0100 From: "[iso-8859-2] Du¹ko Rusmir" <drusmir(a)gmx.ch> Reply-To: wine-users(a)winehq.com To: wine-users(a)winehq.com Subject: Re: Problem with COM Dana nedelja 10. februar 2002. 04:11 napisali ste: > On Sun, 10 Feb 2002, [iso-8859-2] Du¹ko Rusmir wrote: I must use 5726, 5760 and 9600. My app need this to work. On 4800 and 9600 I got error. With other app I can use 38400, 57600 and 115200 wery well. I thing the handling of COM Port on these BaudRate is't good. Thanks -- trace:comm:BuildCommDCBAndTimeoutsA (COM1: baud=5760 parity=N data=8 stop=2,0x405608ac,(nil)) trace:comm:SetCommState handle 64, ptr 0x405608ac trace:comm:SetCommState bytesize 8 baudrate 5760 fParity 0 Parity 0 stopbits 2 trace:comm:SetCommState ~IXON ~IXOFF err:comm:SetCommState baudrate 5760 Now nobody is going to convince me there is any software that will make a normal 16550a run at 5726, but with effort I managed to explain the linux setserial spd_cust kluge, and at last report the app was working: /dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4 Baud_base: 115200, close_delay: 50, divisor: 20 closing_wait: 3000 Flags: spd_cust skip_test trace:comm:BuildCommDCBAndTimeoutsA (COM1: baud=38400 parity=N data=8 stop=1,0x405608ac,(nil)) trace:comm:SetCommState handle 76, ptr 0x405608ac trace:comm:SetCommState bytesize 8 baudrate 38400 fParity 0 Parity 0 stopbits 0 trace:comm:SetCommState ~IXON ~IXOFF trace:file:ReadFile 76 0x405607d0 255 0x405607c4 (nil) trace:file:ReadFile 76 0x405607d0 255 0x405607c4 (nil) trace:comm:EscapeCommFunction handle 76, function=3 trace:comm:EscapeCommFunction SETRTS trace:comm:EscapeCommFunction handle 76, function=4 trace:comm:EscapeCommFunction CLRRTS Now I am not particularly fussed that Wine should be exactly as Windows, and I am willing to try to explain (again) the spd_cust kluge in Wine doco, if I don't have to use sgml, but I wonder if it wouldn't be better in the long run to figure out what Windows does with off-brand speeds like this (little help? I don't have any Windows.) and cobble up a TIOCMGSERIAL/TIOCMSSERIAL to handle them, at least for Linux. Anybody know how to do a ./configure test for an ioctl? Oh.. looks like we already have some. I guess I can figure it out. 5760 is easy, I believe that is just a divisor of 20, but 5726? Does it round up to the next possible speed? Round down? Count the feet and divide by 4? Lawson

1 0

Re: Wine License Change
by Claus Fischer 12 Feb '02

12 Feb '02

As a non-developer, I think this discussion can be considerably shortened by just forking and starting to work on the LGPL branch. If the current license allows Lindows to make proprietary modifications and not give anything back, it certainly allows Codeweavers/whoever to make proprietary modifications and give back under LGPL. Those who don't want to even read LGPL code for reasons of 'contamination' just shouldn't read it. You can't read Lindows code either. Why should Codeweavers be morally pressured to contribute under a steal-me license when steal-it companies don't contribute at all? Just let Codeweavers use their rights that you defend so vehemently for others, and don't critizise them for doing something your favourite license permits. ****** I personally tend to think that GPL style licenses attract more developers and create a level playing field even for companies as contributors. Put a snapshot of current CVS somewhere for X11 freaks and start checking in LGPL. And don't discuss with morons, especially non-developers ... :-) Claus -- Claus Fischer <claus.fischer(a)clausfischer.com> http://www.clausfischer.com/

2 1

RE: Wine license change
by Patrik Stridvall 12 Feb '02

12 Feb '02

> Francois describes the central issue well: the LGPL will > provide a way for the vendors to trust each other. > > Let those of us who understand this simply start releasing > our Wine changes under the LGPL, regardless of what anyone > else does. That should make it clear which way the main > tree should go. First of all what "those of us"? You mean "those of you"? Searching the mailing lists I see that you from time to time have provided various testing, suggestions or other information but I can see no patches. Secondly understand what? If you are so clever that you REALLY understand what the LGPL means, please enlighten us poor ignorant people. In particular answer Roger Fujii's challenge: I challenge anyone to show me what "work that uses the library", "work based on the library", and "whole" means in the context of wine. The problem is that I'm pretty sure you can't. In any case the trust mechanism of LGPL is dependent on the how the license is interpreted. If you are not certain or pretty sure how a judge or jury will interpret the license, all trust issues are meaningless. Futhermore I have tried to show that you can't both have the cake and eat it. In order for the LGPL or for that matter any license to provide the "trust" that you are after you must also prevent things that are quite reasonable to assume are legal. Like Joe Hacker using his proprietary library to get another proprietary application to run under Wine in order to avoid dual booting and share it with fellow hobbyists. Even if you dismiss this as "Oh well, even so I think it is worth it.", I have another question: How is this compatible with freedom 3 of the free software definition? Free Software Definition (freedom 3): The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.

2 1

Wine Developer License Test
by Ove Kaaven 11 Feb '02

11 Feb '02

Take this test and find your preferred license. A few simple questions can reveal your stance. Fun for the whole family! 1. Do you maintain that information (code) should always be free, no matter how expensive or difficult that information was to come up with, no matter how limited applicability it may have, and no matter how damaging freeing that information might be for the industry, both good and bad? a) yes b) no c) maybe points: a = 2, b = 0, c = 1 2. How should people that come up with such information (coders) be rewarded for their efforts? a) tangible goods (money) b) name recognition in the liberation army (free software enthusiasts) c) name recognition in the rest of the world d) feeling good about themselves (no reward at all) e) I really don't care about them, I just want the code points: a = 0, b = 2, c = 0, d = 1, e = 2 3. Would you like it if your work was incorporated into cheap, mass-produced, proprietary, commercial consumer devices, like cell phones, game consoles, microwave ovens, or home-grown nuclear power plants? a) yes b) no c) I don't care points: a = 0, b = 2, c = 1 4. Do you care about users? a) yes, I would like to have many users, and listen to their needs b) no, I'm the developer, I do the work, it's my way or the highway c) mostly, but not at all costs, I don't mind losing a few points: a = 0, b = 2, c = 1 Results: 0-1: I feel the X11 (BSD) license makes the world a better place 2-3: While not perfect, I think the X11 (BSD) license does give users a fair choice and encourage wide use 4-6: I am somewhat suspicious of my users, so I think the LGPL license makes it easier to herd them 7-8: Freedom above all; I elect RMS for president, and prefer the GPL

2 2

ScrollBar/Cannot use first megabyte
by Phillip Ezolt 11 Feb '02

11 Feb '02

Hi All, Here's a little break from the license wars. When I run the example contained in 1902.exe from: http://msdn.microsoft.com/library/en-us/dnwui/html/msdn_scroll32.asp?frame=… I receive the following error: "err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report" Interestingly enough, the test program for scroll bars works much differently on Windows NT than on Wine. The scrollbar example includes both source and executable as well as documentation about some Windows scrollbar bugs. If I knew a little bit more about windows programming and/or Wine, I'd fix it.. --Phil Compaq: High Performance Server Systems Quality & Performance Engineering --------------------------------------------------------------------------- Phillip.Ezolt(a)compaq.com Performance Tools/Analysis

1 0

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

11 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote: > > If you are using marketing speak for "contribute". GPL requires 1) > > for you to show your work 2) You effectively license your software to > > the FSF. It doesn't say it has to be in any useful form to be worked > > back into the originating project (if any). > We're talking about the LGPL, not the GPL. true with either. Your "contributions" must be licensed as LGPL/GPL. > The rest of this paragraph shows a serious disconnect with the text of > the LGPL. Have you actually read the license in question? 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. > "Source code" for a work means the preferred form of the work for > making modifications to it. For a library, complete source code means > all the source code for all modules it contains, plus any associated > interface definition files, plus the scripts used to control > compilation and installation of the library. If you are contesting the "useful form", let's say I did this: Took the original GPLed code and run it through a lexical translator so that all labels and such are changed. Make my changes with respect to THIS codebase. Now publish this. This AFAIK, fulfills the technical requirement of the *GPL, but it certainly isn't a usable form. > > Here we go again.... If this is *all* it did, LGPL is far less objectionable. > > The problem with *GPL is that it also regulates the UNMODIFIED use of the > > software. > > The creation of derived works does not constitute "unmodified use of the > software" under any legal definition I've ever seen, if that's what you're > referring to. no, it's this phase: Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. > > Freedom means allowing people to do things, even things that you don't > > agree with. BSD = Free. GPL is not. Call a spade a spade.... > > Nonsense. To extend your definition to the proper conclusion, it's not > Free unless it's placed in the public domain, you are ABSOLUTELY right. The spectrum is PD->BSD->GPL-------->Propriatary. But then, things in the PD really isn't licensed, so X11/BSD is probably as close as one can get. > and any software license that permits you to maintain any portion of your > copyright is a fraud if it claims to be Free. If you really cared about > giving absolute freedom to the users of code that you write, you would > place all of your code in the public domain. 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. > Not planning to do that any time soon? stuff that I have put back into projects go with the license that it's under. All of the changes I've put back goes back with *no* restriction (ie. it's PD as far as I'm concerned). > Then spare us the bullshit arguments about the BSD being Free and the GPL not. > (Yes, it is bullshit. Call a spade a spade, right?) geez. no need to get bent out of shape. I'll rephrase and say BSD is MORE free than GPL. Happy? > All Free Software licenses attempt to find an equitable balance between the > freedoms and rights of the authors, and the freedoms and rights of the users. this statement is true of licenses in general, with the freedoms/rights of the user declining along that freedom spectrum. In the US (forgetting the DCMA for the time being), the freedoms and rights of the authors are guarenteed by law (1st amendment/copyright). What I philosophically object to is using the freedom argument WRT GPL, since the freedom of the author is never in question, while the freedom of the user is curtailed. I have no problems in saying it's equitable, fair, desirable <insert socially desirable adjective here>, even "right" - just not 'free'. > You are free to favor one balance point over the others, but that doesn't make > other licenses and other balance points non-free. my dictionary says one of the definitions of freedom means "unrestricted use". So it's fair to say something that has MORE restrictions is LESS free, or are you arguing that GPL is more "free" than PD? > But neither philosophy nor politics is the issue at hand. The issue at > hand is whether the LGPL, or a similar license, would be better or worse > for growing the Wine community. For that, there are good arguments on > both sides. we agree. > On the other side, companies like Lindows.com don't impress me as bringing > any added value back to the community -- they may succeed in increasing > the percentage of non-Windows desktops in the world, but the current Wine > license makes it possible for all the profits from their OS to pad the > wallets of marketroids, sales critters and smooth-talking business execs, > without contributing anything back to the Wine tree. I have no problem at > all with the idea of eliminating that particular business model. 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. > > If this is the goal (it certainly is mine), then *GPL is not a good choice, > > because it would interfere with deployment (*GPL wouldn't allow being bundled > > with the playstation2 or other HW platforms as an example). If acceptance > > is the goal and you care about wine in a non-linux context, stay with > > BSD/X11. If you don't care about expanding the pie, go *GPL.... > > Please write what you mean, which seems to be "Sony would never accept the > terms of the LGPL, which would prevent them from being able to bundle Wine > with the PlayStation2". Again, I don't see where this would be a loss. > Companies that are unwilling to contribute back to the community are not > any concern of mine; if they want to compete with Microsoft on the > desktop, let them fund their own software development instead of leeching > off of the community. My only concern with the LGPL is making sure that > well-intentioned companies that DO give back to the community aren't > caught in the middle. Let's say the playstation distributed wine for every PS2 that shipped. If only .001% of its users (and these are gamers) get interested in wine, that's 200 additional contributers. Most people get involved with a project because they USE it initially. So, it's reasonable to say that wine is still better off if sony distributed it without contributing *anything* (maybe had had to make NO changes, who knows) because of the additional interest. You might not consider this a loss, but to me, it seems like it is. -r

3 2

Yet the parameters problem (WAS: CreateProcess API - undocumented use)
by Ricardo 11 Feb '02

11 Feb '02

Ok, I've tried everything. Change the API used (GetStartupInfoA to GetStartupInfoW), changed the code, but I have no idea where to change in wine to, when I have 2 programs, doesn't loose the passed parameters. Here's how it works: PGM1 starts and ask the username and the password. If it's ok it writes FILE1.DAT and FILE1.IDX with settings to PGM2 to run. These files are wrote correctly, but PGM2 can't read them. When PGM1 finish wine seems like "closing" and than star over with the PGM2 (called by PGM1 with the parameters writen (API CreateProcess)). But PGM2 starts without any parameters (API GetStartupInfo) and without the parameters it cant run, so the program exit. I've already checked 3 files: loader/module.c, scheduler/process.c and memory/environ.c. And compared it with the MSDN Library, and the codes are the same, so no problems with it. How does WINE deal with a program calling another one? thanks Ricardo

2 1

Re: Make Home, End and Enter on the keypad work in the debugger
by Eric Pouech 11 Feb '02

11 Feb '02

Dmitry Timoshkov a écrit : > + {/*VK_END*/ 0x23, WCEL_MoveToEnd }, > + {/*VK_HOME*/ 0x24, WCEL_MoveToBeg }, those two ones are already in Win32KeyMapExtended, so I don't see no reasons to add them twice A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Dr. Seuss, licensing, and WINE
by Brett Glass 11 Feb '02

11 Feb '02

[Note: This is a slightly revised version of some material which I've posted to Slashdot. Copy replies to me, as I am not on the wine-devel list (though I have been an active advocate of WINE and will continue to be so long as it is not licensed under a viral license such as the LGPL). -BG] This entire issue is reminiscent of the well known Dr. Seuss story "Horton Hatches the Egg." In the story, a bird lays an egg and then convinces a kindly elephant named Horton to sit on it. Horton braves all manner of hardships -- heat, cold, even the indignity of being captured and displayed as a freak in a circus -- to remain with his charge until it hatches. Whereupon, the bird immediately demands that Horton return the fruits of his labor to her. (Were she a modern Richard Stallman, she might have declared that it was a GPLed egg.) Writing a program -- like laying an egg -- isn't necessarily an easy task. However, bringing it to the marketplace and successfully selling it as a product -- especially in the presence of a free alternative -- is a much more difficult and dangerous one. The company that hopes to sell a product that's an improved derivative of one that's available for free is taking a big risk and must make a truly Hortonian (if I may coin the phrase) effort to be successful. What Mr. Stallman and the (L)GPL would demand is that the person who manages to do this -- competing against all odds with a no-cost version and potentially infinite numbers of competitors publishing and bundling it -- get nothing. Those who wish WINE to be published under a license which is not truly free, as the current license is, appear to believe that the emergence of products such as Lindows is a threat to WINE and/or to businesses such as CodeWeavers. Nothing could be further from the truth. If the creators of derivative works act in their own best interests, they will return all but the most strategically important code from their implementations to the WINE project, reserving for themselves only what is necessary to differentiate their product from what another vendor (e.g. Red Hat) might produce. This minimizes their maintenance costs, and may -- there's no sure thing here -- provide them with sufficient value added to survive in the presence of a free alternative. (If they don't do this, there is an automatic penalty: they'll have to re-integrate changes into each new version.) To (L)GPL WINE, on the other hand, prevents such worthy products from ever seeing the light of day. It is, in essence, snatching back the egg from poor Horton after all of his hard work. And it won't benefit WINE, WINE users, or CodeWeavers. Many companies' potential contributions will be lost, and CodeWeavers and WINE will gain themselves a reputation for being hostile to business. This will cause the consulting business from which CodeWeavers hopes to make money to dry up. In short, the move is shortsighted and bad for all concerned. CodeWeavers, and other companies that hope to profit from their work on WINE via paid consulting, should look instead to the model of Wasabi Systems (http://www.wasabisystems.com/ [wasabisystems.com]), which just received a round of venture capital funding worth more than $1M to port, publish, promote, and consult on NetBSD. NetBSD is truly free; it's published not under the restrictive GPL or LGPL but under the BSD License. And Wasabi is going strong; they just published a desktop package (consisting of NetBSD plus GUIs and applications) that is competitive with the best of the Linux distributions. The WINE project, for its part, should resist falling prey to the spite and resentment that the Fascist^H^H^H^H^H^Hree Software Foundation encourages (and has made part of its licenses). If the project makes the mistake of adopting an FSF license, commercial programmers such as myself will no longer be able to so much as look at the code -- much less fix bugs or contribute. This license change would, effectively, close WINE to me and any other developer who writes commercial software... forever. Here's why. As most people already know, the GPL and LGPL require developers who create "derivative works" to give their work away for free. But what most people do not understand is that if a programmer so much as looks at GPLed or LGPLed code, and later writes some code that performs the same function, he or she is open to accusations that the code produced later is a derivative work. (The late ex-Beatle George Harrison fell into a similar trap when he heard a song and, years later, wrote one with a similar melody. A court convicted him of "unconscious" copyright infringement because he'd heard the original song.) For this reason, commercial programmers simply cannot look at source code that's published under one of the FSF's licenses without taking a tremendous risk which could destroy their careers as programmers. This may be fine with Richard Stallman -- who in the GNU Manifesto stated that programmers should code for love rather than money and that good salaries for programmers should be "banned" -- but for those of us who need to put food on the table it is simply a risk we cannot take. Thus, if WINE is (L)GPLed, I can no longer look at the code, fix bugs when something breaks, or contribute to the project. Nor can I peruse the code in order to learn from it. It will, effectively, be as closed as a closed source product to me and to any other commercial programmer. WINE will be un-free and would not be open source (since it would be licensed under a license that discriminates against a group of people and a field of endeavor). Only a truly free fork (which I sincerely hope will occur if the license is changed) will be accessible to those of us who code for a living. It would be a sad day for those of us who would LIKE to continue to recommend WINE to users who wish to free themselves from Windows, as I would immediately have to stop installing and advocating the use of WINE. --Brett Glass (Who hasn't happened to contribute to WINE yet, but may do so if it remains open source)

9 17

I see no reason to change the license
by Sean Farley 11 Feb '02

11 Feb '02

Thinking it over. I see no benefit for a change to the LGPL. The main reason was to force companies to give WINE their changes and/or additions to the code. As several people have pointed out, they can get around this by writing API wrappers. Doing so they will have removed the only reason the LGPL was proposed in the first place. It would be quite easy to keep in sync with the WINE code base. A PERL script (or whatever) could be written to output a wrapper file. Another script could be used to make changes to any future code base to make use of the wrapper calls. As someone who did this for my last company (JAVA API using JNI calls to mirror their own C library), I can say this will take a minimal amount of work. They would only need to release the changes they made to the code (just the wrapper calls). If you want to force the code out of others, a much stricter license than the LGPL or even the GPL will be required. Can anyone recommend one and have it still be open source? Sean -------------- scf(a)farley.org

2 2

Wine, enthusiasts, businesses and the agony of the license
by Fredrik Ohrn 10 Feb '02

10 Feb '02

(I'm a part time lurker on wine-devel and use Wine to run those pesky apps I can't live without. I regret that I've never mustered the courage to work on and contribute to the code.) What's lacking in this discussion is some sensible analysis of what a license need to contain to encourage future contributions to Wine and to protect the interests of the contributors. Fearmongering about Wine's future and paranoid delusions about the GPL license doesn't bring anything to the table... First, what is needed to please the enthusiasts that write code on their free time? As the variety of open source projects show, the exact license doesn't matter, as long as the source is available and there is a reasonable chanse to get your work included in what is perceived as the "main" distribution, there's plenty of people around that want to lend a hand. Ofcourse, looking at individuals they have preferences, some prefer the (L)GPL and other the BSD style and still others don't even get what all the fuss is about. The point I'm trying to make here is that there's no predominant license preference among the enthusiasts, so one can go either way. Ofcourse a change will make some people jump ship, but it also opens the door to new people who wouldn't have contributed under the old license. Now over to the $64.000 question, how can one convince companies to do the heavy lifting and still get them to share the result? There are 2 obvious ways to make money of Wine. Either you take it as is, package it and sell it as the ultimate Windows replacement (think Lindows and TransGaming). Or you use it as the base to port your existing Windows application (think Corel). And I'm sure there are several not so common ways, like cherrypicking functionality to create the greatest MS-DOS based registry editor ever made (don't laugh, I had to make something up). A viral license would more or less kill the first way. Just as Brett Glass pointed out, one has to add some secret sause that makes your product more valuable than the free version of Wine. For example, Lindows has to fix all bugs and implement everything that prevents Microsoft Office from running properly, and keep this magic patch to them selves. The BSD style is an obvious requirement for this business model to work. Unfortunatley, this is very much at odds with the community, who are working on Wine with the very same goal. To pharaphrase a previous poster, Lindows is standing on the shoulders of a giants and the current license is handing them the coat. The fact is, that neither (L)GPL or BSD style solves this dilemma, if they are allowed to keep thier changes secret it won't do anything for Wine as a whole. If you force Lindows to release their work it will remove the reason for them to do anything in the first place. TransGaming belongs to this group too. Flame me all you want, but the only difference between Lindows and TransGaming are thier long term intentions, outspoken or implied. Over to category two. Corel's source of income isn't from improving Wine, it's from selling their own work, Wine just makes their work more valuable. Here it doesn't really matter if Wine is BSD or LGPL (remember that the INTENT of the LGPL isn't to infect all and everything). A company that chooses this route may have to improve Wine here and there to fill in the missing pieces to make their port work, and by releasing this patch they will contribute to Wine as a whole. Unfortunatley they might not, don't underestimate the power of laziness. One other plausible reason is that some bean counter is afraid that someone else will pick up their work for free and make money out of it (i.e. Lindows) how'd you explain that to your shareholders? If Wine is LGPL they must release the patch if they want to reap the benefits of using Wine, and they can release it without fear of giving away money to someone else. It can even be argued that the LGPL makes Wine an even safer bet, since it guarantees that other companies in this group will chip in, this way Wine will be in even better shape when the first application was a smash hit and they decide to port their next app! :) Companies that decide to develop a new app and use Wine as the cross- platform framework also belongs to this group. Back to Wine again, the selfish motive here is to make Wine better faster. So if we get the choose between companies in group 1 or 2, who will contribute the most? Obviously the ones in group 1 will do the most work, since their living relies on a perfectly working Wine, unfortunatley they have the least to gain from contributing anything back. The companies in group 2 have the least incentive to work on Wine, just fix the bare minimum to get their application to work, but instead they can allow themselves the luxury to contribute and score some goodwill. Another observation is that companies in group 1 are in direct competition with each other, so they want closed source. If TransGaming released their DirectX work BSD style, Lindows would quickly be there to appropriate it. Companies in group 2 arn't competing directly (not to the same extent anyway, they have the entire application market to play on, not just the niche of making the perfect Windows replacement) so they would benefit from a license that enforces sharing. So what's the conclusion? Either you pick your favourite way of making business and lobby for a compatible license, or you start thinking out of the box and find the perfect balance that let's everyone keep the cake and eat it... I'll be back tomorrow with more opinions, and my stab at thinking out of the box. Regards, Fredrik -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams Fredrik Öhrn Chalmers University of Technology ohrn(a)chl.chalmers.se Sweden

2 3

Time for a Fork
by Dan Kegel 10 Feb '02

10 Feb '02

It seems clear to me that Wine is just like Unix: some people prefer a BSD license, and others prefer a GPL license. BSD can never convince Linux people to switch licenses, and vice versa. So be it. Rather than endlessly debate the issues, I suggest we simply agree on an amicable parting of ways. The current cvs tree and patch mailing lists would remain as is. A new LGPL-licensed tree and associated wine-lgpl-patches mailing list would be created to accept LGPL-licensed patches. This would put an end to a lot of bickering, and would let us see how the two license agreements work out in practice. Comments? - Dan

6 8

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

10 Feb '02

Daniel Sabo <sorry(a)nospam.com> wrote: > [snip] > > geez. no need to get bent out of shape. I'll rephrase and say BSD is > > MORE free than GPL. Happy? > [snip] > > Neither the BSD or GPL is free, only public domain is free. The problem with PD software is this screwed up litigious era we live in the US, it is conceivable that you could get sued for a bug in a PD software you wrote. So, the author isn't free from litigation in this case. The minimum you would probably want is X11/BSD which 1) says it's AS-IS 2) requires the copyright to be preserved (pretty much requried by law) 3) says you can't use the copyright holder in advertising. > BSD and GLP are both contracts with the users. a license is required so long as there is a copyright. > BSD means "you must include my licences information with anything you make". > *GPL means "if you make something from my code you have to share it with everyone". well, add the BSD portion to GPL and change the word "share" to "show" (since GPLed software cannot be shared with propriatary linkages) and add "and license it to how I originally licensed it". > Which on you use doesn't depend on freedom, it depends on your goal. true. though the point I was making was BSD *IS* freer than GPL. > I prefer GPL becuase I see getting back what others make as payment for my > work, and yes, I know I'm being selfish. no one is arguing this point (at least I don't think). The question is whether or not is this would result in a more complete wine since a *GPL license WILL drive away commerical people. > [snip] > > In case you hadn't noticed Sony let's you run _Linux_ on a PS2, did that > change to BSD without anyone telling me? Big companies like *GPL because > they know where they stand and they don't loose an advantage by giving > back. Sun and IBM both support *GPL projects, so does SGI and a lot of > other very large players. interesting, though not sure how sony gets away with (from CNET): The programming blueprints, or source code, for the kernel --the heart of Linux--is included on the DVD, Sony said. But the source code for a proprietary "runtime environment" that lets games play on the system is not. As for the BIG players, they get involved with all sorts of projects (X11, propriatary CDE...). The license they choose depends on what they are trying to promote (just like people). Also notice a lot of these large companies will also issue a multiple license scheme, since they see the *GPL as a right fit in some cases. "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> wrote: > Okay. Let's look at this. > > The main objections seem to be based off two debatible premises: > a) LGPL will stop commercial development Hinder, and this is NOT debatable. Look at the last time this was discussed and Gav's response. > b) FSF > > Please, just because you hate the FSF, there is no reason not to accept > the license they use. Using the LGPL does not give the FSF -any- control > over Wine. Even less if you do not give a "or any later version" clause. No, but you may not be able to accept the terms of the license (for legal reasons). Read the paragraph of section 6. > Also the fact that LGPL will stop commercial development is a false > assumption. WINE is the main application. Wine uses several LGPL > libraries. If the main Wine executable is still BSD licensed, you can > replace the LGPLed libraries with your commercial version. Etc, etc. if one wants to go through the headache of maintaining different licenses in the same tree, I suppose this would work. However, if ALL of wine is LGPLed, it is not debatable that no propriatary additions can be made, as the spec compiler will prevent that from happening. > John Carmack made an intresting point, he releases ID softwares older > releases under the GPL. Why? Because after originally releasing an engine > after a BSD-esque license, a project done some very major work to the > engine... and then lost it in a harddrive crash. So his -main- reason for > using the GPL is to prevent work done in the community from being lost. not quite true, as he threatened to sue into oblivion a couple that violated the GPL. > There are of course other points. The LGPL is the GPL without the > restrictions which prevent useful commercial use. LGPL is GPL that grudgingly allows any non-propriatary linkages. > Thus RMS complains it isn't real "open-source"... Neither the LGPL or GPL > prevents charging for software, ??? Read 2C of LGPL. You can charge for the disk, but you CANNOT charge for the software. -r

2 1

Font issue
by Eric Pouech 10 Feb '02

10 Feb '02

latest freetype patch severly breaks Wine: - behavior between Windows TT fonts and X11 font isn't orthogonal. For example, EnumFont can return X11 fonts, while realizing a font never let you use a X11 font - this leads to very interesting effects like asking for a fixed pitch font and getting a variable pitch one so what would be the best fix ? either remove all X11 fonts in enum, or allow X11 fonts to be realized even if freetype is enabled ? any volunteer to fix it ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 4

Re: Dr. Seuss, licensing, and WINE
by Roger Fujii 10 Feb '02

10 Feb '02

David Elliott <dfe(a)tgwbd.org> wrote: > And for most free software projects I think it is morally defendable to > prevent people from even linking to them or using them in any proprietary > software. So, you're saying that GPLed software could not be distributed running under windows, macos, UNIX(TM).... Nice to know that you think linux is right for everyone. > The very nature of moving to a license like the LGPL means it will be > complex. This doesn't mean it has to be incomprehensible (and it isn't) > it just means it'll be complex. complex isn't the right word here. The problem is that it is UNCLEAR in certain places. I challenge anyone to show me what "work that uses the library", "work based on the library", and "whole" means in the context of wine. > If you take the average software company, more likely it'll be spent on a > private jet for the CEO. your "average" company must be considerably larger than any of the companies I worked with.... -r

1 0

Re: Time for a Fork (fwd)
by Roger Fujii 10 Feb '02

10 Feb '02

Has anyone actually figured out what is required for a license change? Regardless what you think of the merits, it would seem that it would make the base confusing, at best, as the current LICENSE file must STILL be distributed along with the LGPL. At minimum, you still have to come up with another license for the spec compiler, and maybe some other stuff for the stuff in the tools directory. It for sure isn't as easy as "cp LGPL LICENSE" -r

1 0

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> On 2002.02.09 19:18 Patrik Stridvall wrote: > > David Elliott wrote: > > > On 2002.02.09 06:39 Patrik Stridvall wrote: > [SNIP] > > > In some ways it is. Many times when entities are violating > > > some license > > > or law a decision is partly based on what exactly their > > > intentions were. > > > Although I would not like to rely on this and I think > > > clarifying what and > > > what is not allowed is better than leaving it up to good > intentions. > > > > Yes, but in the case of copyright it doesn't really make much sense. > > For determining the punishment for any infringment, yes. > > For determining whether something infringes, no. > > > > And sure I guess hiding behind fair use is harder if you > intent is bad. > > > Sorry, should have clarified that more. It is true that > intent is used in > the punishment phase, usually not the actual trial. OK. Then you agree with me. However the fact remains that Alexandre doesn't agree. While he of course might be wrong, and probably is, it bothers me still. Because if he can be wrong, so can lawyers, especially careful lawyers, giving advise to their clients. > > However does the Joe Hacker in my earlier example that used > a propriety > > library to avoid dual booting and shared it with fellow hobbyists > > have "intent to infringe"? > > > This is pointless to discuss. I don't want a license where > no one can > possibly link wine with binary components. The LGPL does not > prohibit > that. Yes, but Alexandre (and possibly Jeremy) seems to want a license that does that. I have giving these examples to illustrate the implications if the LGPL indeed work this way. > > > > > Thus TransGaming does not hurt. Lindows really doesn't hurt > > > > > either, and > > > > > the users of Lindows win because should they need to > > > update the LGPL > > > > > components of Wine they can do so and still continue to link > > > > > to Lindows > > > > > binary only components. > > > > > > > > Exactly, but they will be able to do that without the LGPL. > > > > It is in the respective companies intrest to make it so. > > > > > > > If that is so, then why aren't they doing it already? > > > > 1. Lack of time. > > 2. Lack of insight what their users might want. > > 3. Lack of concerned users. > > > > I'm sure you can find more reasons. > > > Because the current license allows them to get away with it. Yes, but they might fix it then they find time. There is little reason to force it now. > > > Yeah, doesn't that suck. Kind of like people use proprietary > > > software so > > > they get what they deserve. We can't stop them from > using it as that > > > limits the freedom's of the proprietary software companies > > > and the users > > > who want to use that software. However what we can do is > > > remove the need > > > to use proprietary software. Wine is a first step towards this. > > > > Yes, but I never think the need for proprietary software > will disappear. > > > > Obviously not in the grand scheme of things. But basic day > to day tasks > like just being able to use your computer should not require > proprietary > software. I would extend basic tasks to basic word processing and > web-browsing functionality. Your typical Linux distribution > is already at > that point. The only thing missing is the ability to > continue to run the > Windows based programs that offer extended functionality. > Wine fills that > need and will help to transition users to a more reasonable and open > platform. Quite true, I agree. > Wine is such an important product and yet most of the > developers don't > really care about its future. Moving users from Windows to some > proprietary Windows clone isn't really helping. It doesn't? So making users aquinted with Linux in a gentle way will not help? If Lindows will not let their users hack and improve on their version of Wine, I suspect that at least some users will abandon Lindows for some other Linux distribution there they can hack Wine. In fact unless Lindows grow closer to classical Linux distribution, ie not running everything as root for example. I expect many users to abandon Lindows eventually anyway. > > Do you consider it morally or ethically defendable to > > prevent this behavior? > > > Yes, I think it is morally defendable to prevent people from > incorporating > Wine into proprietary products. And for most free software > projects I > think it is morally defendable to prevent people from even > linking to them > or using them in any proprietary software. Even if the tools you had to use say LGPL was so crude that it would additionally prevent people to help themselves and their friend avoid dual boot for example? > For Wine I think by nature we must let people link to > proprietary software. Agreed. > > > This is simply not true. This is very much Wine's problem. > > > If I need > > > some of Lindows's functionality to run my program but would > > > still like to > > > be able to hack on other parts of Wine then I, as a developer > > > and user, am > > > screwed. > > > > So complain with Lindows support or abandon Lindows and use > something > > else or whatever. Eventually they will learn to listen to their > > customers. > > > This laissez-faire attitude really bothers me. You say you > care, but in > reality you don't. No, it is rather a stupidity has its own reward attitude. I just see little reason help stupid people at the expense of other things. I do care, if I could help stupid people with little effort, I would, but I won't make any sacrifices for them. > > > We cannot > > > put our work on the line and say "Well, hopefully no one will > > > make bad > > > choices with it". > > > > You can never prevent people from doing bad choice with a product: > > "Design a product even an idiot can use and only an idiot > will use it" > > > This is not the same thing. Not exactly, no. But the proverb illustrates the same principle. > What I would like to accomplish > is to prevent > people from incorporating Wine into proprietary products. I > don't want to > depend on the users of these proprietary products. So don't use them and save yourself the money. The proverb is meant to illustrate that you are the idiot if you buy or use idioticaly designed products. > Besides > dude.. what > company listens to their customers anymore anyway. Any company that wishes to survive does. > > > > See my suggestion about the "MGPL" instead. > > > > > > > This is really the same thing as a clarified LGPL. It's not > > > necessary to > > > write from the ground up a new license, but if we need to > > > take the LGPL > > > and strike out certain sections and/or add to it then that is > > > far better > > > than writing a new license completely from scratch. > > > > No, it is not, because we want the license to be very clear > > on what is allowed and what is not. No patchwork. A clear > > license with only the absolute minimum number of paragraphs. > > > > Remember we want companies working on Wine without having > > to spend to much money on their lawyers. > > > > ARGH!!!!! Licensing software is complex. If the only > argument you have > against the LGPL is that it is complex, then tough cookies. The only > licenses that are extremely simple are the ones that either say "Do > whatever with it" or the ones that say "We'll take your > firstborn if you > reverse engineer it". > > This argument that the LGPL is too complex is a waste of > time. It reminds > me of microsofts shared source license. One of its strong > points was that > it was simple. Know why it was simple? Because you couldn't > do shit with > the source so it was simple. At the other extreme we have > the X11 which > is simple, because you can do almost everything with it. True, but I primarily wish to strive for simplicity not nessarily reach it. > The very nature of moving to a license like the LGPL means it will be > complex. This doesn't mean it has to be incomprehensible > (and it isn't) > it just means it'll be complex. Well. I just want again to point out that everybody doesn't even agree what the LGPL means. This is what primarily bothers me. > > Basicly but I very much fear that even a MGPL would be to complex. > > > > So then I nailed it. You're only real concern seems to be > that companies > may shy away from Wine if the license is so complex. I > wouldn't be that > concerned about it. Had Wine been LGPL, Lindows probably still would > exist and would be playing more nicely with us. Perhaps, but Transgaming probably wouldn't. Don't celebrate too soon. > > > They can pay lawyers to figure it out for them. Why do you > > > think lawyers > > > make all the money anyway. > > > > Because the money that they can avoid spending on lawyers could > > be spent on improving Wine instead. > > > If you take the average software company, more likely it'll > be spent on a > private jet for the CEO. I'm sure Gavriel would be delighted to have a private jet. :-) > Anyway... this mail is getting really long, and if the > biggest argument > you can come up with against the LGPL is that it's too > complex then it is > pointless to continue. I think the discussion between us is pretty ended as far as goals are concerned. Our prefered means and willingless to give up some of the goals for reduced complexity still differs. Anyway, what rely matter is what other people like Alexandre think about a license that allows wrapper library. Of course we both claim that even the LGPL does, but then other people don't. So I'm intrested in their opinion.

1 0

Macromedia Flash 5.0 ALMOST working (mouse button release bug)
by ivan 10 Feb '02

10 Feb '02

Hi I have run Flash 5 with no problems except for just _one_ annoying issue which is turning it unusable. Once the mouse button is clicked for drawing or placing an item it never gets released (it resizes the item as if you had the mouse button pressed all the time) I would like a lot if this was fixed because Flash is the only app which keeps me using Winblows sometimes. But i can't fix this myself because i don't know enough to do it. The error log which i get when running wine flash.exe is: [ivan@schnell Flash 5]$ wine flash.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (Spanish keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. err:midi:OSS_MidiInit ioctl on midi info for device 0 failed. fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoMarshalInterface Failed to Marshal the interface, 80070057? fixme:ole:_LocalServerThread CoMarshalInterface failed, 80070057! fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:storage:StgCreateDocfile Transacted mode not implemented. fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:imm:ImmGetContext (0x00020022): stub fixme:mdi:MDIRefreshMenu partially function stub fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:accel:CreateAcceleratorTableA should check that the accelerator descriptions are valid, return NULL and SetLastError() if not. fixme:imm:ImmGetContext (0x00020022): stub // the line above happens when i click a tool button fixme:imm:ImmGetContext (0x00020022): stub // the line above happens when i try to draw with that tool // after that i can't do anything else, because the cursor don't gets released // and keeps drawing or resizing Terminated // ctrl+c, the only way to stop it Anyone knows what's happening here? Do you need more info? I will do or test whatever you want to help solve it. TIA

1 0

Richard Stallman
by Brett Glass 10 Feb '02

10 Feb '02

Plato (tom(a)redant.freeserve.co.uk) writes: >Could you give me URLs to one or more of these essays? Last time I looked, they were all on Stallman's gnu.org site, in the "Philosophy" section. Unless, of course, he has expunged them to hide his true intentions. >> Software is "proprietary" if it does not interoperate with other software, >> does not conform to industry standards, and/or uses unique file formats >> or protocols so as to lock users in or deter competition. > >That is not true. In English, `propritetary' is an adjective used to describe >something which is the property of someone. If you were to use this definition, then all of the FSF's software would be "proprietary." (It is interesting that the FSF condemns software "hoarding" and yet has one of the largest hoards of source code in the world.) >In the computing world it is >generally used to describe software which does not allow redistribution and >modification. Not true. This is the way the FSF has attempted to REdefine it, but it is not the correct definition. >Again not true. Commercial software need not be *licensed* for money, it >only need be developed or marketed as a way of business. For something to be commercial, it must be the object of commerce. >Did you read the links I posted? I post them again and suggest you do so >before posting erroneous comments. How can you hope to win an argument when >you do not understand the issues involved? > >http://www.gnu.org/philosophy/words-to-avoid.html#Commercial >http://www.gnu.org/philosophy/software-libre-commercial-viability.html I have studied Stallman's propaganda at great length, and have written essays on the misleading rhetorical techniques it uses. I not only understand the issues involved; I also understand how Stallman has attempted to distort them and mislead programmers into hurting themselves, their profession, and their projects. --Brett

1 0

Re: Time for a Fork (fwd)
by winedev＠admdev.com 10 Feb '02

10 Feb '02

Wouldn't really work... Not only the extra work for Alexandre, but the fact the trees will become totally unsyched. Then there's pollution of code and licensing from one tree to the next.. The problems are too many to count. This is really an all-or-nothing decision. If we loose developers from making a license shift, then so be it... I think its inevitable, but I also think they will slowly start drifting back when they realise that it DOES work and isn't quite the evil they thought :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] On Sat, 9 Feb 2002, Dan Kegel wrote: > Date: Sat, 09 Feb 2002 17:42:55 -0800 > From: Dan Kegel <dank(a)kegel.com> > To: wine-devel(a)winehq.com > Subject: Time for a Fork > > It seems clear to me that Wine is just like Unix: > some people prefer a BSD license, and others prefer a GPL license. > > BSD can never convince Linux people to switch licenses, and vice versa. > > So be it. > > Rather than endlessly debate the issues, I suggest we simply agree > on an amicable parting of ways. > > The current cvs tree and patch mailing lists would remain as is. > > A new LGPL-licensed tree and associated wine-lgpl-patches mailing list > would be created to accept LGPL-licensed patches. > > This would put an end to a lot of bickering, and would let us > see how the two license agreements work out in practice. > > Comments? > - Dan > > >

3 2

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> On 2002.02.09 06:39 Patrik Stridvall wrote: > > > > You might believe me or you might not, as all people > arguing against > > > > me last time. Be that as it may, that discussing is dead and I > > > > will in the future concentrate on "If the LGPL means what you > > > > say it does, we don't want the LGPL". > > > > > > > Actually, IYRC, and IIRC, I pretty much agreed with you > that the LGPL > > > actually WOULD allow one to implement proprietary code simply > > > by releasing > > > small wrapper functions as LGPL code. > > > > Yes, but you was one of the few. Alexandre in particular seemed > > to believe it depended on some strange notation of whether it > > was intentional or. > > > In some ways it is. Many times when entities are violating > some license > or law a decision is partly based on what exactly their > intentions were. > Although I would not like to rely on this and I think > clarifying what and > what is not allowed is better than leaving it up to good intentions. Yes, but in the case of copyright it doesn't really make much sense. For determining the punishment for any infringment, yes. For determining whether something infringes, no. And sure I guess hiding behind fair use is harder if you intent is bad. However does the Joe Hacker in my earlier example that used a propriety library to avoid dual booting and shared it with fellow hobbyists have "intent to infringe"? I claim that every work either violates copyright in and of itself or not at all. Nothing else makes much sense. How can you determine the intent of the author of work, if for example the author is anonymous. Sure if the author or the process of authorship is unknown you really can't claim indepent derivation if you (not the author) distribute the work and if some judge thinks it similar enough with another work to infringe. However that judgement was for obvious reason made by examination of the work in and of itself. > > > Thus TransGaming does not hurt. Lindows really doesn't hurt > > > either, and > > > the users of Lindows win because should they need to > update the LGPL > > > components of Wine they can do so and still continue to link > > > to Lindows > > > binary only components. > > > > Exactly, but they will be able to do that without the LGPL. > > It is in the respective companies intrest to make it so. > > > If that is so, then why aren't they doing it already? 1. Lack of time. 2. Lack of insight what their users might want. 3. Lack of concerned users. I'm sure you can find more reasons. > > > Now you may consider this not enough to stop the less honourable > > > companies. Yeah, you're right. Lindows can continue to > > > build upon wine, > > > add their own stuff, and release a product. The only > > > difference is that > > > now they can't just fold all the wine code into the binary.. > > > they have to > > > allow the user to update the wine code. That is the purpose > > > of the LGPL. > > > Unlike the GPL which tries to make all software free > > > software, the LGPL > > > tries to keep free software as free software, and proprietary > > > software as > > > proprietary software. > > > > Yes. But that is NOT an argument for using LGPL as I have > said above. > > > Sure it is. The LGPL's purpose in life is to make sure the > users of the > program can continue to recompile the code that was LGPL to > begin with. OK. Reformulate. There is no reason to force this to happend, since it is likely to happend eventually anyway. See below. > > > Now let's say we take the stricter interpretation that you > > > cannot do the > > > above. That is bad I think. > > > > > > How about going to LGPL and add a clause that clarifies that > > > the above is > > > in fact allowed? > > > > Why confuse the company lawyer even more? > > > > Even if I would be inclined to agree, I would rather let > the FSF lawyers > > draw up a completely new license lets call it, hmm, MGPL (Middleware > > GPL), > > for use in, hmm, what should I call it, say two-ended > libraries that Wine > > IMHO really is. > > > > This MGPL should clarify that it is legal to "plug-in" proprietary > > application/libraries in both ends while code the middle that is > > the Wine source code should have some copyleft like protection and > > additional that sublicening the code as LGPL is allowed. > > > > Note however I'm not really proposing this but it might be > a reasonable > > compromise. Perhaps something for the LGPL camp to chew on. > > > What you describe sounds to me like what I am describing. A > modified and > clarified LGPL. Essentially when you start adding or > deleting from the > LGPL you are in fact making a new license. You are saying > the same thing > I am. As you wish, this is of no moment. > [SNIP] > [Quote Dennis Miller: Y'know.. I don't want to get off on a > rant here...] > > > > When the voters give any of them support, the problem is that > > > > they didn't really support the extreme views they presented, > > > > but they are forced to do it anyway in order of not being > > > > accussed of betraying the will of the voter. > > > > > > > You can thank the "liberal" media for that one. :-( > > > > Well, that is just the symptom. > > The ignorant masses are the real problem IMHO. > > > > Unfortunately, there is no serious alternative to democracy, > > so I'm a loss what to do. :-( > > > True. Actually, I think the media is more of a symptom of > politicians > catering to them for years now. Well of course they do since that is one of the few way they can reach their voters. It is still the ignorant masses that are the real problem unfortunately. Increased education will only get you so far and it is never any substitute for logical thinking. Of course, the ignorant masses really gets what they deserve. I primarily think it is unfortunate that I live in the same world as them. > Look at the administration > now. They > don't take any shit and just tell it like it is. Bush may not be an > excellent speaker but he seems to say what's on his mind and > doesn't try > to always be the media's bitch like Billy-boy and his wife did. Sometimes the ignorant masses are lucky sometimes they are not. > > Lets return the easy problem of finding of good license for > Wine. :-) > > > Yeah, sorry, just had to get off on a little rant about the media. :-) > > > Especially see MSNBC. What a crock of shit that is.. > > > figures, it being a > > > MS product and all :-). The reporters on that station are > > > just horrible. > > > They ask a question and when they get a totally straight > > > answer that they > > > don't agree with they just ask it again and again changing a > > > few words to > > > make it seem like it's a different question. > > > > Well, people watch the shit, so they get what the deserve. > > > > Unfortunately it hurt us other as well, but then we really can't > > limit their freedom of speech, can we? > > > Yeah, doesn't that suck. Kind of like people use proprietary > software so > they get what they deserve. We can't stop them from using it as that > limits the freedom's of the proprietary software companies > and the users > who want to use that software. However what we can do is > remove the need > to use proprietary software. Wine is a first step towards this. Yes, but I never think the need for proprietary software will disappear. > > > > In the cases of Wine. I hope that the people working with the > > > > Wine project are not among the ignorant masses and thus really > > > > are able to understand the subtle differences between different > > > > positions. > > > > > > > Yeah, so far it only seems like the people who caught > this story on > > > slashdot are among the ignorant masses. :-/ > > > > I wouldn't really call them the ignorant masses but rather the > > I-can-almost-but-not-quite-understand-this masses. Since they > > don't fully understand it they assume that it is something > > bad and post their unordered thoughts in hope that other might > > make something out of it. > > > Yeah, sometimes a little knowledge is far worse than none at > all. Usually > this is only the case when people think that a little > knowledge makes them > an expert and get big-egos. Very true. > > > We should collectively think of the different scenarios and > > > ask one very > > > important question: Do we /really/ want to prevent this > scenario from > > > happening? > > > > Ah, I forgot that very important question. I intend to supply it but > > somehow > > it got lost. But perhaps the question: > > > > 1. Do you consider his or her behavior morally or ethically > defendable? > > > > sums it up pretty well as well. > > > Sounds kind of like my.. do you think it should be allowed question, > although put in a better way. Ah yes, you are right, we probably should ask the opposite question as well: Do you consider it morally or ethically defendable to prevent this behavior? > > > Personally I have warmed up a slight bit to the idea of > > > Lindows. At first > > > I was a bit like.. those dickheads took wine, added a few > > > things, and are > > > gonna sell it for $100/seat and we're not getting any of that > > > or even any > > > improvements back!? That bites. > > > > > > But now I realize that we need to put that emotion aside and > > > look at how > > > exactly lindows harms wine (which it does). > > > > > > The first thing is the issue of binary-only wine that can't > > > be changed and > > > has absolutely no source. That really bites for the user > who is thus > > > locked into Lindows complete package and cannot even change > > > the parts of > > > wine that Lindows has nothing to do with. > > > > If Lindows prevents users from updating their version of Wine > > it is really their and their users problems not our problem. > > > This is simply not true. This is very much Wine's problem. > If I need > some of Lindows's functionality to run my program but would > still like to > be able to hack on other parts of Wine then I, as a developer > and user, am > screwed. So complain with Lindows support or abandon Lindows and use something else or whatever. Eventually they will learn to listen to their customers. > > > If we were LGPL > > > and allowed > > > importing functions from non-LGPL components then Lindows > > > could still add > > > value by implementing APIs in their own DLL or DLLs and > > > loading them from > > > wine. In fact, they don't need to be DLLs. They could just > > > put all their > > > stuff in their own closed source file, compile it, and > > > distribute the .o > > > so that end users (their customers) can later take that .o > > > file plus the > > > LGPLd modifications to wine that make it use the functions in > > > that .o, and > > > link it into a newer version of wine. > > > > I don't see why we should adapt our license to cater for people > > that make bad choices and suffer because of it. Especially > > when such a license might scare other people that might help > > us away. > > > Because people make mad choices every day and don't realize > it. Indeed, but stupidity is its own reward. > We cannot > put our work on the line and say "Well, hopefully no one will > make bad > choices with it". You can never prevent people from doing bad choice with a product: "Design a product even an idiot can use and only an idiot will use it" > > Regardless of any fun you might have had. Ask this question: > > > > Would you have consider it ethically or morally defendable if the > > Wine license had prevented you from using a proprietary ASPI > > library with Wine and distributing the result to your friends. > > > YES! That is my point. I would have done it anyway even if > their was a > proprietary version. And I think it is important that we > allow people to > use and distribute proprietary components with a free software Wine. Agreed. > > > Anyway.. these are just two.. there are more I'm sure.. I > > > really need to > > > go to bed though. > > > > Different time zones. I returned from a late breakfast to > > find your mail. :-) > > > Hmm, well, I suppose about the time I sent it I could've gone > to an early > breakfast since it was like 5am. Well, my father usual gets up at that time. :-) > What was it, like noon or 1 > where you > are? I recieve that mail at 11.20 am. Speaking of time it is now 1.00 am for me. Time for bed as soon as I finish answering this. > > > Before I do so, I would like to point you to the > wxWindows website. > > > > > > According to their short license summary they use LGPL but > > > also allow you > > > to distribute a binary linking with wxWindows included. That > > > exception > > > would not be appropriate for wine (in fact, it's like the > > > main advantage > > > for us to use the LGPL I think). However we could do a > similar style > > > thing and say: "We're LGPL but we specifically allow you to > > > create stub > > > functions in our library that call out to your > proprietary component. > > > > See my suggestion about the "MGPL" instead. > > > This is really the same thing as a clarified LGPL. It's not > necessary to > write from the ground up a new license, but if we need to > take the LGPL > and strike out certain sections and/or add to it then that is > far better > than writing a new license completely from scratch. No, it is not, because we want the license to be very clear on what is allowed and what is not. No patchwork. A clear license with only the absolute minimum number of paragraphs. Remember we want companies working on Wine without having to spend to much money on their lawyers. > > > Hopefully we can get this resolved this time... It's looking > > > promising > > > given the few and far between somewhat clear posts and > > > disregarding the > > > ill-informed wanna-be-on-slashdot shit. > > > > We will see. I'm neither optimistic nor pessimistic for the moment. > > > > > Well, I /hope/ we can get this resolved since we're talking > about the same > things. Your only real concern at this point seems to be > that if we were > to move to LGPL that some companies may not like it because > it's complex. Basicly but I very much fear that even a MGPL would be to complex. > They can pay lawyers to figure it out for them. Why do you > think lawyers > make all the money anyway. Because the money that they can avoid spending on lawyers could be spent on improving Wine instead.

2 1

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 10 Feb '02

10 Feb '02

> > You might believe me or you might not, as all people arguing against > > me last time. Be that as it may, that discussing is dead and I > > will in the future concentrate on "If the LGPL means what you > > say it does, we don't want the LGPL". > > > Actually, IYRC, and IIRC, I pretty much agreed with you that the LGPL > actually WOULD allow one to implement proprietary code simply > by releasing > small wrapper functions as LGPL code. Yes, but you was one of the few. Alexandre in particular seemed to believe it depended on some strange notation of whether it was intentional or. > As in: > > DWORD WINAPI FooMicrosoftApi(CHAR *bar, DWORD baz) > { > return someotherdll_FooMicrosoftApi(bar,baz); > } > > Which would be LGPL, and the someotherdll_FooMicrosoftApi > would be under a > different license. > > With this situation the stated purpose of the LGPL is still > upheld. The > stated purpose is to allow one to continue to update the > parts of the code > that are LGPL while still being able to link with proprietary > components. Exactly. However I see no reason particular reason why even less honourable companies wouldn't release the wrapper code to the us whether they were forced to or not. It is in their intrest to make it easy for Wine to use their library so they can limit the support for clueless users for example. This even if LGPL allowed it, is not a strong argument for LGPL. In this case it would only primarily the confusion on whether this is allowed, for little gain. > Thus TransGaming does not hurt. Lindows really doesn't hurt > either, and > the users of Lindows win because should they need to update the LGPL > components of Wine they can do so and still continue to link > to Lindows > binary only components. Exactly, but they will be able to do that without the LGPL. It is in the respective companies intrest to make it so. > Now you may consider this not enough to stop the less honourable > companies. Yeah, you're right. Lindows can continue to > build upon wine, > add their own stuff, and release a product. The only > difference is that > now they can't just fold all the wine code into the binary.. > they have to > allow the user to update the wine code. That is the purpose > of the LGPL. > Unlike the GPL which tries to make all software free > software, the LGPL > tries to keep free software as free software, and proprietary > software as > proprietary software. Yes. But that is NOT an argument for using LGPL as I have said above. > Now let's say we take the stricter interpretation that you > cannot do the > above. That is bad I think. > > How about going to LGPL and add a clause that clarifies that > the above is > in fact allowed? Why confuse the company lawyer even more? Even if I would be inclined to agree, I would rather let the FSF lawyers draw up a completely new license lets call it, hmm, MGPL (Middleware GPL), for use in, hmm, what should I call it, say two-ended libraries that Wine IMHO really is. This MGPL should clarify that it is legal to "plug-in" proprietary application/libraries in both ends while code the middle that is the Wine source code should have some copyleft like protection and additional that sublicening the code as LGPL is allowed. Note however I'm not really proposing this but it might be a reasonable compromise. Perhaps something for the LGPL camp to chew on. > > > I think it's more of an issue of people thinking too much in > > > black/white > > > terms and people that lean strong towards one side or the other. > > > > Yes. Perhaps they are not nessarily thinking in black and white > > but their arguments are often presented that way. > > > > I'm not entirely blameless on that point either, I will try > > to do better in the future. > > > > > Look no further than the US political system for a good > > > example. You have > > > the Republicans and the Democrats. Generally they take every > > > issue to > > > opposite ends of the extreme such that 99% of congress is at > > > one extreme > > > or the other, but 99% of the population wants neither extreme. > > > > Exactly, but that is because: > > 1. They want votes so they can do that they feel is right. > > 2. The ignorant masses are not likely to understand subtle > > differences in opionion. > > > > When the voters give any of them support, the problem is that > > they didn't really support the extreme views they presented, > > but they are forced to do it anyway in order of not being > > accussed of betraying the will of the voter. > > > You can thank the "liberal" media for that one. :-( Well, that is just the symptom. The ignorant masses are the real problem IMHO. Unfortunately, there is no serious alternative to democracy, so I'm a loss what to do. :-( Lets return the easy problem of finding of good license for Wine. :-) > Especially see MSNBC. What a crock of shit that is.. > figures, it being a > MS product and all :-). The reporters on that station are > just horrible. > They ask a question and when they get a totally straight > answer that they > don't agree with they just ask it again and again changing a > few words to > make it seem like it's a different question. Well, people watch the shit, so they get what the deserve. Unfortunately it hurt us other as well, but then we really can't limit their freedom of speech, can we? > > In the cases of Wine. I hope that the people working with the > > Wine project are not among the ignorant masses and thus really > > are able to understand the subtle differences between different > > positions. > > > Yeah, so far it only seems like the people who caught this story on > slashdot are among the ignorant masses. :-/ I wouldn't really call them the ignorant masses but rather the I-can-almost-but-not-quite-understand-this masses. Since they don't fully understand it they assume that it is something bad and post their unordered thoughts in hope that other might make something out of it. > > > Essentially we could go on forver about X11/BSD vs. GPL. > It's been > > > discussed to death already folks. What we need are reasonable > > > compromises. Of course you need to have people willing to > > > compromise to > > > do that. I suspect most developers are with the exception of > > > the view > > > vocal BSD people and the few vocal LGPL all the way people. > > > I myself am > > > certainly not at either extreme. > > > > Even if perhaps some people won't believe me. I not really > > an extremist. I try to take a pragmatic view of the world. > > > > I believe that GPL has its place, LGPL has it place and the BSD > > license has its place. > > > > However my analysis of the issues at hand makes me believe that > > LGPL would be really bad in the particular case of Wine, for > > reasons that I have tried to explain. > > > Personally I think the LGPL is pretty damn good and fits wine > pretty well > but we simply need to clarify the gray areas about what is and is not > allowed (see above). That is the point we disagree on, at least partly. > > I suggest that people try to think about scenarios of circumstances > > where possible extensions to Wine might be made. This might be > > business models like Transgaming or Lindows.com or just something > > Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring > > -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It > are doing. > > Just like the examples in the my last mail. > > > > Then ask the questions: > > 1. Do you consider his or her behavior morally or ethically > defendable? > > 2. Does it violate the letter of the LGPL? > > 3. Does it violate the spirit of the LGPL? > > 4. Does it violate the letter of copyright law? > > 5. Does it violate the spirit of copyright law? > > 6. Do you think any reasonable Judge/Jury would find him or > her guilty? > > > > With the spirit of copyright law I roughly mean: > > Is it what congress intended and/or is it constitutional? > > Notice the and/or: > > It is possible for act of congress to be constitutional without > > being the intention of the congress. > > > Hmm.. y'know that's a good idea. At least it something concrete to do instead on arguing back on forth about abtract fears. > We should collectively think of the different scenarios and > ask one very > important question: Do we /really/ want to prevent this scenario from > happening? Ah, I forgot that very important question. I intend to supply it but somehow it got lost. But perhaps the question: 1. Do you consider his or her behavior morally or ethically defendable? sums it up pretty well as well. I can't think about anything except egoistical concerns that could make anybody want to prevent something they thought morally and ethically defendable. > Personally I have warmed up a slight bit to the idea of > Lindows. At first > I was a bit like.. those dickheads took wine, added a few > things, and are > gonna sell it for $100/seat and we're not getting any of that > or even any > improvements back!? That bites. > > But now I realize that we need to put that emotion aside and > look at how > exactly lindows harms wine (which it does). > > The first thing is the issue of binary-only wine that can't > be changed and > has absolutely no source. That really bites for the user who is thus > locked into Lindows complete package and cannot even change > the parts of > wine that Lindows has nothing to do with. If Lindows prevents users from updating their version of Wine it is really their and their users problems not our problem. > If we were LGPL > and allowed > importing functions from non-LGPL components then Lindows > could still add > value by implementing APIs in their own DLL or DLLs and > loading them from > wine. In fact, they don't need to be DLLs. They could just > put all their > stuff in their own closed source file, compile it, and > distribute the .o > so that end users (their customers) can later take that .o > file plus the > LGPLd modifications to wine that make it use the functions in > that .o, and > link it into a newer version of wine. I don't see why we should adapt our license to cater for people that make bad choices and suffer because of it. Especially when such a license might scare other people that might help us away. > Now, the second issue, and the one Alexandre is (or maybe > just was) most > concerned about, was companies implementing functionality > that the real > wine does not have will sometimes reduce the incentive for a > developer to > work on it. That is to say that a good portion of developers > that would > otherwise be contributing to Wine making stuff work will stop > if they can > simply by Lindows for $100 and make that work. Perhaps, but you will have to take the good with the bad and licenses preventing this also prevents other things. Whether LGPL really does this or not is another question though. > Ironically > moving to LGPL > would actually make it easier for a wine developer to use > some lindows > functionality since they could update the rest of Wine. > However, at least > for me part of the reason I like hacking on Wine is to hack > on wine to > have a version that is free software. That is, let's say > there had been a > working closed source ASPI layer then I could've used my CD-R > in Wine and > maybe I wouldn't have fixed a bunch of stuff with ASPI. But > doing that > was a lot of fun and I would have been the one missing out by > falling back > to a lindows implementation and never considering actually > fixing the real > wine implementation. Plus in the meantime at least my CD-R would've > worked so it would have been a less pressing issue and would > have avoided > numerous reboots for me in trying to create a free version. Regardless of any fun you might have had. Ask this question: Would you have consider it ethically or morally defendable if the Wine license had prevented you from using a proprietary ASPI library with Wine and distributing the result to your friends. > Anyway.. these are just two.. there are more I'm sure.. I > really need to > go to bed though. Different time zones. I returned from a late breakfast to find your mail. :-) > Before I do so, I would like to point you to the wxWindows website. > > According to their short license summary they use LGPL but > also allow you > to distribute a binary linking with wxWindows included. That > exception > would not be appropriate for wine (in fact, it's like the > main advantage > for us to use the LGPL I think). However we could do a similar style > thing and say: "We're LGPL but we specifically allow you to > create stub > functions in our library that call out to your proprietary component. See my suggestion about the "MGPL" instead. > Hopefully we can get this resolved this time... It's looking > promising > given the few and far between somewhat clear posts and > disregarding the > ill-informed wanna-be-on-slashdot shit. We will see. I'm neither optimistic nor pessimistic for the moment.

3 3

Re: Dr. Seuss, licensing, and WINE
by Brett Glass 10 Feb '02

10 Feb '02

Plato (tom(a)redant.freeserve.co.uk) writes: >> Give me a break dude. Yes, the FSF wants all software to be free and >> wants to rid the world of commercial software altogether. >[...] > >I think it is worth pointing out the the Free Software Foundation does *not* >want to rid the world of commercial software. > >Stallman has, however, stated that he would like to rid the world of >*proprietary* software. Richard Stallman most certainly does want to rid the world of all commercial software. He says so in many of his essays. One of Stallman's propaganda techniques, alas, has been to refer to commercial software as "proprietary" software. He does this because the word "proprietary" has negative connotations. He hopes to co-opt those connotations so as to convince others to join him in his drive to destroy all commercial software. To set the record straight: Software is "proprietary" if it does not interoperate with other software, does not conform to industry standards, and/or uses unique file formats or protocols so as to lock users in or deter competition. Software is "commercial" (that is, the object of commerce) if it is licensed for money. GPLed software cannot be commercial because it cannot be licensed for money (the GPL prohibits this). You can sell a disc with GPLed software on it, but only the plastic disc is a commercial product -- not the code it contains. --Brett Glass

2 1

Re: Wine license change (fwd)
by winedev＠admdev.com 10 Feb '02

10 Feb '02

(Reposted, as I just realised my Pine roles wern't sending this from the right address :) Regards, | It's always bad news in computing.. and beware | of anything claming to be good news - because | its probably a virus. - Salmon Days Ender | (James Brown) | [Nehahra, EasyCuts, PureLS, www.QuakeSrc.org] ---------- Forwarded message ---------- Date: Sun, 10 Feb 2002 08:44:52 +0800 (WST) From: "J.Brown (Ender/Amigo)" <ender(a)enderboi.com> To: Brett Glass <brett(a)lariat.org> Cc: wine-devel(a)winehq.com Subject: Re: Wine license change > >John Carmack made an intresting point, he releases ID softwares older > >releases under the GPL. Why? Because after originally releasing an engine > >after a BSD-esque license, a project done some very major work to the > >engine... and then lost it in a harddrive crash. So his -main- reason for > >using the GPL is to prevent work done in the community from being lost. > > He really should take the time to back up his drives. ;-) But, assuming > that he wishes to use this rather unusual backup mechanism, why would the > GPL be any better at this than a BSD-style license? Sorry, let me clarify that point... the major work that was lost was done by a COMMUNITY project, not one of ID's in-house ones. His point is that as the xGPL forces the release of source code with any binaries, so any valuable work like this won't be lost to the community. This has intresting implications for wine too. It's nice to say that Codeweavers/Transgaming/Lindows/etc might feed slice of code 'x' back to Wine at 'i' time in the future. Of course, if said company goes bust (sorry guys, but this IS the post .com era ;), there is a chance that code could be lost for good. - Ender

1 0

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> On Sat, 9 Feb 2002, Patrik Stridvall wrote: > > > I think you will be able convince both the lazy person above > > as well as the bean counter that this will be the best > > long time choice. > > > > > If Wine is LGPL they must release the patch if they want > to reap the > > > benefits of using Wine, and they can release it without > fear of giving > > > away money to someone else. It can even be argued that the > > > LGPL makes Wine > > > an even safer bet, since it guarantees that other companies > > > in this group > > > will chip in, this way Wine will be in even better shape when > > > the first > > > application was a smash hit and they decide to port their > next app! :) > > > > Correct, but this is likely to be true anyway for reasons > given above. > > > > This is what I imagine the LGPL proponents are dreaming > about at night. > > Unfortunately it is a dangerous dream since it total ignores the > > drawbacks with a LGPL:ed Wine. > > > > The drawback would be that it locks out the companies from > group 1 (yes, > you have pointed out technical problems that might render the LGPL > worthless, but I'll leave the bugfixing for now, lets just assume it > actually works). > > My question is, to you and everyone else, how valuable are > this kind of > companies to the Wine community? A relevant question, unfortunately the problem is much more complex that that. Assuming that LGPL really prevents wrapper libraries have very far reaching consequences. I have tried to give example of specific cases like the Joe Hacker hobbist with his proprietary hobby related library and his proprietary Windows application and his wish not to dual boot. I asked whether doing this (or for that matter preventing) this was among other things ethically or morally defendable. You can't just focus on the companies that wish to profit on Wine in some way. But yes, short answer: I believe such companies like Transgaming is valuable for the simply reason that our resources are limited, this allows us to concentrate on improving other parts of Wine. If in the future decide that hey now that we have more developer resources, now let do a really free DirectX, we can do that. Always remember that: He who defends everything, defends nothing. In short a strategic retreat means that we get resources to defend what we have and later take it back as we grow stronger. > Yes, they may make progress fast, maby they are even required > to take Wine > from the allmost but not quite stage to actually reach that > elusive goal > of 99.9% Windows compatibility. > > But at the same time this progress may never make it back to > the community. > And as pointed out by Alexandre, in the worst case scenario > they may halt > or slow down progress in the free version, because there is > no incentive > to implement some missing peice when it already exists and > can be bought > cheaply from company X. Well and as I pointed out. Most people have a Windows license and many Micrsoft DLL work fine under Wine. Yes, I know he thought that to was bad too. But then you can't both have the cake and eat it. The same thing with other proprietary extensions, except perhaps better from Alexandres point of view, since much more people have Windows licenses than a random proprietary library. > The limited experience shows that things has worked out OK. It will be > interesting to see what Lindows ends up doing, I wish they > would skip the > maketdroid speak for a while and join this discussion. Agreed. > > > have the least to gain from contributing anything back. The > > > companies in > > > group 2 have the least incentive to work on Wine, just > fix the bare > > > minimum to get their application to work, but instead > they can allow > > > themselves the luxury to contribute and score some goodwill. > > > > Since companies in group 2 are likely to contribiute back anyway > > for reasons given above I see no reason to hurt group 1 companies. > > > > Yes, each and every one has to go back to his own motivation > for working > on Wine, does it matter if the group 1 companies get a free lunch? Well, all users of Wine already get a free lunch, and they might already profit from being able to run say Microsoft Office under Linux so if you are worried about people getting a free lunch you already have a serious problem.

1 0

Re: Wine license change
by Brett Glass 09 Feb '02

09 Feb '02

Roland (roland(a)netquant.com.br) writes: >To write it again we have two interests: > >1. People who want to make money selling WINE or derivates == anti xGPL >2. People who contribute for free or have another business model than the >above == pro xGPL There are a few more categories who would not want the (L)GPL: 3. Professional programmers who would like to fix bugs (if the code is (L)GPLed, they can't without becoming "tainted" by having read the code); 4. Anyone who objects to viral licenses or the FSF's misleading propaganda; 5. Users who want to be able to buy a commercial product with professional support, especially good integration, and possibly enhanced features; 6. Anyone who does not want to see WINE fork into truly free and FSF-licensed versions; and 7. Anyone who cares, on principle, about software freedom and choice. --Brett Glass

4 4

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> What's lacking in this discussion is some sensible analysis of what a > license need to contain to encourage future contributions to > Wine and to > protect the interests of the contributors. Fearmongering about Wine's > future and paranoid delusions about the GPL license doesn't > bring anything > to the table... Agreed. > Over to category two. Corel's source of income isn't from > improving Wine, > it's from selling their own work, Wine just makes their work > more valuable. > Here it doesn't really matter if Wine is BSD or LGPL > (remember that the > INTENT of the LGPL isn't to infect all and everything). > > A company that chooses this route may have to improve Wine > here and there > to fill in the missing pieces to make their port work, and by > releasing > this patch they will contribute to Wine as a whole. > > Unfortunatley they might not, don't underestimate the power > of laziness. > One other plausible reason is that some bean counter is afraid that > someone else will pick up their work for free and make money out of it > (i.e. Lindows) how'd you explain that to your shareholders? Companies in this group have several choices: 1. Don't use new improvement in the main Wine tree, only resync then a new major version of the application should be released. 2. Maintain a tree by themselves, continually resyncing in order to make even minor version take advantage of new improvements in the new Wine tree. 3. Have some sort of wrapper library that implement all the improvments that they don't what to release, that in turns calls the Wine real corresponding Wine function. Now they can, if the designed it correctly, use new versions of Wine without any problem. 4. Release the code to the Wine project and be able to run with the latest version of Wine without any problem. (1) and (2) are not very attractive. Resyncing the trees are quite time consuming. Especially (2) will not be fun at all. Both requires continously working with Wine. In any case I guess most companies want the Wine adaption to be a ONE TIME cost not a continous one. Likely they want to hire specialists from companies like CodeWeavers. This leaves (3) and (4). If you design (3) wrongly the application will break with newer version of Wine so it is not really a that good choice either. In addition it will require extra work just to be able to hide the improvments. This leaves (4) ie they treat Wine is LGPL even if it isn't. I think you will be able convince both the lazy person above as well as the bean counter that this will be the best long time choice. > If Wine is LGPL they must release the patch if they want to reap the > benefits of using Wine, and they can release it without fear of giving > away money to someone else. It can even be argued that the > LGPL makes Wine > an even safer bet, since it guarantees that other companies > in this group > will chip in, this way Wine will be in even better shape when > the first > application was a smash hit and they decide to port their next app! :) Correct, but this is likely to be true anyway for reasons given above. This is what I imagine the LGPL proponents are dreaming about at night. Unfortunately it is a dangerous dream since it total ignores the drawbacks with a LGPL:ed Wine. > Companies that decide to develop a new app and use Wine as the cross- > platform framework also belongs to this group. Partly, but new applications can avoid using unimplemented functions so they are less likely to contribute anything back. > Back to Wine again, the selfish motive here is to make Wine > better faster. > So if we get the choose between companies in group 1 or 2, who will > contribute the most? Obviously the ones in group 1 will do > the most work, > since their living relies on a perfectly working Wine, > unfortunatley they > have the least to gain from contributing anything back. The > companies in > group 2 have the least incentive to work on Wine, just fix the bare > minimum to get their application to work, but instead they can allow > themselves the luxury to contribute and score some goodwill. Since companies in group 2 are likely to contribiute back anyway for reasons given above I see no reason to hurt group 1 companies. > So what's the conclusion? Either you pick your favourite way of making > business and lobby for a compatible license, or you start > thinking out of > the box and find the perfect balance that let's everyone keep > the cake and > eat it... Well, that would be good. However I'm pretty convinced that a very good solution would be not moving to LGPL. While perhaps not the ultimate solution, I have a gut feeling that no better soltion exists in the real world. > I'll be back tomorrow with more opinions, and my stab at > thinking out of > the box. Your welcome.

2 1

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