wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

Re: WineCorp (was Re: Wine license change)
by Roger Fujii 14 Feb '02

14 Feb '02

David Elliott <dfe(a)tgwbd.org> 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

2 3

Re: shellexecute patch
by Andreas Mohr 14 Feb '02

14 Feb '02

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 Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 2

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

14 Feb '02

Ian Schmidt <ischmidt(a)cfl.rr.com> wrote: > On Wednesday 13 February 2002 01:28 pm, Brett Glass wrote: > > > business. So, if the company was profitable at all, it was just squeaking > > through. (And $20M in annual revenues after ten years of existence is no > > one's idea of "good money" for a company that size.) > Sure, but they did stay in business for 10 years and were in no reported > danger of going out of it. Not bad by any metric for a license you can't > make money off of ;-) but I wouldn't use the word 'thrive' to describe a company that is barely profitable (which is what the original poster used). It's not my opinion (and probably not even Brent's) that it is *impossible* to eek out a living. I think the point is that it is DIFFICULT to do so. I don't mind hearing GPL advocates say that it is more socially desirable, equitable... (not that I necessarily agree with it, but it is a valid point of view). But I don't see any evidence that it is helpful to commerical entities (which is some of the reasoning behind a license switch). > Anyway to steer back toward my point, can you name any pure-BSD/X11 players > that are profitable? well, depends on what you mean by "pure". X.org presumably is. Usually, the business model for this is a common group that publishes a reference port for other vendors, which can build propriatary value adds on top of the reference port. Ximian's 'mono' model is based on this logic (I think). A better way of looking at it is companies that have 'free' licenses that are NOT *GPL. sendmail.org has a modified license and they seem to be doing ok. Apache would a another one. > See, I think there's a more basic problem, which is that no known business > model works really well for source-available software when the software is > targeted at technically savvy users. Things like the Aladdin license are a > nice compromise, but ultimately won't lead to Microsoft levels of > profitability. No one here is advocating for M$ levels of profitability (at least, not for wine :) ), but the point is correct. The problem is the *GPL highly limits what models can be tried. > The solution as I see it is for GPL/BSD/whatever programmers to actually > cough up something non-technical users not only would use, but would > *prefer*. *Then* support and selling binaries becomes a worthwhile > proposition. you cannot sell *gpl binaries. You can sell the media, but not the content. Think sun has a good idea with dual licensing and having assignment of the copyright. This allows them to change the license so that they can make a productized version. > Codeweavers is leaning in this direction with CrossOver - even > though you could probably duplicate their work eventually with the current > Wine CVS, the installer and overall ease of use make it well worth paying for > if you value your time at all (I bought it and I love it, if you can't tell). Isn't the whole reason this discussion was opened up again was because they want to release LGPLed code (the inference was that they thought that their code released under X11/BSD would harm them materially). The obvious extrapolation is that a more complete wine under X11/BSD is not in codeweaver's interest, regardless of where the code came from. > To put this back on topic, I don't see any immediate benefits from a LGPL > license. If we knew what the threat to Wine Jeremy hinted at was, it might > make for a more informed discussion. I also liked Gav's idea about WineCorp > a lot as a compromise, and I'd love to see more dicussion of that and less > licensing flaming. MORE?! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!! :) -r

5 6

[patch] - add several structs to ntddk.h
by Ron Gage 14 Feb '02

14 Feb '02

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/

1 0

Request for wine-license list
by Uwe Bonnes 14 Feb '02

14 Feb '02

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 bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

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

14 Feb '02

Tony Bryant <brd(a)paradise.net.nz> 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

1 0

Re: Wine license change
by Claus Fischer 14 Feb '02

14 Feb '02

