I would like to close this discussion now and proceed with the license change. Here's a summary of the various points that have been discussed and the conclusions I draw from them.

License choice

The possible copyleft licenses that have been discussed are:

• LGPL
• MPL (Mozilla license)
• MPL/LGPL/GPL multi-license
• LGPL with modifications to section 2d
• xGPL with time delay on code release

As already mentioned, the LGPL is the favorite of the majority of people who voted in favor of copyleft. I have not seen arguments compelling enough to make one of the alternatives a clearly better choice, especially since they all have some other drawbacks that have been discussed. So the logical choice is to go with the LGPL.

LGPL ambiguities

Some people have remarked that in some cases it's not exactly clear what the LGPL allows or doesn't allow. I think this is inevitable given the nature of what the license tries to achieve, and any other license with the same goals would have the same problems. I'm confident that this is not going to be a real problem in practice; border cases can be resolved simply by discussion among the contributors (on this mailing list for instance). The existence of binary drivers for the Linux kernel plainly demonstrates that these things can be worked out.

Header files

Some people have suggested using a different license for header files. I don't think this is really necessary, given that the LGPL doesn't impose extra restrictions on headers compared to the current license (LGPL headers don't influence the license of the code compiled with them, and you cannot really distribute headers without source anyway). And having everything under the same license makes things a lot simpler.

WineCorp

The suggestion of assigning copyrights to an organization to allow relicensing under different terms seems to be generally disliked. It may still be useful to have a non-profit org to manage other aspects of the project, but since setting this up is a non-trivial amount of work I'm not going to pursue it at this point.

I'll shortly be making a general announcement of the change, and I'll then begin switching the CVS tree license to LGPL. If some people feel the need to maintain an X11-licensed fork (though I hope this won't prove necessary), they should use the 20020228 release as the starting point for that tree.

• add COPYING.LIB file containing LGPL version 2.1
• change LICENSE file to refer to COPYING.LIB
• add notice/exception in spec compiler output
• (probably) add notice in all source files following FSF guidelines
• make new release announcing the change
• start accepting LGPL patches

I noted today with disappointment (but not surprise) the switchover in WineHQ CVS to LGPL. While this is going to have significant repercussions on the way that TransGaming works on Wine, I will leave our views on that subject to some other time.

I do have two specific legal issues to raise - I would have raised them earlier this week, but I have not had the time to respond until today.

1) Switching to the LGPL in the manner done today violates the previous Wine license, which states:

... The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The new LICENSE file includes the 'above copyright notice', but not 'this permission notice'. The LGPL can certainly be applied to newly written code, but I believe that it is improper to apply it to all of the existing code in the tree.

The AFPLed TransGaming WineX tree deals with this issue by:

• Renaming the original LICENSE file to LICENSE.WineHQ
• Replacing the LICENSE file with the AFPL
• Identifying all modified files with TransGaming's copyright notice
• Prefacing the new LICENSE file with the following:

  Source code and other software components explicitly identified as Copyright TransGaming Technologies Inc. is covered by the license below. Other source code and software components are covered by the Wine license, found in the LICENSE.winehq file.

Something similar should suffice for the WineHQ LGPL switch. Explicitly identifying files that now include LGPLed components is probably a good thing regardless.

2) Header files. Under the same logic that allows the Wine project to build header files compatible with Microsoft's own, the appropriateness of applying the LGPL to the header files is suspect. From a post of mine to wine-devel about a year ago:

Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. ( http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html ) The court in that case said:

Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.

The LGPL acknowledges this legal issue in section (5):

When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.

Rather than be subject to this ambiguity, it may be simpler for the headers to fall under the previous license, since the previous license still needs to be there regardless.

To grant a right to 'sublicense' means that a licensee is allowed to license a copyright work to someone else - the terms under which a licensee can sublicense are still covered by the original license, which required that permission notice to be included with the code.

http://www.lawyers.com/lawyers-com/executable/glossary/defpage.asp?SEQNO=8275

Perhaps Eben Moglen can be helpful here. It's a shame that he has not had any input into this process to this point; there are a number of issues that have been brought up that it would probably be worth discussing with him.

Since it's official that Wine has gone LGPL, it's also official that there will be an X11-licensed fork. So far, 4 independent movers have stepped forward, all volunteering to look after this fork; Kenneth Davis, Gerard Patel, Eric Pouech, and me. Several others have stated their support for it, and will contribute either directly or indirectly (by licensing their Wine contributions under the X11 license). While we would like to move forward with this, and request that as many Wine contributors as possible give us permission to apply their contributions to the X11 fork, we must first decide on a few things.

• What do we call the fork.
  Kenneth suggested "winem", and already created a sourceforge project with this name. Afterwards, Gerard suggested "Theleme" to him (from "Abbey of Theleme"). Then later, Eric mailed me and suggested OpenWine. Others?
  
  
• Where do we host it.
  SourceForge is an option, but in the long term it would be preferable with a somewhat more independent place to host it.
  
  
• Who is in charge.
  While a development model where more than one person can do stuff like committing patches etc may be a good idea, we still ought to choose someone that's ultimately responsible...
  
  Or, would we maybe rather prefer to have a WineCorp in charge?
  
  
• Who's in?
  If you want to join the X11 fork, or just support our efforts by continuing to license your patches under the X11 license, let us know.

Anything else?

