wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

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

13 Feb '02

At 12:26 PM 2/13/2002, Paul Millar wrote: >> It's hard to conceive of a rational business model that did not recognize >> the advantage of offloading maintenance of non-strategic code to an >> open source team. > >True for non-strategic code, but what about _strategic_ code (strategic in >the sense that the business model assumes the retention of IP-rights). If >this is based on BSD-licensed code then there is no incentive to release >the code back to the community. Whether or not it's based on BSD-licensed code, it's a good idea for the business not to release it for everyone to use. If it's of real value, though, it will probably have a lot of originality to it. --Brett

2 1

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

13 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > > 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. > > Since this is not the first time this mistruth show up in the discussion > here, I think a clarification is warranted. it is NOT a mistruth. Maybe I should have said, "you are not really selling *gpl binaries", but the meaning is the same. By the license, the source and binaries are freely distrubutable, thus they have no monetary value. So assuming the people in a commerical transaction don't give something for nothing, the monies paid must be for cost of copying, media... > The second paragraph of section 1 of the GPL (v.2) states: > > You may charge a fee for the physical act of transferring a copy, and > you may at your option offer warranty protection in exchange for a fee. How I read that is that you can charge for the _service_ of copying, but you are NOT charging for the content. > The only limits that the GPL places on sales is that once someone has > received a copy of binaries from you, you can't sell them the SOURCE at an > additional cost that's higher than your distribution cost. Up to that > point, you can charge people whatever you want to for access to GPLed ^^^^^^^^^^ > *content*. You just don't have any power to make sure that others don't > sell that same content at a price lower than yours, or even give it away. no disagreement here. But nothing you said so far contradicts what I have said. > And although the LGPL is a different license (which is important to keep > in mind when talking about '*gpl'), the same permission is granted by the > LGPL to charge a fee (an arbitrary fee) for copies of the software. you are confusing the what was said. I did NOT say "you can't charge for GPLed stuff; they must be distributed free". What I said was "you can't charge for the *gpled binaries" because by the license, by section 1, the receiver can make as many copies as s/he wants (providing it falls within the *GPL). The by-product of all this is that the *GPL makes content "zero cost", thus you can only make money by focusing on something other than content. Another way to look at it is like getting a can of compressed air. Do you think you are buying air, or do you think you are buying the process the compressed, canned and distrubuted the air? -r

2 1

RE: Wine build system tech info
by Patrik Stridvall 13 Feb '02

13 Feb '02

> As part of a private investigation I noticed that both > WINE and LINUX kernel > build systems have a mkdep utility which generates in > clude file > dependencies. What I am looking for is to understand > the reasons behind this > decision for the two very popular projects instead the > recipe > suggested by GNU make documentation. For us because we do not wish to depend on GNU Make. For Linux kernel, no idea.

2 1

RE: DLL specific defines
by Patrik Stridvall 13 Feb '02

13 Feb '02

> > With the patch below this is added as EXTRADEFS > > flags so I can pick it up from the Makefile_in's > > and convert to .dsp compile rules. > wouldn't it be better to add them to another specific define > (like EXTRAWINDEFS or something) just to really know what > they are for ? If you wish. I don't care either way. I just want the defines somewhere so I can find them in the Makefile.in to .dsp/.dsw convertor.

1 0

Re: DLL specific defines
by Eric Pouech 13 Feb '02

13 Feb '02

> With the patch below this is added as EXTRADEFS > flags so I can pick it up from the Makefile_in's > and convert to .dsp compile rules. wouldn't it be better to add them to another specific define (like EXTRAWINDEFS or something) just to really know what they are for ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

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

13 Feb '02

At 12:09 PM 2/13/2002, Paul Millar wrote: >This is the crux of the issue. What if the business model relies upon >retaining the IP-rights associated with the in-house written code? There >the cost/benefit balance would be tipped towards non-disclosure. It's hard to conceive of a rational business model that did not recognize the advantage of offloading maintenance of non-strategic code to an open source team. --Brett Glass

