wine-devel February 2002

wine-devel@winehq.org

142 participants
296 discussions

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

← Newer
1
...
17
18
19
20
21
22
23
...
30
Older →

Jump to page:

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 February 2002