wine-devel February 2002

wine-devel@winehq.org

142 participants
296 discussions

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

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

← Newer
1
...
14
15
16
17
18
19
20
...
30
Older →

Jump to page:

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 February 2002