2 1

Modified makedep to handle #include <>
by Patrik Stridvall 13 Feb '02

13 Feb '02

I have been working some more on a Makefile.in to .dsp/.dsw converter for working in Microsoft Developer studio and it is comming along fine. Anyway one of the the problems compiling with MSVC using the Microsoft headers is that all Wine only includes in wine/include can't use for example: #include "windef.h" it must use #include <windef.h> otherwise Wine's windef.h in the same directory is used. The problem as you pointed out is that makedep.c can't handle this. Here is a patch so it can. BTW. If you apply this patch or a similar should all .h and .c files be converted or should I just do the absolute minimum ie the Wine specific include (.h files) under wine/include. Files like heap.h for example. * tools/makedep.c: Modified makedep to handle #include <> for the Windows includes correctly. ---8<--- Index: wine/tools/makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.7 diff -u -u -r1.7 makedep.c --- wine/tools/makedep.c 2000/12/13 21:27:26 1.7 +++ wine/tools/makedep.c 2002/02/13 16:40:21 @@ -4,6 +4,8 @@ * Copyright 1996 Alexandre Julliard */ +#include <sys/types.h> +#include <sys/stat.h> #include <ctype.h> #include <stdio.h> #include <stdlib.h> @@ -185,6 +187,31 @@ return file; } +/******************************************************************* + * find_include_file + */ +static int find_include_file(char *name) +{ + INCL_PATH *path; + int found = 0; + + for (path = firstPath; path; path = path->next) + { + struct stat buf; + char *filename = xmalloc(strlen(path->name) + strlen(name) + 2); + strcpy( filename, path->name ); + strcat( filename, "/" ); + strcat( filename, name ); + if (!stat( filename, &buf )) + { + found = 1; + } + free( filename ); + if(found) break; + } + return found; +} + /******************************************************************* * open_include_file @@ -260,6 +287,7 @@ while (fgets( buffer, sizeof(buffer)-1, file )) { + char qoute; char *p = buffer; line++; while (*p && isspace(*p)) p++; @@ -268,9 +296,11 @@ if (strncmp( p, "include", 7 )) continue; p += 7; while (*p && isspace(*p)) p++; - if (*p++ != '\"') continue; + if (*p != '\"' && *p != '<' ) continue; + qoute = *p++; + if(qoute == '<') qoute = '>'; include = p; - while (*p && (*p != '\"')) p++; + while (*p && (*p != qoute)) p++; if (!*p) { fprintf( stderr, "%s:%d: Malformed #include directive\n", @@ -278,7 +308,9 @@ exit(1); } *p = 0; - add_include( pFile, include, line ); + if (qoute == '\"' || find_include_file(include)) { + add_include( pFile, include, line ); + } } fclose(file); }

1 0

wineconf 2002 user submitted agenda topics
by Michael Robertson 13 Feb '02

13 Feb '02

Here's a list of some of the suggestions people have sent in for wineconf 2002. http://www.lindows.com/wineconf It demonstrates where people's interest is and not a confirmation of the agenda or that the proposed speaker has even confirmed. Some have not responded to my email (like Dr. Ulrich Weigand). As you can see, there's no shortage of interesting topics. Please keep sending me your input and I'll incorporate. I haven't made it through everyone's suggestions yet. Company Presentations: ---------------------- Transgaming, Success To Date [Transgaming/State] ReactOS - Where it's at, where it's going [ReactOS/Filby] Corel, A Look Back [Xandros/Tranter] Crossover Strategy [Codeweavers/JW] Macadamian - Making It As A Software House [Macadamian/???] Business -------- WINE's "Most Wanted": Features To Make WINE Great [???] Developer Funding, Who Pays The Rent [???] Future of WINE licensing [CW/White] Technical --------- Development Model [CW/AJ] NORM - The secret weapon [Codeweavers/???] Making Fonts Not Look Like Crap [CW/Timoshkov/Davies] Multimedia And WINE [eric.pouech(a)wanadoo.fr] Regression Testing [???] How To Improve The Debugger [Meissner/marcus(a)jet.franken.de] Maximizing performance of WINE [???] Package streamlining of WINE [???] WinNT APIs (Odin, ReactOS, winNT wine, WINE) [???] DirectX [Transgaming/Kaaven] WINE as a porting tool [Macadamian/Jacques] Native user.dll [Dr. Ulrich Weigand] API Standardization [???] Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

