wine-devel

wine-devel@winehq.org

84463 discussions

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

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

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