February 2002 - Wine-devel - list.winehq.org

RE: Dr. Seuss, licensing, and WINE
by Medland, Bill 08 Feb '02

08 Feb '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dimi(a)cs.toronto.edu] > Sent: Friday, February 08, 2002 6:35 AM > To: Brett Glass > Cc: wine-devel(a)winehq.com > Subject: Re: Dr. Seuss, licensing, and WINE > > > On Thu, 7 Feb 2002, Brett Glass wrote: > > > --Brett Glass (Who hasn't happened to contribute to WINE > yet, but may do so if > > it remains open source) > > Could you have finished wiht a more dumb line? LGPL _is_ open > source my > friend, go read about it first. > > I don't know about other people, but I'm so tired of these > arguments where > LGPL is 'fascist', 'proprietary', 'not open source', etc. > Once again, we > don't discuss what is important, but we keep arguing about mostly > irrelevant things, just like last time... :( Especially as the OP seems to be in favour of contributing to an "open source" set of code that is used for the basis of a "commercial closed source" product. Bill

1 0

License change: patenting for one year?
by Roland 08 Feb '02

08 Feb '02

Hello, someone here already had the idea of making a patenting scheme. Maybe this would be a good idea. A company can take the code, improve it and doesn't have to give modifications back until one year has passed. That would give them a competitive edge. Users would pay that company to be able to use always the newest versions. After one year, the code has to be contributed and is placed under the xGPL. The disadvantage of this would be that it would slow down the WINE progress or lead to code duplication. Free developers who don't want to wait a year would start duplicating the code that the company already has but doesn't want to give back yet... Maybe it would really be a good idea to open a web-site with a forum for this discussion, or how about another mailing list? I think the problem with this discussion is that we seem to have at least 2 distinctive groups: 1. People who want to make money selling WINE or derivatives == Anti xGPL 2. People who have no financial interest(individual developers) or companies who have another business model than the above == Pro xGPL Of course there are also people from group 2 that are against the xGPL for one reason or another. Ok, how do we solve this conflict? Maybe there is no solution other than splitting up WINE? That means we would have two code bases corresponding to the two conflicting interest groups. I think that the xGPL group will win on the long run because group one would consist of many people who have only a limited interest in sharing back! That means that the codebase wouldn't evolve much over the long run, and we would have more companies like Lindows who simply build their own version of WINE and improve it, without giving back. Of course there probably will be a group of people involved like on FreeBSD but I wonder if the xGPL group wouldn't have more members.... The problem with the actual license is that it has created exactly this kind of situation: Companies don't share back at all or only if certain requirements(incoming profit) have been fulfilled. This effectively created a situation that is similar to the proposed patenting scheme. So basically I see two options A. We make that patenting scheme official, which basically would correspond to the way things are NOW. B. We split WINE in two projects. B is my current prediction of what will happen. In fact CodeWeavers has already announced that this will happen(they will base their code on xGPL no matter what), so it is very obvious. The only alternative is if someone finds an ingenious solution but I doubt it is possible since the involved interests are so antagonistic. We simply cannot sit in the same boat if one group wants to go north, the other south. Roland

2 1

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

08 Feb '02

Marcus Meissner <marcus(a)jet.franken.de> wrote: > Hi, hello.... > On Thu, Feb 07, 2002 at 05:45:36PM -0500, Roger Fujii wrote: > > If you are using marketing speak for "contribute". GPL requires 1) > > for you to show your work 2) You effectively license your software to > > the FSF. It doesn't say it has to be in any useful form to be worked > > back into the originating project (if any). > License is not equal Copyright. > You don't automatically sign away your Copyright when switching to the GPL. ??? but I didn't mention copyright. I used the word "license" for this very reason. The copyright holder can later change the licensing policies (though the FSF says this is "ethically tainted"). But there still can be a *GPLed copy after the change.... > > Freedom means allowing people to do things, even things that you don't > > agree with. BSD = Free. GPL is not. Call a spade a spade.... > > Quoting: > When we speak of free software, we are referring to freedom of use, > not price. Our General Public Licenses are designed to make sure that > you have the freedom to distribute copies of free software (and charge > for this service if you wish); that you receive source code or can get > it if you want it; that you can change the software and use pieces of > it in new free programs; and that you are informed that you can do ^^^^^^^^^^^^^^^^^^^^^^^^ > these things. I didn't mention cost for the same reason. It seems like a trivial academic exercise to show that something that has LESS restrictions is more "free" than something with more. Hence it is riduculous to say GPL is more "free" than X11/BSD (which is why I wrote that to begin with). Just because something claims it's 'free' doesn't mean it is, just as the "Democractic People's Republic or Korea" isn't democratic by most people's definition of democracy. GPLed programs are certainly infinitely more "free" than propriatary ones, but then, propriatory programs don't try to claim that they're "free" either. > The problem is not other people doing things with my stuff, the problem > is restricting ME as a developer. but that is PRECISELY the issue here, unless you consider someone not contributing is a restriction on a developer. The *GPL clearly restricts how something can be distributed: "rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program" The topic was opened again because there are concerns about how other people are using the source code. Yes, this is a problem, but the tendency is for *GPL advocates to claim that there will be no negative impact which is not the case. -r

2 1

more on wineconf 2002
by Michael Robertson 08 Feb '02

08 Feb '02

I've fielded a few questions from people who are interested in wineconf 2002. http://net2.com/lindows/hotels.htm For a list of hotels. The best on the cheap/close scale would probably probably be Homestead which are really nice suites (have a little kitchen I believe). Sorry about the short notice (by Feb 14th). That's of course not the cutoff to attend, but just the cutoff for those of you to attend that want Lindows.com to pick up the airfare. We don't intend on advertising it to the general public so we keep a high caliber of attendee. The only place the notification has gone is wine-devel list. We currently have about 15 people signed up. Alexandre told me to tell you he's coming if that will help get more people here. Please continue to send in your ideas about topics and speakers. This will help make the conference as informative and rewarding as possible. We'll also have a fun event planned for one of the evenings on Lindows.com so we'll try to make it a good social event as well as technical. -- MR Lindows.com michael(a)lindows.com 858-410-5941 Bring choice to computers: Become a Lindows.com Insider http://www.lindows.com/signup

4 3

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

08 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > Under the LGPL, everyone /will/ contribute back, because that's what the > LGPL requires. If you are using marketing speak for "contribute". GPL requires 1) for you to show your work 2) You effectively license your software to the FSF. It doesn't say it has to be in any useful form to be worked back into the originating project (if any). > Under the LGPL, it's not for them (or for you) to decide > whether they have anything to contribute back; if they make modifications, > they must be shared openly. And you're right that some people don't want > to contribute back. That's precisely WHY we would consider relicensing > under the LGPL. If everyone shared of their own free will, why would we > need a license that said they had to share? The question at hand is > whether or not we want to allow others to benefit from Wine without > sharing their changes. Here we go again.... If this is *all* it did, LGPL is far less objectionable. The problem with *GPL is that it also regulates the UNMODIFIED use of the software. > I make no bones about the fact that I'm a staunch believer in copyleft. > If Free Software has value, then there's also value in keeping it Free. Freedom means allowing people to do things, even things that you don't agree with. BSD = Free. GPL is not. Call a spade a spade.... > > As for commercial interest, I see that Apache+modssl has done quite well > > against any closed-source versions. > I would argue that this is a different ballgame. In the web serving > field, There's More Than One Way To Do It, there shouldn't be... http and ssl are 'well' defined protocols. > and trying to avoid forks leads to infrastructure issues as you need more > and more management to make decisions and guide the project. this is a project SIZE issue and has very little to do with the license. > In Wine, most of the decisions have already been made by Microsoft for us, > it's simply a question of implementation; and most of that implementation > is parallelizable to a high degree. and what gives you this impression about wine? Seems that many of the subsystems are interconnected (look at the recent thread on dll mapping). Can't imagine that DX support wouldn't impact anything else. > Having a license that allows commercial offshoots of a > webserver lets companies come up with innovative new designs that > wouldn't have been incorporated into the main tree. Having a license that > allows commercial offshoots of Wine potentially leads to a bunch of > different Windows emulators, each of which is 98% complete and none of > which works with half the software people want it to. If it works 100% with the 1-3 pieces of software a user needs it for, the user certainly wouldn't care. The question is whether the alternative would be better or not..... > I'm sure that under a BSD-style license, Wine could continue to outcompete > any commercial offshoots. The question is, which license model gives us > the best chance of competing with *Microsoft*, who already has the lead? If this is the goal (it certainly is mine), then *GPL is not a good choice, because it would interfere with deployment (*GPL wouldn't allow being bundled with the playstation2 or other HW platforms as an example). If acceptance is the goal and you care about wine in a non-linux context, stay with BSD/X11. If you don't care about expanding the pie, go *GPL.... -r

4 3

Re: wine license change - look at how ghostscript is licensed
by dschwarz＠bellatlantic.net 08 Feb '02

08 Feb '02

As a non-coder but longtime interested observer of the WINE project, here are my ideas: Consider doing what ghostscript does (http://www.ghostscript.com/) New versions are released under the AFPL license (more restrictive than GPL). Old versions are re-released under GPL when they are about 1 year out of date. This may be applicable to Wine. Like Wine, ghostscript tracks an evolving API. Older versions are useful but may not have all the latest bells and whistles. Those that need to be on the cutting edge have to use the more restrictive license. How this could be applied to Wine: Going forward, all builds are released under LGPL. They are then re-released one year later under an X11 style license. Regards, Daniel Schwarz http://www.winecentric.com/ coming soon... the wine wiki! test it at http://www.winecentric.com/test

2 1

Re: Wine license change
by Andreas Mohr 07 Feb '02

07 Feb '02

Seems Slashdot is fast today ;-) They already have a thread about the proposed license change running. One guy made an interesting suggestion: a "dual license" scheme (like MySQL uses) where you switch to (L)GPL, but certain companies are allowed to take code without contributing everything and their arms and legs back... -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