Issue 1: On corporations' dealing with GPL Basically all big companies in the software industry know about the GPL. It's a known quantity. Even if it may not have been publicly enforced, companies have spent lawyers' time finding out the core implications. They know its `spirit', and they mostly equate it with its spirit, i.e. they deal with GPL code according to its spirit. This is true whether they are pro or contra GPL in a particular situation; hardly have big companies ever tried to sneak around it. (Or was there some good enforcement?) GPL'ing code may not fit everybody's needs but it can make a lot of sense for corporations whose core business is not Wine. Imagine some big hardware vendor (Intel), software vendor (IBM), bank, fortune 500 company, considering the use of Wine for some internal or external product. They don't want to get into the Wine business at all. It's much easier for them to hire external consultants, Codeweavers, whoever, to implement some stuff for them and give back to the public if they don't run the risk of a) the competition taking the code b) the competition improving it c) the competition getting better products d) the competition not giving anything back Even if the causal connection between the little money you spent and the success of your competition is very weak, you don't want to read that kind of implication in a newspaper. Rather spend 10 times the money and do it closed-up in-house. Whereas using the GPL, by this time a very well known quantity in most of the above mentioned companies, you can rule out this kind of embarrassment and explain fair and square to your shareholders that a Windows compatibility layer is not a means of competition to you, and that you are just playing by the general rules of the community, and those ensure that your competition will not take advantage of you. For an enabling technology like Wine that will perhaps never become the one big bread and butter product of a fortune 500 company (sorry Lindows guys), this carries a lot of potential for consultants, both individual and incorporated, whose goal is to offer a Windows compatibility layer and to improve Wine. (1) `We need something like Wine' (2) `We need some enhancements' (3) `We have to give back the source code anyway' (4) `So we can as well outsource that and consult with experts' In contrast an X11 style license would modify this: (1) `We need something like Wine' (2) `We need some enhancements' (3) `We do not want our competition to know' (4a) `Let's do it in-house', or (4b) `Let's make a contract with our external consultants that disallows them to reuse the code' Issue 2: On developers discussing licenses You shouldn't. You can't convince others, and you shouldn't try to. You have the power. Just pick one that fits your goals for yourself and for the project, and move on. Claus -- Claus Fischer <claus.fischer(a)clausfischer.com> http://www.clausfischer.com/

2 1

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

14 Feb '02

> To give a concrete technical example (but not an > authoritative legal one, > as IANAL), it is my understanding of the LGPL that if someone > has released > a library under the LGPL, a third party cannot distribute a modified > version of this library that has been linked against a proprietary > library[1]. I think because of the reduced scope of the LGPL, there's > also less room for ambiguity on questions of aggregation vs. derived > works. [snip] > [1] The reason for this lies in section 2d of the LGPL: > > d) If a facility in the modified Library refers to a function or a > table of data to be supplied by an application program that uses > the facility, other than as an argument passed when the facility > is invoked, then you must make a good faith effort to ensure that, > in the event an application does not supply such function or > table, the facility still operates, and performs whatever part of > its purpose remains meaningful. > > A library that is linked against a proprietary library cannot be used > without the proprietary library; it will fail to load at > runtime with a > complaint of "No such file or directory". If that was the only problem: BOOL (*PROPRIETARY_Foo)(void) = NULL; void call_this_init_on_dll_load(void) { HANDLE h = LoadLibrary("PROPRIETARY.DLL"); PROPRIETARY_Foo = (void *) GetProcAddress(h, "Foo"); } BOOL WINAPI Foo(void) { if(PROPRIETARY_Foo) { return PROPRIETARY_Foo(); } else { /* The old implementation goes here */ } } So no runtime failure any more. At least not anymore than happend before. > If "application > program" as > used above is understood to include other libraries (the > distinction is > artificial, and the LGPL 2.1 does not define "application program" to > exclude this interpretation), then trying to hide proprietary > functions in > a separate library that an LGPLed library is made to depend on is not > permitted under the LGPL. Well, the the requirement if the function didn't exist was "the facility still operates, and performs whatever part of its purpose remains meaningful." Observe the words "remains meaningful". It doesn't have to do the same thing as Alexandre claimed in the last discussion. Yes, I can see why he thought that since the example below paragraf d (not included in your cut) was missleading. It should just do something that in the context of the missing function remains meaningful. It could mean using the old Wine implementation but I guess it could also mean that just doing: SetLastError(ERROR_NOT_IMPLEMENTED); return FALSE; since doing that is ALWAYS meaningful for a Windows API. Sure the application might not check but then this is the responsebillity of application not our problem. Beside since the Wine likely didn't have a non-stub implementation anyway, it was probably was what it already did, so the application crashed anyway without the patch and the proprietary library.

3 2

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

14 Feb '02

At 05:44 PM 2/9/2002, J.Brown (Ender/Amigo) wrote: >Sorry, let me clarify that point... the major work that was lost was done >by a COMMUNITY project, not one of ID's in-house ones. His point is that >as the xGPL forces the release of source code with any binaries, so any >valuable work like this won't be lost to the community. In that case, it seems to me that his remarks are a complete non sequitur. The source code of "community" projects that license their work under the MIT X or BSD license is every bit as publicly available as that of projects that use the GPL. In fact, the GPL would actually reduce the likelihood of recovering the code from someone's box, because commercial programmers such as myself won't look at it or download it. --Brett

7 12

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

13 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > When you buy a book, are you paying for the physical paper, or are you > paying for the information contained within its pages? If you are talking about publications by the US government, or books that are in the public domain or have an expired copyright, then I am just paying for the paper. For something with an active copyright, you are also paying for copyright access for the publisher. > How is this anything more than a semantic difference? we are talking about licenses, aren't we? > Just because I can build a greenhouse, plant the seeds and grow my own > 'copies' of the fruit doesn't mean I'm not paying for fruit. bad example, because fruit still has value. And if you want really scary permutations of this, start looking at genetically modified corn and what companies like monsanto are doing.... > > How I read that is that you can charge for the _service_ of copying, but you > > are NOT charging for the content. > Semantics. we are talking about licenses and the law. How can you ignore semantics in this context? > Whatever the license governing the software in question, I'm > buying the same thing when I buy a CD -- and usually less when it's a > proprietary license. If one of these vendors is "selling binaries", then > so is the other. just because you aren't willing to see the distinction, doesn't mean that there isn't one. Why do you think the phrase "Right To Use" exists (you didn't buy the binaries in that case either)? > Or, if the only thing I'm buying from RedHat is the service of copying, > then the only thing I'm buying from Microsoft is insurance against legal > harrassment -- since Windows binaries are just as easy to come by, and > just as easy to copy, as Linux binaries are... what does availability have to do with anything? What am I missing? -r

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel