Re: Wine license change
On Wed, Feb 13, 2002 at 10:56:52AM -0700, Brett Glass wrote: At 10:20 AM 2/13/2002, Dan Kegel wrote: No; the LGPL would provide a way for the vendors to sabotage one another -- and, most likely, ALL fail as businesses. Sabotage? Brett, you might be getting a bit carried away here. No, I'm not. Richard Stallman himself has stated that the purpose of the GPL's poison pill is to turn developers against their colleagues and the organizations for which they work. His writings even urge programmers to put GPLed code into the work they do for their employers for the express purpose of forcing them to give away the code! You keep on making unsubstantiated claims like this. Post some *exact* references (not quotes) to papers or transcriptions which support each of your points or I do not see how anyone on this list can continue to take you seriously. Plato (Do not CC me, please. I am on the list)
Request for wine-license list
Hallo, I repeat may proposal, as the license wars will probably rage on: Let us create a wine-license mailing list and discuss licenses there. Thanks -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Licensing response and an idea
Tony Bryant [EMAIL PROTECTED] wrote: The (L)GPL is thus extremely discriminatory against programmers. It just forces a different way of making money - charging for your time, not charging for your IP. Revolutionary concept - charge for work done. Doesn't exactly fit with the bill gates of this world, but for small programmers like myself, most of my work is one-offs anyway. what is so revolutionary about that idea?! Consulting services where they charge by the hour has been around for quite a while. The PROBLEM with this model is that it forces all the costs up front, thus making it unafforable for people without a large budget. A simple example goes as follows: Let's say I want a device driver for a scanner. I find a relatively proficient programmer and s/he said it's about $1000 worth of work. Under the *GPL model, I have 3 choices: 1) Pay him/her $1000 for a driver for a $200 scanner 2) Go out and play salesman and find others to defer the cost. 3) Write it myself (and for the sake of argument right now, let's say this isn't an option) Under the normal commercial route, you can make up other options that try to keep the per user cost down. (L)GPL just doesn't suit business people. i.e. those expecting to sit back and watch the money roll in. I really hate it when things are characterized in this fashion because it shows a fundamental misunderstanding of how normal businesses work. Companies that don't have monopoly power survives by accepting risks and deriving benefit from their success(es). If I spend $10M developing a software project, I'm not sitting back and watching the money roll in when the product starts selling. If you're good, you'll have more money at the end than when you started. If not, you'll fail. This is the main concept behind free enterprise. One has to wonder why it matters what other people do with Wine. Wasn't Wine developed because we wanted to run some windoze apps on linux? Who really cares what codeweavers, transgaming etc do to it. Just as long as I can still run my windows apps on linux, I'm happy. If lindows sells a few copies of what is effectively free, what skin is it off our noses? I was wondering that too, and have come to the following conclusion: Either 1) They believe like the FSF and don't think propriatary software should exist 2) Are not comfortable with the idea of giving up code freely for the good of all. 3) Misunderstand the effects of the *GPL 4) Expect to be paid in other people's work. -r
Re: WineCorp (was Re: Wine license change)
David Elliott [EMAIL PROTECTED] wrote: Thus what we really need is some entity that will always have an unlimited license to the complete wine codebase to do with it as it decides. I question assigning copyrights away from myself and to anyone else, is there some reason why signing an unlimited use license wouldn't be acceptable (and thus developers would still retain their own copyright) or is that effectively how it works anyway? This scheme would make the license awkward, because you have to add in oh, by the way, all the contributions you make will be given to winecorp with an unrestricted license clause. It is far cleaner and simpler to require contributions to assign the copyright. OpenOffice does this. Wine cannot stay X11 free-for-all forever. Reminds me of one of Roger Ebert's columns about the movie It's a Wonderfull Life. Because the movie is now public domain, anyone can use the original print for whatever purpose. This includes colorizing it and then selling the colorized version for a lot of cash (thanks Ted... yeah right). The colorized version is a bastardization of the movie and is one of those cases where you almost wish that copyrights didn't expire. Especially considering that the director and the much of the cast were still alive to see this horrible, horrible thing. Wine is very much in the same position here. While we are not quite public domain we are so close that any distinction is a moot point. *GPL wouldn't prevent the above either. Any open source license would let the above happen. As I said before, freedom means others can do what you don't like -r
Re: Licensing response and an idea
Brett Glass wrote: At 01:13 PM 2/13/2002, Christopher Dewey wrote: With the exception of the copyright holder(s), (L)GPL provides everyone with the same rights. The license does not discriminate between developers and potential developers. Not so. The (L)GPL allows everyone to use the code in the way that benefits him or her the most, EXCEPT for developers -- who not only may not use the code but may be exposed to claims of copyright infringement if they even read it in order to learn from it. The (L)GPL is also intended to destroy their markets, businesses, and livelihoods. The (L)GPL is thus extremely discriminatory against programmers. Brett, you continue to ignore that the (L)GPL implicitly treats *everyone* as programmers, regardless of their occupation, motives, intent, or what they actually end up doing with the software. By painting the license as discriminatory, and continuing your attacks on the FSF and RMS's politics on this list, you confuse the issue, and do this list and the Wine community a disservice. The issue at hand is that neither the LGPL, nor the current Wine license meet every Wine developer's needs and goals, with the consequense that the development effort spent on Wine may be slowed or fragmented. It's a real problem, and a compromise is required. I'm thankful that the principal Wine developers, including the representatives of commercial interests, all seem very level-headed and pragmatic with regard to the problem. Hopefully they will find a compromise that allows them to pursue their common goals, to the benefit of the greater Wine community.
[patch] - add several structs to ntddk.h
Hi folks...
I just sent the following patch to wine-patches. I thought it would be a good
idea to let you folks beat it up before someone actually commit's it to CVS...
The patch adds several struct definations to include/ntddk.h to assist getting
the NtQuerySystemInformation routine working. It also adds several enumerations
for the System Information Class.
By far, these are not complete, and I can only hope that they are accurate.
One thing you may notice is that HANDLEINFO and THREADINFO have been defined. I
believe there is already a less complete defination of the THREADINFO struct
(called THREAD_INFO) in the code already. This has been left untouched so that
this patch minimizes the potential side effects.
These are untested in that I have not tried to recompile with these changes in
place. My only concern: do FILETIME and LARGE_INTEGER data types exist?
Google is your friend - use it wisely!
--
Ron Gage - Owner, Linux Network Services - Saginaw, Michigan - 989-274-8088
Your one-stop source for Reliable, Secure and Affordable Networking Solutions
--- ntddk.h~Wed Dec 19 14:16:29 2001
+++ ntddk.h Thu Feb 14 07:32:31 2002
@@ -147,6 +147,21 @@
MaxThreadInfoClass
} THREADINFOCLASS;
+typedef struct {
+/* This is used by NtQuerySystemInformation */
+
FILETIME ftCreationTime;
+
DWORD dwUnknown1;
+
DWORD dwStartAddress;
+
DWORD dwOwningPID;
+
DWORD dwThreadID;
+
DWORD dwCurrentPriority;
+
DWORD dwBasePriority;
+
DWORD dwContextSwitches;
+
DWORD dwThreadState;
+
DWORD dwWaitReason;
+
DWORD dwUnknown2[5];
+} THREADINFO, *PTHREADINFO;
+
/* file information */
typedef enum _FILE_INFORMATION_CLASS {
@@ -220,12 +235,124 @@
/* system information */
typedef enum SYSTEM_INFORMATION_CLASS
-{
Unknown1 = 1,
-
Unknown2,
-
Unknown3,
+{
SystemBasicInformation = 0,
+
Unknown1,
+
SystemPerformanceInformation,
+
SystemTimeInformation,
Unknown4,
-
SystemPerformanceInformation
+
SystemProcessInformation,
+
Unknown6,
+
Unknown7,
+
Unknown8,
+
Unknown9,
+
Unknown10,
+
SystemDriverInformation,
+
Unknown12,
+
Unknown13,
+
Unknown14,
+
Unknown15,
+
SystemHandleList,
+
Unknown17,
+
Unknown18,
+
Unknown19,
+
Unknown20,
+
SystemCacheInformation
+
} SYSTEM_INFORMATION_CLASS, *PSYSTEM_INFORMATION_CLASS;
+
+typedef struct {
+/* System Information Class 0x00 */
+
DWORD dwUnknown1;
+
ULONG uKeMaximumIncrement;
+
ULONG uPageSize;
+
ULONG uMmNumberOfPhysicalPages;
+
ULONG uMmLowestPhysicalPage;
+
ULONG uMmHighestPhysicalPage;
+
ULONG uAllocationGranularity;
+
PVOID pLowestUserAddress;
+
PVOID pMmHighestUserAddress;
+
ULONG uKeActiveProcessors;
+
BYTE bKeNumberProcessors;
+
BYTE bUnknown2;
+
WORD wUnknown3;
+} SYSTEM_BASIC_INFORMATION;
+
+typedef struct {
+/* System Information Class 0x02 */
+
LARGE_INTEGER liIdleTime;
+
DWORD dwSpare[76];
+} SYSTEM_PERFORMANCE_INFORMATION;
+
+typedef struct {
+/* System Information Class 0x03 */
+
LARGE_INTEGER liKeBootTime;
+
LARGE_INTEGER liKeSystemTime;
+
LARGE_INTEGER liExpTimeZoneBias;
+
ULONG uCurrentTimeZoneId;
+
DWORD dwReserved;
+} SYSTEM_TIME_INFORMATION;
+
+typedef struct {
+/* System Information Class 0x05 */
+
DWORD dwOffset;
+
DWORD dwThreadCount;
+
DWORD dwUnknown1[6];
+
FILETIME ftCreationTime;
+
DWORD dwUnknown2[5];
+
WCHAR* pszProcessName;
+
DWORD dwBasePriority;
+
DWORD dwProcessID;
+
DWORD dwParentProcessID;
+
DWORD dwHandleCount;
+
DWORD dwUnknown3;
+
DWORD dwUnknown4;
+
DWORD dwVirtualBytesPeak;
+
DWORD dwVirtualBytes;
+
DWORD dwPageFaults;
+
DWORD dwWorkingSetPeak;
+
DWORD dwWorkingSet;
+
DWORD dwUnknown5;
+
DWORD dwPagedPool;
+
DWORD dwUnknown6;
+
DWORD dwNonPagedPool;
+
DWORD dwPageFileBytesPeak;
+
DWORD dwPrivateBytes;
+
DWORD dwPageFileBytes;
+
DWORD dwUnknown7[4];
+
THREADINFO ti[0];
+} SYSTEM_PROCESS_INFORMATION;
+
+typedef struct {
+/* System Information Class 0x0b */
+
PVOID pvAddress;
+
DWORD dwUnknown1;
+
DWORD dwUnknown2;
+
DWORD dwEntryIndex
+
DWORD dwUnknown3;
+
char szName[MAX_PATH + 1];
+} SYSTEM_DRIVER_INFORMATION;
+
+typedef struct {
+/* System Information Class 0x10 */
+
USHORT dwPID;
+
USHORT dwCreatorBackTraceIndex;
+
BYTE bObjectType;
+
BYTE bHandleAttributes;
+
USHORT usHandleOffset;
+
DWORD dwKeObject;
+
ULONG ulGrantedAccess;
+} HANDLEINFO, *PHANDLEINFO;
+
+
+typedef struct {
+/* System Information Class 0x15 */
+
ULONG CurrentSize;
+
ULONG PeakSize;
+
ULONG PageFaultCount;
+
ULONG MinimumWorkingSet;
+
ULONG MaximumWorkingSet;
+
ULONG unused[4];
+} SYSTEM_CACHE_INFORMATION;
/* reading coffee grounds... */
typedef struct _THREAD_INFO
-
This mail sent through IMP: http://horde.org/imp/
FW: Patch: Double-click support
It looks like this patch wasn't applied to CVS and I didn't see any comments here in wine-devel. Before I resubmit I just want to make sure that it wasn't turned down for any particular reason. =Michael C. Maggio http://www.voyd.net/ -Original Message- From: Michael C. Maggio [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 15, 2002 1:27 AM To: [EMAIL PROTECTED] Subject: Patch: Double-click support This patch adds support for double clicking in Wine. The added function, _is_dblclick(), is invoked with each button-down mouse event. The event must be the same button (left, middle, or right), at the same X,Y position, and occur within 500 milliseconds from the previous event. The original button-down event is still invoked regardless of the double-click. Tested in Starcraft. :) Ideally, we may eventually want to determine the double-click delay time from the registry, as it is a configurable Windows setting. But this should serve the purpose in the mean time. One last tidbit of info - I did not add a function prototype to any header files given the limited scope of this function. Whether this deviates from the Wine Development Standard (tm), I do not know. Perhaps a local prototype is more suitable in this case for the sake of ANSI-C compliance. I would appreciate knowing, at least, what the preferred method of prototyping is. ChangeLog: Adds support for double-click events via _is_dblclick(). =Michael C. Maggio http://www.voyd.net/ dblclick.diff Description: Binary data
Re: WineCorp (was Re: Wine license change)
At 04:26 AM 2/14/2002, Roger Fujii wrote: This scheme would make the license awkward, because you have to add in oh, by the way, all the contributions you make will be given to winecorp with an unrestricted license clause. It is far cleaner and simpler to require contributions to assign the copyright. OpenOffice does this. The danger of this approach is that EVERYONE -- even contributors -- must go to the organization that owns the copyright and ask, Mother, may I? before doing things with the code. Commercial entities will have no guarantee that they'll be allowed to use even their own contributions -- especially if their competitors are part of the body that grants permissions. Politics can also rear their head, with favoritism toward specific vendors. One of the nicest things about the current license is that you do not need to ask, wait, reveal your product plans to competitors (which will inevitably happen if they have representatives in the organization), and risk being denied permission to use the code. You can't run a business unless you can move ahead with confidence -- without having to ask Mother, may I? or tell competitors what you're up to. --Brett
Re: Wine license change
At 01:38 AM 2/14/2002, Plato wrote: No, I'm not. Richard Stallman himself has stated that the purpose of the GPL's poison pill is to turn developers against their colleagues and the organizations for which they work. His writings even urge programmers to put GPLed code into the work they do for their employers for the express purpose of forcing them to give away the code! You keep on making unsubstantiated claims like this. You can find them as well as I can. Just go to Stallman's gnu.org site. However, because you seem to insist on having me do your research for you, Stallman actually says this in an essay called What is Copyleft. Until January 1999, the version of the essay posted on the FSF site said the following: People who write improvements in free software often work for companies or universities that would do almost anything to get money. A programmer may want to contribute her changes to the community, but her employer may 'see green' and insist on turning the changes into a commercial product. When we explain to the employer that it is illegal to distribute the improved version except as free software, the employer usually decides to release it as free software rather than throw it away. In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away. Interestingly, in a case of almost Orwellian revisionism, Stallman removed the bit about seeing green from the version of the essay that's now published at http://www.gnu.org/copyleft/copyleft.html . He did this after I cited it on a public mailing list as an example of his strongly anti-business agenda. (However, the Web remembers: mirrors of the original text may be found throughout the Internet.) The revised essay still encourages programmers to incorporate GPLed code in their work as a way of monkey wrenching organizations, but it is now more subtle. --Brett Glass
Re: Wine license change
On Thu, Feb 14, 2002 at 10:41:05AM -0700, Brett Glass wrote: At 01:38 AM 2/14/2002, Plato wrote: [snip still unsubstantiated claim] You keep on making unsubstantiated claims like this. You can find them as well as I can. Just go to Stallman's gnu.org site. However, because you seem to insist on having me do your research for you, Stallman actually says this in an essay called Well actually it's your research because they are your claims. Do you not know how debates work? What is Copyleft. Until January 1999, the version of the essay posted on the FSF site said the following: People who write improvements in free software often work for companies or universities that would do almost anything to get money. A programmer may want to contribute her changes to the community, but her employer may 'see green' and insist on turning the changes into a commercial product. When we explain to the employer that it is illegal to distribute the improved version except as free software, the employer usually decides to release it as free software rather than throw it away. In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away. No that is completely untrue. It is clear to me from reading this passage that Stallman is talking about modifications to code already GPLed. He is *not* referring to putting GPLed code into proprietary products. Plato *** N.B. PLEASE DO NOT CC ME ON REPLIES
Re: shellexecute patch
On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote: Needed for Visual Studio.NET installer. Changelog: dlls/shell32: shell.c In ShellExecute16, make sure there is a space between command and parameters. Hmm, I suspect that might be wrong. (in case your ShellExecute16() is being called by ShellExecute(), that is) ShellExecute() was supposed to call WinExec() instead of WinExec16() (long filename support). I wrote a ShellExecute patch some weeks ago that didn't get applied, probably because there were compile warnings. But I might be wrong and your patch is completely independent of mine. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Wine license change
At 10:58 AM 2/14/2002, Plato wrote: No that is completely untrue. It is clear to me from reading this passage that Stallman is talking about modifications to code already GPLed. Not true. Stallman specifically asks programmers to put the code in for the EXPRESS PURPOSE of forcing it to be given away. Again, it would be a good idea for you to READ Stallman's essays (particularly the older versions, since some of the more recent ones have been toned down by his PR people even though his goals remain the same) before commenting. --Brett
Re: Wine license change
At 05:33 PM 2/13/2002, Anthony Taylor wrote: Currently, there are only a few software companies making huge amounts of money. It's not *just* Free Software-based software companies. Cygnus had problems making money; so is Borland. Ironically, Borland is having trouble because it made the mistake of targeting the Linux platform. Many Linux users have moral objections to paying for a product, and so either have not bought Kylix or have pirated it. At the February 2000 LinuxWorld, Bradley Kuhn of the FSF disparaged Borland's products in front of a large audience. He told the group that Borland's products are a proprietary threat to freedom, and urged developers in the audience to write a GPLed clone and not to buy Borland's tools. Red Hat isn't terribly profitable yet; It has lost millions over its lifetime. I do not believe it will make it in the end. Be Corp. went belly-up. Interestingly, Be failed because it was squeezed between Microsoft on the one hand and Linux on the other. Microsoft damaged Be by precluding pre-installs, but Linux did even more damage by undercutting BeOS on price. Fact is, it's hard for a start-up to make money at all in the current software industry. It's not the licensing model that is the problem; it's the industry itself. Licensing models matter a great deal. Yes, it's easier to make money when you induce artificial scarcity in a product. Insisting that you be paid before giving someone your work is not inducing artificial scarcity any more than my refusal to do, say, unpaid plumbing work is doing so. It's simply necessary to earn a living! ;-) --Brett
Re: Wine license change
At 07:10 PM 2/13/2002, Dan Kegel wrote: It may not matter too much how IP-oriented businesses feel about the issue, since (according to many prognosticators) the future is in services. Wasn't this fallacy about as thoroughly debunked as possible by the dot.com bust? --Brett Glass
Re: shellexecute patch
On Thu, 14 Feb 2002 19:14:28 +0100, you wrote: On Thu, Feb 14, 2002 at 11:57:55AM +0100, Rein Klazes wrote: Needed for Visual Studio.NET installer. Changelog: dlls/shell32: shell.c In ShellExecute16, make sure there is a space between command and parameters. Hmm, I suspect that might be wrong. (in case your ShellExecute16() is being called by ShellExecute(), that is) ShellExecute() was supposed to call WinExec() instead of WinExec16() (long filename support). I wrote a ShellExecute patch some weeks ago that didn't get applied, probably because there were compile warnings. But I might be wrong and your patch is completely independent of mine. I think so. The patch is just preventing that ShellExecuteA( ..., K:\\setup.exe,option,...) will cause a call to WinExec16(K:\\setup.exeoption) that fails for a file not found error. Rein. -- Rein Klazes [EMAIL PROTECTED]
Re: WineCorp (was Re: Wine license change)
At 06:48 PM 2/13/2002, David Elliott wrote: The main problem with LGPL is that once we go there we can never go back. I agree. Wine cannot stay X11 free-for-all forever. Why not? BSD has. X11 has. Apache has. Reminds me of one of Roger Ebert's columns about the movie It's a Wonderfull Life. Because the movie is now public domain, anyone can use the original print for whatever purpose. This includes colorizing it and then selling the colorized version for a lot of cash (thanks Ted... yeah right). The colorized version is a bastardization of the movie and is one of those cases where you almost wish that copyrights didn't expire. Especially considering that the director and the much of the cast were still alive to see this horrible, horrible thing. I happen to agree, though I don't think it's horrible -- just weird. The best thing we can do is vote with our feet and not buy or rent that version. The same would be true of a bad commercial version of WINE. However, the X11 license has the great advantage that it is extremely flexible. So flexible that anyone who wanted to could take the tree and release it under any other license. Actually, no. You can't change the license on existing code. But you can combine it with code that's licensed differently. Looking at some of the more popular BSD-type licensed projects, many of them have this sort of non-profit set-up. Apache would be the one that springs to mind immediately, I'm sure there are others. FreeBSD and NetBSD do as well. But they administer the trademarks and handle contributions; they don't try to restrict access to the code. --Brett
Question to Brett Glass
The longer I read your posts on this mailing list, the more I think you don't like Open Source or Free projects. You like commercial projects, with lawyers, profits and copy protection. Why don't you say that Linux is a sabotage of HP,IBM, Microsoft,(non-exhaustive list) OS providers ? Note that closed source programs are consuming time, employees,money... and are slowing the development. _All_ the code that is not free is today forked somewhere in a vendor's program. Every company reinvents the wheel. In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away. If I were a the boss of an ecologic team, I would urge my colleagues to respect the nature... Wouldn't you ? :-) ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
Re: Wine license change
On Thu, 2002-02-14 at 13:29, Brett Glass wrote: At 05:33 PM 2/13/2002, Anthony Taylor wrote: Currently, there are only a few software companies making huge amounts of money. It's not *just* Free Software-based software companies. Cygnus had problems making money; so is Borland. Ironically, Borland is having trouble because it made the mistake of targeting the Linux platform. Many Linux users have moral objections to paying for a product, and so either have not bought Kylix or have pirated it. At the February 2000 LinuxWorld, Bradley Kuhn of the FSF disparaged Borland's products in front of a large audience. He told the group that Borland's products are a proprietary threat to freedom, and urged developers in the audience to write a GPLed clone and not to buy Borland's tools. Borland was in trouble well before it ported its products to Linux. Now you're just rationalizing. Their port to Linux was an attempt to move into a potentially-unexploited development platform. And attributing Be's downfall to Linux is absurd; they addressed completely different OS spaces. Be targetted multimedia production, an area Linux in which Linux is not strong. Plus, Be had been around long before Linux became well-known. Also, you haven't addressed any of the failed software companies that had nothing to do with Linux, or GPLd code. Yes, it's easier to make money when you induce artificial scarcity in a product. Insisting that you be paid before giving someone your work is not inducing artificial scarcity any more than my refusal to do, say, unpaid plumbing work is doing so. It's simply necessary to earn a living! ;-) Plumbing is done on a case-by-case basis. You are paid for the work you do when you do it; this is hardly artificial scarcity. The same can happen in programming. I do that; I am paid as I do my work. I make good money. Others do the same thing. I do not feel cheated at all. The artificial scarcity comes when a proprietary software company released binary-only programs, charging an exorbitant sum for the privelege of using their software. If the software is buggy, there is no recall, there are rarely patches that fix any but the most serious bugs/security holes, and there is no chance to fix the software yourself. You cannot give the software to someone you know. Fine: this is copyright law, and is the perogotive of the publisher. Most coding is not done in a proprietary software house. Most is done internally, in banks and pizza parlors and museums and government labs. Most coders get paid for writing code that will never be sold. (It does, however, have intrinsic value to the company.) If these coders choose to code on the side, it is their perogotive to determine how their code is used. For my code, I place the same restrictions on proprietary software houses that they would place on me. This is the bronze rule: Do unto others as they would do unto you. I'm damned spiteful, so that is what I do. Plus, it's my code, I can do whatever I please with it, for the *exact same* reason proprietary software houses can restrict their code however they wish. There's a certain symmetry here. Most programmers who get paid to produce proprietary software do not get rich off their work. The successful software companies do. I am paid about the same as most programmers working for Microsoft. I don't produce as much code(my duties are primarily database related, not code related). *I am not getting cheated by writing GPL code.* I am not cheating anyone else by writing GPLd code. - Tony PS: Sorry, I know I signed out of this discussion. I apologize for getting sucked back in; but my emotions are running hot over this issue.
Re: shellexecute patch
On Thu, Feb 14, 2002 at 07:40:54PM +0100, Rein Klazes wrote: On Thu, 14 Feb 2002 19:14:28 +0100, you wrote: But I might be wrong and your patch is completely independent of mine. I think so. The patch is just preventing that ShellExecuteA( ..., K:\\setup.exe,option,...) will cause a call to WinExec16(K:\\setup.exeoption) that fails for a file not found error. Hmm, thinking more about it (hmm, should have done that before :), I guess you're absolutely and completely 100% right. I really don't want to know how many installers failed due to this problem... (I'm certainly remembering several cases that almost cry for correlation to this fix...) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: WineCorp (was Re: Wine license change)
Brett Glass wrote: At 04:26 AM 2/14/2002, Roger Fujii wrote: This scheme would make the license awkward, because you have to add in oh, by the way, all the contributions you make will be given to winecorp with an unrestricted license clause. It is far cleaner and simpler to require contributions to assign the copyright. OpenOffice does this. The danger of this approach is that EVERYONE -- even contributors -- must go to the organization that owns the copyright and ask, Mother, may I? before doing things with the code. well, I think the assumption here was that winecorp would always release an lgped (or whatever viral license) version of the tree, so that 'normal' use would not be inhibited. I suppose there is a small window between submission/transfer of copyright and the publication into the tree where the maintainer/licensor may go insane and to something silly, but that scenario would definitely fall under done in bad faith. Commercial entities will have no guarantee that they'll be allowed to use even their own contributions -- especially if their competitors are part of the body that grants permissions. Politics can also rear their head, with favoritism toward specific vendors. you do have a point - given that this licensing issue started up again because of what appears to be competitive/political reasons, I guess one shouldn't ignore the possible influence it might have in the future. -r
Re: Dr. Seuss, licensing, and WINE
At 11:31 AM 2/8/02 -0700, Brett Glass wrote: Perhaps a simple economic analysis would help to assuage those egos. [SNIP] The (L)GPL destroys this delicately balanced symbiotic relationship by making it impossible for the vendor to add unique value. As a result, the scenario described above can't happen, and it's a lose/lose rather than a win/win. The I agree with most of what you said, but have a few NEW questions: 1. Companies that benefit from WINE in this way have no incentive to contribute back. So why should they? That means that this kind of companies are of no big help to WINE, so why should we help them with the licensing scheme? 2. Companies like CodeWeavers that have a different business model probably would share code back even with the xGPL. They don't lose anything for doing it. And with the xGPL they don't have to fear that a competitor will make money out of their work. In fact any producer of a Windows app is a potential contributer to WINE, since he will help to make its app run under Linux. A xGPLed WINE would help ensure that the improvements made by those companies come back to the community. This of course without loss to the contributer, since selling WINE will not be his business. So after all it seems that maybe xGPL is an advantage, even if it prevents some companies from making money from WINE. What do you think about that? Roland
Re: Wine license change
On Thu, Feb 14, 2002 at 11:18:20AM -0700, Brett Glass wrote: At 10:58 AM 2/14/2002, Plato wrote: [Snip easy to understand quote] No that is completely untrue. It is clear to me from reading this passage that Stallman is talking about modifications to code already GPLed. Not true. Stallman specifically asks programmers to put the code in for the EXPRESS PURPOSE of forcing it to be given away. Don't be silly. He doesn't. Again, it would be a good idea for you to READ Stallman's essays [...] If you would attempt to win an argument, it would be a good idea that you post references rather than spouting the same rhetoric again and again. I have had enough of listening to you and attempting to correct you. You seem determined to misrepresent someone or something whenever you speak. I shall not waste any more of the Wine developers precious time by posting to the list. You clearly have nothing useful to contribute. I recommend that everyone ignore you from now on. I hope the Wine developers can keep up the good work whatever license they choose. I wish you well guys. Goodbye, Plato P.S. For the last time, please do not reply to me directly: only to the list. PLEASE!
Re: Dr. Seuss, licensing, and WINE
At 12:10 PM 2/14/2002, Roland wrote: I agree with most of what you said, but have a few NEW questions: 1. Companies that benefit from WINE in this way have no incentive to contribute back. It may not seem obvious at first, but in fact they have a strong incentive to contribute back. Any patch that's not contributed back to the main source tree must be re-integrated again and again -- and there's often no other way to do this than by hand. It only pays to reserve code that's very strategic. So why should they? That means that this kind of companies are of no big help to WINE, so why should we help them with the licensing scheme? It *is* mutually beneficial to maintain a truly free license. See above. 2. Companies like CodeWeavers that have a different business model probably would share code back even with the xGPL. I have not been able to come up with any business model where it pays not to give back non-strategic code. They don't lose anything for doing it. And with the xGPL they don't have to fear Why is this a fear? In exactly what way does it hurt CodeWeavers when someone else is making money via products that are not in direct competition with what CodeWeavers sells? that a competitor will make money out of their work. As explained in an earlier message, a company that uses the code in a product can only make money from its *own* work. In fact any producer of a Windows app is a potential contributer to WINE, since he will help to make its app run under Linux. Only if he sees Linux as a platform worth supporting! There is still significant expense involved in doing a WINE port, and he has to be convinced that he'll make money in the Linux world. (Which is by no means a sure thing. Borland is losing its shirt on Kylix because most Linux users apparently won't pay for tools.) Use of Linux to run Windows apps must become widespread before you'll see many ports. And this won't happen if WINE isn't truly free (see below), because companies such as Lindows won't be around to promote the idea. A xGPLed WINE would help ensure that the improvements made by those companies come back to the community. I disagree. Many will turn tail and run. Others will fork the last truly free version. And the rest will try to make money but fail, because they cannot differentiate their products due to the (L)GPL. Have I answered your questions adequately? --Brett
Re: Question to Brett Glass
At 12:02 PM 2/14/2002, Sylvain Petreolle wrote: The longer I read your posts on this mailing list, the more I think you don't like Open Source or Free projects. Not true. I'm very much in favor of a truly free intellectual commons, and I'm very thankful for the existence of code such as BSD and Apache. But (L)GPLed code is neither open source nor free. That the FSF says otherwise cannot change this fact. You like commercial projects, with lawyers, profits and copy protection. I do like some commercial products very much, and I like the companies that make them to make profits so that the products will continue to be improved. I like coding for a living, and I do not want the FSF and its licenses to succeed in its agenda, which consists of wiping out all commercial software and destroying decent jobs for programmers. On the other hand, I strongly support the notions of fair use and the first sale doctrine, and I don't buy copy protected software. As for lawyers: Hiring them is sometimes a necessary expense (for example, if you're negotiating a contract). But I wouldn't say that I like using them. Why don't you say that Linux is a sabotage of HP,IBM, Microsoft,(non-exhaustive list) OS providers ? Anything that's GPLed throws a monkey wrench into the relevant market, and (if it's any good) eventually destroys all competition. GCC is great example. It's a mediocre compiler, but notably *better* compilers -- the ones I need for some of the work I do -- are not selling. GCC was one of the very first FSF projects. The others, as they progress, are beginning to have similar effects on the markets which they have invaded. The progression leads, inexorably, to the extinction of alternatives and the elimination of user choice. Note that closed source programs are consuming time, employees,money... and are slowing the development. I disagree. In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away. If I were a the boss of an ecologic team, I would urge my colleagues to respect the nature... Wouldn't you ? :-) Yes. And the purpose of the GPL is to poison the well of truly free software that existed long before Stallman founded the FSF. That ecology was balanced. The GPL injects a poison pill designed to destroy the commercial players, destroying the delicate symbiosis between commercial and freely available software. --Brett
Re: Licensing response and an idea
It's a real problem, and a compromise is required. The current license is far and away the best compromise. The (L)GPL is not a compromise; it is an extreme. The public domain is the other extreme. The X11 license sits in the middle. The words of a man who has no intention, interest or desire to compromise. There is no need to compromise because my way is the right way. Brett, no one on this list that has read your posts fails to see your point. Some of them disagree, some of them agree, but a) you have no formal say in the decision (of course, you're free to do as you've done and bemoan the issue) and b) you have shown no willingness to look at the points of view of the other members of this list who don't think the same way you do. I think it's time you, to use a phrase, either put up or shut up. If you want people to listen to you more than you've listened to them, then write some code. Then, people might be more interested in what you have to say. Saying Well, I *might* contribute, so long as you don't change the license and presuming that your vapourware-work is any sort of argument for people to listen to you and do what you want, is ridiculous, childish and egotistical. We've heard your arguments and attacks on the FSF and RMS. Fine, you've stated your case and made your point. Now let the people that can actually make the decision make it. Regards, Marcus Brubaker
Re: Licensing response and an idea
Brett Glass wrote: At 08:13 AM 2/14/2002, Christopher Dewey wrote: Brett, you continue to ignore that the (L)GPL implicitly treats *everyone* as programmers, regardless of their occupation, motives, intent, or what they actually end up doing with the software. Not true. It singles out the activities in which only professional programmers need to engage in order to make a living, and penalizes that group specifically by attempting to prevent them from making a living. The GNU Manifesto explicitly states this intent. Many professional programmers do their work for hire, with no say in the license applied to their work, whether it's GPL, BSD or MS-EULA. The GNU Manifesto is off-topic and irrelevant to this discussion; the FSF does not speak for me, nor does it speak for the Wine developers, I dare say. The issue at hand is that neither the LGPL, nor the current Wine license meet every Wine developer's needs and goals, with the consequense that the development effort spent on Wine may be slowed or fragmented. Is that possible? What if the goal of some of the developers is simply to sabotage the business models of others? There have been discussions on Linux gaming fora wrt whether TransGaming and Wine were sabotaging Loki Games' business model. It's bullshit, of course. Sabotage is a bullshit argument here, too. I've seen *nothing* in six years as a Wine user and following Wine development that suggest any of the developers acting in bad faith toward the whole of the Wine community. But more importantly, your accusations of sabotage, and your diatribe against the FSF and Rihcard Stallman do not belong on this list. It's a real problem, and a compromise is required. The current license is far and away the best compromise. The (L)GPL is not a compromise; it is an extreme. The public domain is the other extreme. The X11 license sits in the middle. It's the best for you, perhaps. Jeremy White has expressed that it's no longer the best compromise for *his* business model. You clearly have no respect for that, but then you're not arguing honestly here; you have a political agenda and an axe to grind. Please do it elsewhere.
Question concerning internal string usage
Some functions are duplicated with their only difference being that one of them is wide character (W) and the other is ASCII (A). Of course it makes sense to convert one of them into the other and reuse the existing code. What I was wondering about, though is that, at least in the exmaple of files/profile.c the W functions are converting to A instead the other way around. Shouldn't we expect some problems with systems using wide characters or is this handled such that these characters are represented as more then one characters in ASCII? In Windows I'm pretty sure that A is always converted to W for such functions.
Re: WineCorp (was Re: Wine license change)
At 12:10 PM 2/14/2002, Roger Fujii wrote: well, I think the assumption here was that winecorp would always release an lgped (or whatever viral license) version of the tree, so that 'normal' use would not be inhibited. The implication here is that the use of freely available code as the basis of commercial products is somehow not normal. I'm not sure how you can say this, because it is really very common. Every modern operating system contains code from BSD, for example. Commercial entities will have no guarantee that they'll be allowed to use even their own contributions -- especially if their competitors are part of the body that grants permissions. Politics can also rear their head, with favoritism toward specific vendors. you do have a point - given that this licensing issue started up again because of what appears to be competitive/political reasons, I guess one shouldn't ignore the possible influence it might have in the future. Politics always seem to get in the way in the world of freely distributable software. For example, the trademark FreeBSD is currently owned by one of the distributors of FreeBSD, not by the FreeBSD Foundation. It was supposed to transfer the trademark, but never has. In theory, this could allow it to shut down the other distributors unless they used a different name for the software. Linux also has its politics; witness the multi-way tug of war between ESR, Perens, and Stallman. --Brett
Re: Licensing response and an idea
At 12:15 PM 2/14/2002, Marcus Brubaker wrote: I think it's time you, to use a phrase, either put up or shut up. If you want people to listen to you more than you've listened to them, then write some code. I'd like to. But I will not release code under an FSF license, so I can only do so if I know that the project won't try to xGPL my work. --Brett
RE: drawtext should not split words on clipping
-Original Message- From: Joerg Mayer [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 2:42 PM To: Medland, Bill Cc: Wine patches (E-mail) I think we're supposed to discuss these on wine devel Subject: Re: drawtext should not split words on clipping I've only read the description, so maybe I'm guessing wrongly what the path does. Sometimes it is preferrable to split a word in the middle to not splitting very long words (like URLS). Yes, but you don't split it by saying it should be clipped; you split it by specifying, for example, DT_WORDBREAK | DT_EDITCONTROL (which results in breaking within the word if the whole word doesn't fit) This is a small part of a long sequence of changes that, I believe, are required to make DrawText work correctly overall, especially when it comes to ellipsification and word breaking on multiple lines. (The current version believes that ellipsification is only done if DT_SINGLELINE is specified!!). Maybe there is some case where the existing code worked by accident and it doesn't now but if so then I believe it should be fixed properly (which won't really be possible until I've submitted a couple more major reworks). Actually it's getting difficult to figure out how to do the next stage without a 500 line delta, because somewhere along the line I think it requires a complete revamp of the core routine (and, tempting as it may be, I am not happy submitting 250 lines of code that aren't yet called but will be when I submit the next delta). I am perfectly happy to discuss this with anyone who wants to; otherwise please bear with me. I honestly believe I know what I am doing. Regards Bill
Wine's path VS host path
Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is self-contained. The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to hang around for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process.
Re: Question concerning internal string usage
On Thu, 14 Feb 2002, Gerhard Gruber wrote: Some functions are duplicated with their only difference being that one of them is wide character (W) and the other is ASCII (A). Of course it makes sense to convert one of them into the other and reuse the existing code. What I was wondering about, though is that, at least in the exmaple of files/profile.c the W functions are converting to A instead the other way around. Shouldn't we expect some problems with systems using wide characters or is this handled such that these characters are represented as more then one characters in ASCII? In Windows I'm pretty sure that A is always converted to W for such functions. Yes, you are supposed to implement xxxA by calling xxxW and not the other way around. But historically, the xxxA functions have been implemented first and the xxxW came later. And it's easier to just call the xxxA function than to move all the code around to do things the right way. Still, the xxxW - xxxA instances need to be fixed and they, slowly, are. You are welcome to lend a hand. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
Re: Question to Brett Glass
--- Brett Glass [EMAIL PROTECTED] a écrit : Not true. I'm very much in favor of a truly free intellectual commons, and I'm very thankful for the existence of code such as BSD and Apache. But (L)GPLed code is neither open source nor free. That the FSF says otherwise cannot change this fact. Would you say that Linux is not free ? I do like some commercial products very much, and I like the companies that make them to make profits so that the products will continue to be improved. I like coding for a living, and I do not want the FSF and its licenses to succeed in its agenda, which consists of wiping out all commercial software and destroying decent jobs for programmers. What could you say about Microsoft trying to destroy the concurrence ? For example Netscape ? A programmer can be paid even he makes free code. And these are other commercial ways : distribution packaging services, on-line services... If you say that companies distributing free software are loosing money, look RedHat and consider : why is it not dead after years and years ? On the other hand, I strongly support the notions of fair use and the first sale doctrine, and I don't buy copy protected software. As for lawyers: Hiring them is sometimes a necessary expense (for example, if you're negotiating a contract). But I wouldn't say that I like using them. Anything that's GPLed throws a monkey wrench into the relevant market, and (if it's any good) eventually destroys all competition. GCC is great example. It's a mediocre compiler, but notably *better* compilers the ones I need for some of the work I do -- are not selling. GCC was one of the very first FSF projects. The others, as they progress, are beginning to have similar effects on the markets which they have invaded. The progression leads, inexorably, to the extinction of alternatives and the elimination of user choice. Note that closed sources are slowing development. I disagree. In this case, qualify the time Linux has taken to become as today. Windows took 20 years and so. In short, Stallman urges programmers to sabotage their employers' IP -- by injecting GPLed code into it -- so that it must be given away. Yes. And the purpose of the GPL is to poison the well of truly free software that existed long before Stallman founded the FSF. That ecology was balanced. The GPL injects a poison pill designed to destroy the commercial players, destroying the delicate symbiosis between commercial and freely available software. It's not destruction, it's only the competition ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
Re: Wineconf attendance
Michael Robertson wrote: On the technical track, since attendees will be the speakers please think about the topic that would be interesting that you are knowledgeable about. This is all about people leaving smarter than they came and that happens best with everyone sharing their information and ideas. One of the 3 people on the Frankfurt/San Diego express, Dr. Ulrich Weigand has volunteered to speak on the following two topics: - 16-bit Windows: how does the support for 16-bit in Wine work, how much 16-bit code is still there in Windows 95/98/ME, how are the various types of thunks etc. implemented, what are the chances of running native Windows 95/98/ME 16-/32-bit DLL pairs under Wine (this would include the user.dll question Uwe suggested) - Debugger: how does the Wine debugger work, details about the various debugging formats (including the undocumented .PDB format) ... The LPBN has indicated they'd be willing and able to videotape the presentations for later free access via their web streaming server (http://www.lpbn.org). Michael, could Lindows make a small donation, say $500, to lpbn.org to help cover expenses? - Dan
Re: Licensing response and an idea
The issue at hand is that neither the LGPL, nor the current Wine license meet every Wine developer's needs and goals, with the consequense that the development effort spent on Wine may be slowed or fragmented. It's a real problem, and a compromise is required. I'm thankful that the principal Wine developers, including the representatives of commercial interests, all seem very level-headed and pragmatic with regard to the problem. Hopefully they will find a compromise that allows them to pursue their common goals, to the benefit of the greater Wine community. .well said and thats my hope as its been all alongI am not a programmer at this stage in my life albeit I'm learning swiftly, but I do use Linux and its meant a great deal to me to be able to do so from so many different angles I can't begin to tell you. Linux is about choice and open sharing for the greater good and I'm excited about the possibilities laid before me,- and can only hope these matters are settled swiftly and consisely in a way that as Christopher so eloquently summed..is good for the team that has worked so hard to get this far,the greater wine 'community' and likely those that are utilising that same code will decide that the basis on which this was founded warrants respect in said decisions. To do less leads us where ? cu lee -
Re: Licensing response and an idea
On Thu, Feb 14, 2002 at 03:51:23PM -0700, Brett Glass wrote: At 12:15 PM 2/14/2002, Marcus Brubaker wrote: I think it's time you, to use a phrase, either put up or shut up. If you want people to listen to you more than you've listened to them, then write some code. I'd like to. But I will not release code under an FSF license, so I can only do so if I know that the project won't try to xGPL my work. You believe in releasing code under BSD-style licenses, but you refuse to do so unless you have assurances that no one will create a GPLed product from that code as allowed by the BSD license? Hypocritical jerk. Steve Langasek postmodern programmer
Re: Wine's path VS host path
On Thu, 14 Feb 2002, David D. Hagood wrote: Due to circumstances beyond my control, I have an embedded system that I am developing that uses Windows based compilers. Unfortunately, WinNT bluescreens too much for me to be able to work, so I have ported the project to using Gnu Make, with the compilers being executed via Wine. The problem is that the compilers search the path for their sub-components (just like GCC does - the driver calls the preprocessor, compiler, assembler, etc.). Now, the location of the project within the filesystem is not fixed - it depends upon where the developer checks it out. The project has the compilers stored along with the code, so the project is self-contained. The project has a shell script that sets several environment variables describing the location of the project, and adds the needed directories to the Unix path. However, Wine (wisely) does not make that path available to the Windows program, so when the compiler driver looks for the preprocessor, it bombs. Pity you couldn't use some other environment variable. The entire unix environment is available in the windows app's environment, but PATH is significant to windows apps, I guess, so wine takes the windified version of it from the config file to replace the *NIX value. If your compiler would look in, say MYPATH, a shell script could easily set that how it liked. *nix current directory is another possibility you should consider. If it happens that it can be accessed somewhere on a Wine drive, Wine will use it as the windows current directory, which is on the windows path, I think, implicitly. If not it will use the windows directory and write a mesage to that effect. As a work-around, I've stated the the developers must install the tools into a fixed directory, and add that directory to the Windows path as defined in ~/.wine/config. However, it would be nice if the setup shell script could add the tools directory within the project automatically to the Wine path. Has any thought been given to honoring a WINEPATH (or similar) environment variable, which would be added to the Wine path at runtime? On a related note: would it be possible to have a means to tell the wineserver process to hang around for a few seconds after the last wine process using it has terminated? Again, in this make process you get lots of start wine, start compiler, compile, exit. Start wine, start compiler, compile, exit operations - if the wineserver stuck around for 2 seconds after the last wine process terminated, this would aviod starting and stopping the wineserver process. start wineserver -p before starting any compiles, it will serve until it is killed. kill it with -INT or -TERM, please, not -KILL. -KILL will force it to leave a stale socket you will have to remove by hand. Lawson GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.
Re: OT: Wine build system tech info
On 2002.02.13 23:41 Alexandre Julliard wrote: [SNIP] Actually an advantage of a makedep tool is that you generate all the dependencies for a directory in one step. This means that you only need to parse each include file once, even if it is included from multiple .c files. This can easily be an order of magnitude faster than preprocessing each file individually (though with recent gccs you can use gcc -MD to generate dependencies while compiling the file, which is even more efficient; sadly it's not portable). Ah yes.. good point. I'll probably wind up using Wine's makedep for my project then. If I recall though, it had issues with includes that were only included if something was specifically defined. Maybe I should take another look at it. X11's makedepend still chokes on #if's with logical operators and also likes to generate dependencies for the system headers too which just fills up the makefile with tons of dependency info. Maybe I can find some time to look through and extend Wine's makedep to be a bit more usefull for projects other than Wine. Or maybe I should read a bit more documentation on it first. :-) -Dave
Re: Wine's path VS host path
[EMAIL PROTECTED] wrote: Pity you couldn't use some other environment variable. The entire unix Yes, but make must also be able to find the tools, hence they are in the path (I am using Linux's binfmt_misc with the appropriate settings so that the programs are directly executable). compiler would look in, say MYPATH, a shell script could easily set that how it liked. If I had the source, it would already be running natively. However, in this case I don't - the compiler is for a DSP, and is most definitely Closed Source *nix current directory is another possibility you should consider. If The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option. wineserver -p Great! One down, one to go. I'll add that to the initial setup shell script. Perhaps, one fine day when I'm not trying to get a 160G drive to play nice in my computer, and I've taken the time to get ADPCM working in Wine, I can add some sort of additional path environment logic in. And **I** would actually rather release under LGPL, thankyouverymuch.
Re: Wine license change
On 2002.02.14 15:25 Plato wrote: [BIG SNIP] P.S. For the last time, please do not reply to me directly: only to the list. PLEASE! Actually, the ettiquette on this list is to hit Reply All and thus post both directly to the people involved in the discussion and also to the mailing list. Personally I prefer this, and I was actually about to write an e-mail to Brett bitching about him replying to one of my mails, twisting my words around, and sending it only to the list. I filter the list based on the headers from the list server. So if the mail came through the list it goes into the wine-devel mailbox. However when you send a mail both to me and cced to the list I get two copies.. one in my normal inbox which I can read and reply to immediately, and one which is in with the rest of the stuff in the mailbox for the list. There have been lots of discussions about this in the past, so please don't flame someone (even if he is a flamer in all senses of the word) for doing what everyone else on the list does. -Dave
Re: Licensing response and an idea
On Thu, 14 Feb 2002 13:58, Christopher Dewey wrote: Brett Glass wrote: The current license is far and away the best compromise. The (L)GPL is not a compromise; it is an extreme. The public domain is the other extreme. The X11 license sits in the middle. It's the best for you, perhaps. Jeremy White has expressed that it's no longer the best compromise for *his* business model. You clearly have no respect for that, but then you're not arguing honestly here; you have a political agenda and an axe to grind. Please do it elsewhere. The only problem is that we don't know what the problem is. We have been informed that Jeremy has a problem with the current license but not what the problem is. His solution is to change the license although it may not be in the best interest of Lindows and TransGaming. According to your inference to Brett, he would be showing them no respect to *their* business models. Sean P.S. I am not implying Jeremy is trying to do anything against either Lindows or TransGaming; I am just playing devil's advocate. IOW, no flames please. :) -- [EMAIL PROTECTED]
Re: Dr. Seuss, licensing, and WINE
On Thu, 14 Feb 2002 16:10, Roland wrote: At 11:31 AM 2/8/02 -0700, Brett Glass wrote: Perhaps a simple economic analysis would help to assuage those egos. [SNIP] The (L)GPL destroys this delicately balanced symbiotic relationship by making it impossible for the vendor to add unique value. As a result, the scenario described above can't happen, and it's a lose/lose rather than a win/win. The I agree with most of what you said, but have a few NEW questions: 1. Companies that benefit from WINE in this way have no incentive to contribute back. So why should they? That means that this kind of companies are of no big help to WINE, so why should we help them with the licensing scheme? Are you saying that because a company has no incentive to contribute that we should force them even though they (Lindows and TransGaming) are contributing? I do not mean to be rude, but that sounds a little spiteful. 2. Companies like CodeWeavers that have a different business model probably would share code back even with the xGPL. They don't lose anything for doing it. And with the xGPL they don't have to fear that a competitor will make money out of their work. If they will share regardless of the license, there is no reason to change the license for this. In fact any producer of a Windows app is a potential contributer to WINE, since he will help to make its app run under Linux. A xGPLed WINE would help ensure that the improvements made by those companies come back to the community. This of course without loss to the contributer, since selling WINE will not be his business. The license can be BSD, X11, Apache, LGPL, GPL or MS-EULA and have the same effect on these companies, therefore, a license change for this reason is moot. So after all it seems that maybe xGPL is an advantage, even if it prevents some companies from making money from WINE. I have still not seen a good reason to change the license. What do you think about that? Personally, I think the movement to change the license is political as I have yet to read a reason to change it that was not about enforcing code contributions. This is not including Jeremy's request which I think is commercial in nature. Sean -- [EMAIL PROTECTED]
Re: FW: Patch: Double-click support
Michael C. Maggio [EMAIL PROTECTED] writes: It looks like this patch wasn't applied to CVS and I didn't see any comments here in wine-devel. Before I resubmit I just want to make sure that it wasn't turned down for any particular reason. Double click is already implemented, look in windows/message.c. If it doesn't work for you there's probably something else going on. -- Alexandre Julliard [EMAIL PROTECTED]
Re: OT: Wine build system tech info
David Elliott [EMAIL PROTECTED] writes: I'll probably wind up using Wine's makedep for my project then. If I recall though, it had issues with includes that were only included if something was specifically defined. Maybe I should take another look at it. Wine's makedep doesn't attempt to handle #if or #ifdef at all. This sometimes results in more dependencies than strictly necessary, but at least for Wine this isn't a problem. And it makes things much simpler. Maybe I can find some time to look through and extend Wine's makedep to be a bit more usefull for projects other than Wine. Or maybe I should read a bit more documentation on it first. :-) If you want to read documentation on Wine's makedep, you'll have to write some first ;-) -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine's path VS host path
On Thu, 14 Feb 2002, David D. Hagood wrote: The project is a rather large one, comprised of over 9000 files in many different directories. Having the tools always in CWD isn't an option. Well, maybe I am stupid, but I don't see why you can't just install the tools somewhere, and add the windows path to that somewhere to Wine's Path = and be done with it. Unless the leafnames of the tools have different meanings depending where they are called from, and they are called only by leafname, that should about do it. You mentioned binfmt_misc, and GNU make, IIRC, so maybe what you miss is that you can always call an executable by absolute or relative pathname as well as by leafname; if called by leafname from *NIX, it will be searched for in the *NIX path, and the wine path doesn't matter. If it is not any other kind of executable, and binfmt_misc finds it to be a wine executable, it will call on wine to execute it, and IIRC it will give Wine the absolute path to find it by. What exactly is the problem? :-) Lawson Probable user head space error. - Dennis A. Moore
Re: Wine License change: Open question to Jeremy White
Hi, Last time you just said you had personal problems. Now you are just hiding away. When a company wants to have the money, there are not days or weeks, only hours. Re: Wine License change: Open question to Jeremy White From: Jeremy White ([EMAIL PROTECTED]) Date: Fri Feb 08 2002 - 18:23:23 EST Next message: Andreas Mohr: Re: Dr. Seuss, licensing, and WINE Previous message: Andreas Mohr: Re: Dr. Seuss, licensing, and WINE In reply to: Roland: Wine License change: Open question to Jeremy White Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Roland, I've just hit a very busy patch in my personal life. You've asked a fair question, and I will try to address it, but please give me a day or two. Thanks, Jeremy ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.fr
