wine-devel

wine-devel@winehq.org

4 participants
84401 discussions

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

09 Feb '02

Roland (roland(a)netquant.com.br) writes: >To write it again we have two interests: > >1. People who want to make money selling WINE or derivates == anti xGPL >2. People who contribute for free or have another business model than the >above == pro xGPL There are a few more categories who would not want the (L)GPL: 3. Professional programmers who would like to fix bugs (if the code is (L)GPLed, they can't without becoming "tainted" by having read the code); 4. Anyone who objects to viral licenses or the FSF's misleading propaganda; 5. Users who want to be able to buy a commercial product with professional support, especially good integration, and possibly enhanced features; 6. Anyone who does not want to see WINE fork into truly free and FSF-licensed versions; and 7. Anyone who cares, on principle, about software freedom and choice. --Brett Glass

4 4

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> What's lacking in this discussion is some sensible analysis of what a > license need to contain to encourage future contributions to > Wine and to > protect the interests of the contributors. Fearmongering about Wine's > future and paranoid delusions about the GPL license doesn't > bring anything > to the table... Agreed. > Over to category two. Corel's source of income isn't from > improving Wine, > it's from selling their own work, Wine just makes their work > more valuable. > Here it doesn't really matter if Wine is BSD or LGPL > (remember that the > INTENT of the LGPL isn't to infect all and everything). > > A company that chooses this route may have to improve Wine > here and there > to fill in the missing pieces to make their port work, and by > releasing > this patch they will contribute to Wine as a whole. > > Unfortunatley they might not, don't underestimate the power > of laziness. > One other plausible reason is that some bean counter is afraid that > someone else will pick up their work for free and make money out of it > (i.e. Lindows) how'd you explain that to your shareholders? Companies in this group have several choices: 1. Don't use new improvement in the main Wine tree, only resync then a new major version of the application should be released. 2. Maintain a tree by themselves, continually resyncing in order to make even minor version take advantage of new improvements in the new Wine tree. 3. Have some sort of wrapper library that implement all the improvments that they don't what to release, that in turns calls the Wine real corresponding Wine function. Now they can, if the designed it correctly, use new versions of Wine without any problem. 4. Release the code to the Wine project and be able to run with the latest version of Wine without any problem. (1) and (2) are not very attractive. Resyncing the trees are quite time consuming. Especially (2) will not be fun at all. Both requires continously working with Wine. In any case I guess most companies want the Wine adaption to be a ONE TIME cost not a continous one. Likely they want to hire specialists from companies like CodeWeavers. This leaves (3) and (4). If you design (3) wrongly the application will break with newer version of Wine so it is not really a that good choice either. In addition it will require extra work just to be able to hide the improvments. This leaves (4) ie they treat Wine is LGPL even if it isn't. I think you will be able convince both the lazy person above as well as the bean counter that this will be the best long time choice. > If Wine is LGPL they must release the patch if they want to reap the > benefits of using Wine, and they can release it without fear of giving > away money to someone else. It can even be argued that the > LGPL makes Wine > an even safer bet, since it guarantees that other companies > in this group > will chip in, this way Wine will be in even better shape when > the first > application was a smash hit and they decide to port their next app! :) Correct, but this is likely to be true anyway for reasons given above. This is what I imagine the LGPL proponents are dreaming about at night. Unfortunately it is a dangerous dream since it total ignores the drawbacks with a LGPL:ed Wine. > Companies that decide to develop a new app and use Wine as the cross- > platform framework also belongs to this group. Partly, but new applications can avoid using unimplemented functions so they are less likely to contribute anything back. > Back to Wine again, the selfish motive here is to make Wine > better faster. > So if we get the choose between companies in group 1 or 2, who will > contribute the most? Obviously the ones in group 1 will do > the most work, > since their living relies on a perfectly working Wine, > unfortunatley they > have the least to gain from contributing anything back. The > companies in > group 2 have the least incentive to work on Wine, just fix the bare > minimum to get their application to work, but instead they can allow > themselves the luxury to contribute and score some goodwill. Since companies in group 2 are likely to contribiute back anyway for reasons given above I see no reason to hurt group 1 companies. > So what's the conclusion? Either you pick your favourite way of making > business and lobby for a compatible license, or you start > thinking out of > the box and find the perfect balance that let's everyone keep > the cake and > eat it... Well, that would be good. However I'm pretty convinced that a very good solution would be not moving to LGPL. While perhaps not the ultimate solution, I have a gut feeling that no better soltion exists in the real world. > I'll be back tomorrow with more opinions, and my stab at > thinking out of > the box. Your welcome.