10 14

Re: Wine license change: it's about time!
by Roger Fujii 07 Feb '02

07 Feb '02

Gavriel State <gav(a)transgaming.com> wrote: > Quite the opposite: It is not 'competitive advantage' that concerns us, > or others using our code without contributing their own code. It is > simply that we could not and cannot afford to do our development without > monetary compensation. If the OLE DLLs had been LGPLed, we could not > have been able to afford to do any DCOM work, since we would have had > no prospect of getting paid for it. > > Under the LGPL, the only possible business model is this: > a) Find someone who might need some piece of code > b) Sell them on: "We can do this for you, and release it under > the LGPL for $x dollars. We're really good at what we do, > honest" > c) Do the work, and hope to actually get paid. well, a)+b) is really the same, and you left out d) sell support on the changes, but yes, there are only 3 choices. I really think that *GPL will have problems in the long term because there is no real economic way to sustain it, but it's going to take VAlinux/SUSE/RedHat to finally go down in flames for people to take a long, hard look at the issue. Think the patent model (with a much shorter protection period) is a good place to start. > The LGPL simply slams the door shut on that whole model, saying in effect > "It's my way or the highway". It also slams the door shut to non-development areas too. -r

1 0

Re: wine-devel digest, Vol 1 #714 - 13 msgs
by Roger Fujii 07 Feb '02

07 Feb '02

dschwarz(a)bellatlantic.net wrote: > Consider doing what ghostscript does (http://www.ghostscript.com/) New > versions are released under the AFPL license (more restrictive than GPL). > Old versions are re-released under GPL when they are about 1 year out of > date. This is fine for the "owners" of the project. It gives them a grace period and makes sure that changes gets worked back in. However, if you are on the outside, it blows, since you must IMMEDIATELY make your changes available (because of the GPL). > How this could be applied to Wine: Going forward, all builds are released > under LGPL. They are then re-released one year later under an X11 style > license. This won't work very well since all that this is really requiring is that changes to the changes are LGPLed, but not changes to the base. What might work is this (though this won't be considered "open" by those self-professed 'champions' of open-source. BSD/X11 base with the following LGPLish addition: Modifications to 'derived work' must be made available within 12 (or some reasonable period) months of initial publishing under the same terms. This way, unmodified versions aren't virialized like the GPL, but you will (eventually) have access to any improvements. -r

1 0

RE: Wine license change: it's about time!
by Patrik Stridvall 07 Feb '02

07 Feb '02

> Patrik Stridvall wrote: > > > Bottom line is clear: as the project matures and becomes more > > > useful, the deterant of contributing code back from a business > > > perspective is going to greatly increase, while at the same > > > time, the incentive under the LGPL would have also increased. > > > > This is a just claim without any sort of proof. > > It seems like a reasonable analysis to me; contributing code > represents a bigger and bigger gift as Wine comes closer to > completion, > as your competitors will be able to produce useful products with > less and less work. The only likely head to head competitors that I can see are two companies that uses Wine to port their competing applications. As Wine nears completion, the competive advantage fixing Wine at all instead of working around the difference in their respective application becomes quite low so I don't think we will see that many patches from either. LGPL or no LGPL. > Under the LGPL, this is ok, because you'll have > access to the competitor's code as soon as he starts shipping ig. > Under the X license, you're in trouble, and have to hustle to > reproduce > the work the competitor did. In the longer perspective neither company will live or die because the better quality of the Wine port, but rather because of the better quality of their application. So even the company that is nice to Wine is not likely to suffer serious competive disadvantages anyway. In fact it might even make sense to them to make a deal that they should treat Wine as it was LGPL despite being competitors. But this is their choice and we shouldn't force it on them. > > For head to head competitors > > it has some (but only some) relevance. However this is not > the kind of > > business models we are likely to see IMHO. > > Really? Sun doesn't compete head to head with IBM? I some markets, yes. In the Wine market neither of then competes so your example is largerly irrelevant. Anyway, if both would enter the Wine market I would be very suprised if they really competed head to head. I would rather think they did it in some niche of their own. > > > In economic terms, for Wine, one spells death, the other, life. > > > > Another grandiose claim without any substance. The world is not that > > simple. Both approaches has their pros and cons but neither is life > > not death. > > It captures the essense of how the two licenses set up incentives, > though. In a simplified enconomic theory: Perhaps. In the real world: Difficult to tell, but I believe not. > I think Patrik and I agree that it's important for the Wine license > to provide economic incentives for companies to contribute to the > Wine project. Yes. > His legal analysis of the LGPL differs so sharply > from mine (or that of most people), as far as I can tell, that > just about nobody agrees with his point of view on it. Perhaps it is because I'm bad on explaining what I mean. Anyway, I would rather be alone and right than not alone and wrong. :-)

1 0