6 5

Licensing response and an idea
by Gavriel State 13 Feb '02

13 Feb '02

Hi everyone, As I mentioned, I have been considering the license issue for the last several days. It is a matter very near to my heart, as I believe that it affects not only TransGaming, but really the entire software industry. This posting is somewhat lengthy, but please bear with me. Open Source software has made enormous strides in the last several years, and incredible amounts of great code have been produced. At the same time, it has been unable to compete effectively with proprietary software vendors like Microsoft, except in those areas where sufficient well financed companies have been able to direct full-time developer resources to the problem. With the wellspring of dot com VC funding going dry, the question arises: where will the money come from to pay full-time Open Source developers? Just imagine where Wine would be without the code contributed by the half-dozen or so companies that have been involved. Imagine where Linux would be without the efforts of the companies paying for dozens of full-time Kernel hackers. And imagine where we could be if just one or two percent of Microsoft's annual $25 Billion in revenue were being directed at Open Source projects. The business models capable of supporting traditional Open Source projects are really rather limited: consulting services, technical support, and selling ancilary products with the software. None of these come close to delivering the levels of revenue that traditional mass-market shrinkwrap software can. So far, it is unclear whether they can support much profit at all for their proponents: RedHat, VA, and others bear witness to that. TransGaming, for one, is working with some new ideas on how to do things differently, and profitably. There are a number of interesting possible approaches out there, and it is important to the entire world that we find models that work. Otherwise we are going to be stuck with the kind of information police states envisioned by the RIAAs, MPAAs, and Microsoft's of this world. Now we are all here because we think that there are better ways to do software than the wholly proprietary approach. We want to be able to look at the code, tear it apart, fix the bugs, and make it cooler. And we want others to have the freedom to do the same. Ultimately, the questions that need answering are these: o What freedoms are important to the community? o Can those freedoms be achieved without sacrificing other goals? o What is the best mechanism for ensuring those freedoms, and ensuring the continued development of the code? The Wine X11-style license essentially allows the code to be used anywhere, in any way. Users don't need to pay, Developers can take bits and pieces as they deem appropriate, and corporations can sell the product in whatever way they feel like. But it also has no legal mechanism to try to coerce further development of the project. Current proponents of an LGPL license switch believe that a legal mechanism is important to protect the project. Frankly, I am at a loss to understand the reasoning behind such a switch. I don't see any way in which any company could maintain their own fully proprietary fork of Wine without doing periodic merges into the public project. It's hard enough for TransGaming to do it despite the fact that we deal mostly in very specific areas. And even if someone was able to do so, how does it affect the Wine project any more than the existence of Windows or MainWin does? At most, it would affect the userbase, but in the current model that doesn't matter, since that userbase doesn't contribute significantly to the project. Only the developers contribute, and it is not at all clear to me that they would stop. Marcus Meissner has already shown that the existance of our AFPLed DCOM code didn't stop him from going ahead and doing it himself. On the contrary - it helped him, since he got hints from our design. It's a shame that he had to, since we've been working hard to find a way to contribute that code back, and now we may have no way to recoup our investment. We still have a 2nd pass, more complete DCOM implementation under development, so it is possible that we be able to get a sponsor for that. But regardless, it clearly shows that having code outside the WineHQ tree is no impediment to the community reimplementing it if necessary. The LGPL would severely limit a number of possible commercial applications of Wine, such as: o Companies or groups that might want to take a small bit of Wine code here and there without taking the whole thing. IE: Corel's Mac porting work, or projects like MicroWindows or Odin (similar projects like Xine and ReactOS use parts of Wine this way, though they're GPLed, and thus would not be affected). o Porting Wine to platforms with NDAed APIs. Or commercially oriented ports to other platforms which might not be viable under the LGPL. o The work that TransGaming has done to support copy protection. Releasing that code all at once - as would be required under the LGPL - might violate the DCMA, since it reveals something of how the copy protection systems work. o New business models like TransGaming's, with conditional-future- release of code. While I am open to considering license changes that have the potential to benefit the project, I am very very concerned about the LGPL. Going that route is a one-way street with no turning back. I've been thinking about these problems for a long time. As much as for any other reason, I started TransGaming with the desire to try to find good long-term solutions to the problem of how to fund Open Source development through the people who are actually using the code. I have the germ of an idea that might be useful to address some of the concerns that the LGPL-license-change camp has had, while at the same time leaving the doors open for a much wider variety of different commercial activities. I have been trying to flesh it out while at the same time working to some very tight deadlines, and I have not had time to really think through some of the the possibilities that it entails. I am posting it to the list now anyway so that it's out there for people to think about. Here's the quick and dirty version: o A new non-profit company is created: WineCorp o Developers contribute their work to WineCorp - possibly assigning copyright, or at least giving WineCorp the rights to do with the code whatever it pleases. o WineCorp distributes the code under an AFPL-like license - no commercial redistribution allowed. o WineCorp has a set of standing licenses allowing for commercial redistribution. A company can redistribute commercially if it does one of the following things: - Releases source modifications to WineCorp immediately. - Releases source modifications within a preset timeframe (maybe one year). - Releases source modifications with some appropriate prearranged condition (ie: the TransGaming subscriber limit). - Pays WineCorp a pre-set royalty, which WineCorp can then use to sponsor other Wine development o For cases that don't fall into the above conditions, the WineCorp board of directors can vote to allow some other licensing arrangements. This helps prevent the kind of one-way ticket we have with the LGPL. o WineCorp could also serve as a way for the userbase to direct funding and attention to different parts of Wine. To my mind, this is one of the biggest problem Open Source projects have. The end users get everything, but many don't contribute: no code, no money, no bug reports, nothing. The more they can be encouraged to contribute, the better off everyone is. WineCorp could solicit donations from users who can't contribute otherwise and possibly institute a subscription/voting system similar to TransGaming's. One hard question the above idea creates is how does money gets split fairly amongst different developers working on particular parts of the code? I am sure that there are other problems as well. That said, I think that the importance of new models like this go far beyond the Wine project. Ideally, I hope that methods like these can be profitable enough to make proprietary software companies begin to consider opening up their code in a similar fashion. Just imagine the day that Microsoft makes their first contribution to Wine, openly and without coersion by the government, because they recognize that doing so is in their own best interests. Food for though, anyway. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

3 3

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

13 Feb '02

Gavriel State <gav(a)transgaming.com> wrote: > > You did not mention whether you want to have this > > license only or to have Wine licensed also with some > > open-source license? > > > > I think in this case even GPL can be a choice for the > > second license. > > Under the WineCorp approach, the AFPL + an allowance > for commercial redistribution if Wine code is returned is > essentially equivalent to the LGPL. It's more flexible though, > since it allows for the possibility of other unforseen ways in > which commercial redistribution without immediate release > of source would be possible. > > It would also be possible for the WineCorp to allow certain > portions or all of the code to be dual-licensed under the LGPL > and mixed with other GPL or LGPLed projects. I think that you'll find considerable resistance from the *GPL people, but you do bring up a good point. If there is going to be a license change, it would probably be wise to require that the copyright of future submissions go to a single (or small #) of people. That way, you can revert the licensing terms if you change your mind. -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