2 1

Re: Dr. Seuss, licensing, and WINE
by David Elliott 09 Feb '02

09 Feb '02

On 2002.02.09 05:32 Plato wrote: > On Sat, Feb 09, 2002 at 03:50:09AM -0500, David Elliott wrote: > > On 2002.02.08 15:03 Brett Glass wrote: > > [...] > > >taxes: It will act in its own interest, not yours. The FSF's > > >sole goal is to destroy commercial software developers, and > [...] > > Give me a break dude. Yes, the FSF wants all software to be free and > > wants to rid the world of commercial software altogether. > [...] > > I think it is worth pointing out the the Free Software Foundation does > *not* > want to rid the world of commercial software. > > Stallman has, however, stated that he would like to rid the world of > *proprietary* software. > Whoops, sorry, you are correct about that. However to the person I was replying to commercial==proprietary. Red Hat Linux is a commercial product, but not proprietary (to give an example). Though I think Red Hat does have a few proprietary products they work on. > There is an incredibly important difference. Please do not use the terms > interchangably. See > > http://www.gnu.org/philosophy/words-to-avoid.html#Commercial > http://www.gnu.org/philosophy/software-libre-commercial-viability.html > Been there long ago.. just kinda forgot. -Dave

1 0

RE: Wine, enthusiasts, businesses and the agony of the license
by vinn 09 Feb '02

09 Feb '02

IANAL, yada, yada [nor can my involvement with Wine be considered anything more than minor] Patrik wrote: > Companies in this group have several choices: > 1. Don't use new improvement in the main Wine tree, only resync > then a new major version of the application should be released. > 2. Maintain a tree by themselves, continually resyncing in order > to make even minor version take advantage of new improvements > in the new Wine tree. I just want to throw a couple of ideas out about using an LGPL license. There's a lot of people with a heck of lot more at stake than me, and ultimately they deserve to have their opinions weighed more heavily than mine. Ultimately these ideas stem from the practice of licensing software rather than the theory (which is where this thread was headed). First, the LGPL doesn't really ever give a time frame for modifications to be released back. We can safely assume that it means "in a timely manner", since in practice this is how it works. I think we could collectively agree that a company such as Transgaming could be allowed a grace period in order to submit their modifications back. Whether this is a week or a year can be debated. If for no other reason than to ensure clean code. Now you may argue that a year is too long, but keep in mind that the modifications do have to be released, and if it takes them a year the amount of work required for a resync may impact other operations. Second, the LGPL doesn't state how the modifications have to be released. In practice this is done electronically via patch files or access to a modified tree. But there's no reason why the modifications couldn't be released on handwritten post-it notes available by request only. In this manner there is a non-trivial amount of work required to integrate the changes. ------ Brian Vincent vinn(a)theshell.com

3 2

something to do
by Jason Phillips 09 Feb '02

09 Feb '02

Hello everyone, I'm interested in doing some work on the wine project. There's quite a few bugs in the bug list are any in particular that someone would recommend as a good place to start? I might need to document for my own good also. Any guidelines on what/how that should be so it can be contributed? Jason Phillips

3 2

RE: Wine, enthusiasts, businesses and the agony of the license
by Patrik Stridvall 09 Feb '02

09 Feb '02

> On Sat, Feb 09, 2002 at 11:40:54AM +0100, Fredrik Ohrn wrote: > > Another observation is that companies in group 1 are in > direct competition > > with each other, so they want closed source. If TransGaming > released their > > DirectX work BSD style, Lindows would quickly be there to > appropriate it. > > You miss one case here: Companies in group 1 that also want > to make money > with group 2s business model. They could do that easily and > it would give > them a distinct competitive advantage over the group 2 only > type enterprises. > Result: The group 2 only companies *can't* release their > sources any more > if they want to stay in business. I'm not sure that I follow you. Groups 2 companies (like Corel) have one or more Windows application that are likely to be their primary source of income. How can group 1 (like CodeWeavers and Transgaming) companies compete with that? Sure they can compete other group 1 companies to get contract with the group 2 company. If the application was DirectX based I can imagine that Transgaming are likely to give a better bid. But I don't see how they compete with the group 2 company. And in the example above I'm sure that Gavriel according to his promises will release any non-DirectX related stuff he had to do in order to fulfill the contract and if group 2 company is nice perhaps they might even require him to release some of the DirectX related code.