NOTICE!! NOTICE!! NOTICE!!

www.winehq.com will be moving to a new home in Minnesota. We are trying to make this move as seamless as possible, but we can't guarantee that there will not be any downtime. I will post another message to the mailing lists when I have a more definite time of shutdown of the old server.

www.winehq.org WILL be on-line for Web, FTP and CVS access. The area that could have the longest downtime is the mailing lists.

Once the transfer is complete, winehq.com, winehq.org, and wineproject.org will be one and the same site.

If you run a mirror of winehq.com please contact me to make arrangements for access.

Further questions can be directed my was as well.

The WineHQ.com move is complete, but not without some issues.

The 1st issue is that our mailing lists (mailman) sent out a huge amount of email because the newsgroup gateway changed. It basically thought all the messages on comp.emulators.ms-windows.wine were new. Apologies go out to the users whose email inboxes we filled up.

So in the meantime, the newsgroup gateway, and the NNTP server on winehq.com are offline until further notice.

If you notice any other issues that I am not aware of, please let me know. There is a lot of things to a site that has been running as long as Winehq.com has.

I moved it to a new list called FIXMEs. It is intended as an intermediate list for fully diagnosed bugs. That's the third list but don't worry, I intend to stop there.

• Tasklets http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=406
• FIXMEs http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=455
• Tasklist http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=395

Now, I really must get going on that contrib page.

There are 2 areas that we'll be focusing on:

Business issues - This will be a combination of presentation from companies talking about their business experience with WINE as well as talks on the non-technical issues facing WINE.

Wine Technology - There will be some advanced topics as well as some more general overviews. Since (http://www.lpbn.org) will be on hand to shoot video of all the session, our goal is to have a video series that those newer to wine can view at anytime via the net to get up to speed. Alexandre's keynote will set the tone and provide a roadmap for many of the discussions. Alexandre's keynote will kickoff the conference.

NOTE: Presentations listed below with a * designate a Friday presentation. If there's no asteric, then the presentation will be on Saturday. For maximum diversity, we will be alternating between technology presentations and business. There will be two technology presentations and then one on a business topic. Repeat.

Wine Technology

WINE Past, Present and Future [Julliard]*
Supporting Drag and Drop between Wine and non-Wine windows [Weigland]*
How To Make Fonts Look Great In Wine [Davies]*
Package streamlining of WINE [Meissner]*
DirectX [Kaaven]*
IActiveScript, or how jscript.dll was reimplemented using the Mozilla JScript engine, lots of glue, and a little bit of luck". [Hatheway]*
Beyond Trial And Error, Alternative Ways To Insure Quality Code [Stridvall]
A Howto For Regression Testing [Gouget]
Winedoc and Automated Verification [Paun]
Wine/Windows bootup handling and documentation/end user representation [Mohr]
Package streamlining of WINE [Meissner]
TBD [Czekalla]

Business Talks

Macadamian - Making It As A Software House [Boulanger]*
An Unique Commercial Application for WINE [Cadlink Technology/Hawkes]*
Gaming and Beyond [Transgaming/State]*
ReactOS - Where it's at, where it's going [ReactOS/Filby]
Corel, A Look Back [Xandros/Tranter]
Lindows.com And WINE [Robertson]

I've been following Wine development for the last 6 months, mostly watching for improvements for the 2 Windows applications I actually care about -- Quicken and TurboTax.

Quicken has been mostly usable for that entire time period; however it's behavior has significantly improved. Far fewer hangs, crashes and other undesirable behavior. I won't enumerate the problems y'all have fixed, but the user-visible progress has been great. There's still some rough edges, but the improvements have been huge.

TurboTax was basically unusable until recently -- but when I returned from a short vacation and updated my wine sources, all the show-stopping issues with TurboTax had been resolved. Amazing.

The one issue in both tools that I still need to check on is both consistently ran out of GDI space, which I've hacked around with some tweaks to gdiobj.c.

There was a 3rd application I've been evaluating (RentTracker) which was also unusable in mid-Feb, but which appears to work flawlessly now.

I just wanted to let you know that you've made great strides recently and your work is greatly appreciated.

Microsoft Visual Studio 6 is crashing when opening an existing projet, with current CVS version of Wine (Wine20020122 was OK).

Comparing both, I have found the change that triggers the crash. It is function StgOpenStorage in OLE32/storage32.c, line 5595 :

hr = StorageImpl_Construct(
     newStorage,
     hFile,
     pwcsName,
     NULL,
     grfMode,
     TRUE,
   - FALSE);
   + !(Fad.nFileSizeHigh || Fad.nFileSizeLow) /* FALSE */ );

As you can see in TRACE the crash occurs in StorageImpl_WriteBigBloc. I suppose Wine is trying to write to a readonly opened file ? (because file is opened with GENERIC_READ)

I hope this will help finding a fix.

I created the problematic change in question.

Without the change, when StgOpenStorage is called with an existing zero length file as the filename, it fails because it suceeded in opening the file but expects it to have valid content...

Unfortunately, the change was merged incorrectly from the big CW patch. (the Fad structure is not initiaized)

Could you try this patch instead please?

What's the current state of OOP COM objects in Wine? I've noticed a lot of related changes, but have yet to find an InstallShield 6 installer that works. (I did copy the stdole*.tlb files to the windows & system directory)

Before I start debugging this, I'd like to know if it is supposed to work at all.