Installshield 6 (inter-proc) patches

[Gavriels State]

Hi Everyone,

Discussion on this topic seems to have somewhat bypassed what I believe 
are some key points:

1) Wine *needs* corporate developers.  

  Without the funding, code, and profile that the various corporate 
  developers have brought to the table, the project could not be where 
  it is today.  Without continued support from companies able to afford 
  to fund development, the future prospects of being able to keep up with
  Microsoft's API changes is very bleak indeed.

2) The current Wine license played a very significant role in the 
involvement of some of the past and current corporate players.

  I can state categorically that if the Wine license had been GPL or LGPL,
  Corel would not have invested the millions of dollars it did into Wine
  development - I was the one who made that decision.  There were three 
  choices: Wine; Go it alone, based on the work we had done on the Mac; 
  and Willows TWIN, which was LGPLed.

  At the time, TWIN was much better suited for source-level porting.  The 
  reason we went with Wine was almost entirely because of the license.  We
  knew that we would be able to take code we had developed for Wine and 
  use it in our Mac work and elsewhere.

  If the Wine license had been LGPL, TransGaming would most likely not
  have been started.  The LGPL would not have given us the flexibility 
  to explore the subscription/voting business model that we're using.  
 
3) Our work has not affected other DirectX work in Wine.

  Except for Direct3D, all our DirectX work goes back to Wine.  We have
  already contributed our major DirectDraw restructuring work, and many
  other pieces.  There is ongoing work by non-TransGaming developers 
  on non-3D DirectX related areas in Wine, including both the x11drv and 
  dib code.  

  The only thing that we are keeping back here is the D3D code.  The 
  only other developer who has ever worked on D3D in Wine is Lionel
  Ulmer, and the last time he did significant work on D3D was in early
  1999 - on much earlier DirectX APIs.  Experience with 3D development 
  is rare.  There are very few developers who have the required 
  skill-set, and fewer still willing to volunteer their time on Open 
  Source projects.  If there is anyone out there who has the experience 
  necessary to do D3D work, please let me know: I want to hire you.

  We do have a bit of merge work pending for non-3D components, which 
  we hope to get to soon.  The delays there have nothing to do with
  licensing issues though - they're more about development process and
  CVS policy.
  
4) We would not have been able to afford to do the DCOM work under the LGPL.

  The DCOM problems with InstallShield had been kicked around for 
  a very long time before we finally stepped up to the plate to do 
  something about it.  We poked around a bit to try to see if there
  was anyone willing to do the work on the Wine side of things, 
  sponsored by us, but didn't have much luck.  
  
  In the end, we decided to go ahead with it in the hope that 
  along the way we could find someone to sponsor *us*.  If we 
  had known how much work was going to be required, I'm not sure 
  that we would have done it at all.  
  
  It took months of effort for us to get DCOM working with InstallShield, 
  and cost us tens of thousands of dollars.  We're a very small company, 
  and much of that money came directly out of my personal pocket.  I 
  haven't had an income for over 18 months, and I have an 8 month old 
  daughter to support.     
  
  The several months worth of effort we put into DCOM also had a huge
  opportunity cost: that was all time that we could have spent on 
  improving Direct3D instead, which is, in the long run, where our
  primary business is.
  
  If I had thought that there would be no possibility of finding a sponsor
  for the work because we would have been forced by the LGPL to 
  make the code available immediately, we would very simply have
  ignored the issue entirely and just continued to wait for someone
  else to do it while we worked on DirectX.  Given the complexity 
  of the DCOM/InstallShield issues and the amount of effort required, 
  I believe that we would have had to wait a very long time.
  
  The fact is, I would *love* to release the code now.  I don't want
  us to shoulder the burden of maintaining it - that's not where we
  should be spending our efforts.  
  
  But there are companies out there who will benefit significantly 
  from commercial use of this code, and who can afford to sponsor a 
  portion of the development cost.  Until such a sponsorship happens, 
  we cannot apply the WineHQ license to that code.  
  
  Note though that we *have* contributed substantially to all kinds of
  related code, including typelibs, rpc, safearrays, etc.  I feel that
  the work we have contributed so far is fair reciprocation for the 
  work that other commercial Wine developers have brought to the table.
  
5) Using the LGPL may limit the abilities of those who need to work on 
code that cannot legally have source revealed.

  One of the other non-DirectX things that we have spent significant
  amount of effort on is copy protection.  We have extended Wine to
  support both SafeDisc and SecuRom protected programs.  For the moment,
  our work on this code is not even in our AFPLed tree.  Until we have
  a chance to make a legal determination on whether or not releasing
  the source code would violate the US DCMA, we have little choice
  but to keep it secret.
  
  If Wine was LGPLed, we might not have the option to distribute this
  code at all, which would thus severly limit the utility of our 
  entire endeavour.  It's not hard to imagine other commercial efforts
  where similar issues might occur.

6) Additional limited AFPL-style licensing of portions of Wine could 
be a *good* thing for the project, not a bad thing.

  The more developers there are getting paid to develop Wine code, the
  better.  Volunteer developers alone will not be sufficient to move
  the project along quickly enough.
  
  An AFPL style license that restricts only commercial redistribution of
  code, but permits all other use and redistribution is an excellent way
  of making the code available to Wine users while still allowing 
  developers to be paid for their efforts by forcing entities that want
  to make commercial use of the code to contribute something in return.  
  Ideally, things would be structured such that code would be sponsored 
  by a commercial entity to be relicensed under the Wine license.
  
  I would *love* to see more of the volunteer developers working full-time
  on Wine, supported through such a sponsorship system.
  
  Really, that is the ultimate goal of our subscription system.  With
  a sufficient number of users contributing to our system, we want to 
  begin spreading some of the funding around to developers willing to
  work on the features our users have voted for.  In fact, we're basically
  ready to do this right now.  Anyone who wants to look at this list:
  
    http://www.transgaming.com/pollslist.php?old=1
  
  and who chooses to work on one of the poll items is welcome to send 
  me a proposal for sponsoring their work.  They can make their code
  available under the AFPL while we determine if it fits the need, and
  if we like it and agree to the price, we will be happy to pay to 
  make it available under the Wine license.

  I firmly believe that this kind of arrangement is going to play a key
  role in financing the development of all kinds of Open Source projects
  in the future.  I could be mistaken, but at the least, I think that it 
  is important to run the experiment and see.  
  
 -Gav 
 
-- 
Gavriel State, CEO
TransGaming Technologies Inc.
http://www.transgaming.com
gav at transgaming.com