1 0

RE: Dr. Seuss, licensing, and WINE
by Patrik Stridvall 09 Feb '02

09 Feb '02

> If people don't understand that some people are decent and > contribute back > regardless of whether they are forced to or not, but others > are not and > require a feedback loop to force this behavior, then they > don't understand > how the world works and we're just wasting time. That is not one of the problem, as far as I'm concerned I fully agree that there will be companies that will be, how should I put it, less honourable. There ALWAYS are in ALL markets. As I sidenote I would like to say that I believe that the LGPL for reasons stated in last debate will not be enough to stop less honourable companies from doing less honourable thing. You might believe me or you might not, as all people arguing against me last time. Be that as it may, that discussing is dead and I will in the future concentrate on "If the LGPL means what you say it does, we don't want the LGPL". > I think it's more of an issue of people thinking too much in > black/white > terms and people that lean strong towards one side or the other. Yes. Perhaps they are not nessarily thinking in black and white but their arguments are often presented that way. I'm not entirely blameless on that point either, I will try to do better in the future. > Look no further than the US political system for a good > example. You have > the Republicans and the Democrats. Generally they take every > issue to > opposite ends of the extreme such that 99% of congress is at > one extreme > or the other, but 99% of the population wants neither extreme. Exactly, but that is because: 1. They want votes so they can do that they feel is right. 2. The ignorant masses are not likely to understand subtle differences in opionion. When the voters give any of them support, the problem is that they didn't really support the extreme views they presented, but they are forced to do it anyway in order of not being accussed of betraying the will of the voter. In the cases of Wine. I hope that the people working with the Wine project are not among the ignorant masses and thus really are able to understand the subtle differences between different positions. > Essentially we could go on forver about X11/BSD vs. GPL. It's been > discussed to death already folks. What we need are reasonable > compromises. Of course you need to have people willing to > compromise to > do that. I suspect most developers are with the exception of > the view > vocal BSD people and the few vocal LGPL all the way people. > I myself am > certainly not at either extreme. Even if perhaps some people won't believe me. I not really an extremist. I try to take a pragmatic view of the world. I believe that GPL has its place, LGPL has it place and the BSD license has its place. However my analysis of the issues at hand makes me believe that LGPL would be really bad in the particular case of Wine, for reasons that I have tried to explain. I suggest that people try to think about scenarios of circumstances where possible extensions to Wine might be made. This might be business models like Transgaming or Lindows.com or just something Joe Hacker or Joe Ex-Windows-Shareware-Writer or Joe I'm-Conspiring -With-A-Proprietary-Library-Company-But-You-Can't-Prove-It are doing. Just like the examples in the my last mail. Then ask the questions: 1. Do you consider his or her behavior morally or ethically defendable? 2. Does it violate the letter of the LGPL? 3. Does it violate the spirit of the LGPL? 4. Does it violate the letter of copyright law? 5. Does it violate the spirit of copyright law? 6. Do you think any reasonable Judge/Jury would find him or her guilty? With the spirit of copyright law I roughly mean: Is it what congress intended and/or is it constitutional? Notice the and/or: It is possible for act of congress to be constitutional without being the intention of the congress.

2 1

Re: Dr. Seuss, licensing, and WINE
by Roger Fujii 09 Feb '02

09 Feb '02

Steve Langasek <vorlon(a)dodds.net> wrote: > Jeremy White, the man who posted the request for feedback that spawned > this discussion, the developer who is encouraging the Wine community to > adopt the LGPL, works for a company whose principal software product > (though not their only source of revenue) is a bundled package of a piece > of proprietary glue code and Wine functionality. > > Let me repeat. The person recommending the LGPL to us sells a proprietary > program built on top of Wine as part of the business model for his > company. if you are going to follow this line of reasoning, you have to ask jeremy whether or not the crossover plugin would have been written IN THE FIRST PLACE if wine was LGPLed at the time. I really think that LGPL would have at least *some* impact on the decision, which is why there is opposition - it impacts future contributers. > Now, do the people arguing that the LGPL would destroy all chance for > people to make a profit believe that Jeremy is stupid, or out to get you? I'll agree that the Brett overstated the case by saying "impossible". But it does make it very difficult and the thrust of the argument is sound. Even though I'm not too sure if codeweaver's business model is too sound (no flames please), but the request for LGPL makes sense because an LGPLed wine now would deny future competitors (even if they contribute) the advantage that they had. -r

1 0

Wine License change: Open question to Jeremy White
by Roland 08 Feb '02

08 Feb '02

Quote from Jeremy White: "However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's." Obviously you, Jeremy started this discussion. I don't want to sound curious, but I have the feeling that our discussion will be in vain if we don't know about those "events" you can't disclose. I mean suppose that the list reaches a consensus to stay at the BSD license. This wouldn't make a difference would it? You would simply say, sorry: but I have my reasons which I can't disclose and will start a xGPL fork of WINE now... So I think to consider all interests involved we must obviously first KNOW what they are specifically...otherwise we will just be wasting time without touching the really important points(your specific concerns among others...). Best regards, Roland

2 1

RE: Wine license change
by Patrik Stridvall 08 Feb '02

08 Feb '02

> I think that this message as well as many other bring up some > very good > points as to the needs of licensing within the wine project. > Many other > messages have been clearly in the realm of bsd-gpl feudalism. > I think that trying to find a license to fit the needs of the project > without first having a good understanding of the needs of the > project is a > serious error. Yes, that is what I have tried to say in my reply to Jeramy. We must define what we want to license to protect, but more importantly we must define what the we DON'T want the license to protect. Because "What doesn't the license protect?", more popularly known as "What can we get away with?" is the first question ALL new business models will ask. If the answer of that question is "Not Much" it might be very bad for most business module, but even worse if the answer to the question is "I don't know, it depends on your intent" or "I have no idea, the jury is still out" it will be very bad. >From my discussion with Alexandre last time he seems to believe that whether or it was allowed to implement a few function in some DLL in a LGPL Wine by linking to a proprietary library depended on my intent. I reject this absurd idea most violently. However consider for a moment: What if he is right? This means that with a LGPL:ed Wine: If somebody that had some proprietary library and thought hey with this library it should be quite easy to implement these functions in Wine that prevented these cool application to work. Some programming later... Great it works... Now I call Lindows, Red Hat, SuSE (whomever that distribute Wine) and tell them that I can license this library for $5 per end user to you. Some time later... Great at least some them accepted and the money keeps streaming in. Life is good. Questions: Is his intent bad? Would you sue him for violating the LGPL? If he publish his proprietary library function wrappers under the LGPL. If he didn't? What about the Linux distributor? Under what circumstances would you sue it? Another scenario: Joe Hacker has bought a proprietary library to use with his non Wine related hobby. One day he realizes that the one of his hobby related also proprietary Windows application he dual boots to since it never worked under Wine could be made to work by implementing the missing Wine functions with that library. He does so, it takes a weekend. It works. He puts out the patch to Wine under LGPL on a hobby related website for other that also owns the application and the library. He is happy since dual booting is but a memory. Life is good. Questions: Is his intent bad? Will you sue him? If some months or so later the maker of the protrietary library finds the patch and contacts the Linux distribution like in the case above. Will you sue the him, the proprietary library company or the Linux distribution? All this begs the questions: 1. Isn't it so, that as I claimed that the LGPL really doesn't protected this. 2. Or alternatively, if it really does make what some of the people above do illegal, do we REALLY want to use it? > It's pretty obvious that neither the a gpl > license nor a bsd > license are optimal. It only take the observation of the lack > on consensus > to see it. Quite. > All that I can really offer is this suggestion: end feuding > and start a > process to > 1. Gather the requirements to the licensing of the wine project > 2. Determine if any combination of existing licenses can meet the > requirements > 3. If no combination of existing licenses will suffice, write > a license > that does. Fully agree. > Additionally, I advise that everyone abandon there preconceptions of > licensing. There is no mandate that I know of to license the > whole project > under the same license, only use one license for any part of > the project, > only use existing licenses, license any part of the project > to different > groups under the same license. Quite true. However, take care with viral licenses, they might spill over to the other parts all the same.

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