Alexandre Julliard julliard@winehq.com wrote:
My conclusion is that there clearly isn't enough support in the developers community to justify changing the license. So I'm not going to proceed with any change, either now or in the foreseeable future.
hurrah.
before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs.
This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license.
-r
Roger Fujii wrote:
Alexandre Julliard julliard@winehq.com wrote:
My conclusion is that there clearly isn't enough support in the developers community to justify changing the license. So I'm not going to proceed with any change, either now or in the foreseeable future.
hurrah.
I'm sad. The LGPL seems like the clearest hope we have of protecting Wine against companies that want to take it and never contribute code back. Its protection might not be airtight -- but it would clearly communicate the spirit. And my impresson was that the majority of Wine developers agree.
before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs.
Agreed, programs that generate code should specify what license the generated code is under.
This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license.
I think it's clear that Wine cares, and should be careful not to alienate companies like Codeweaver and Transgaming. One way to deal with Transgaming might be to start a campaign to get people to buy Transgaming subscriptions, or perhaps try to rummage up enough of a one-time payment to get Transgaming to contribute their current changes back. I suspect that there's some such arrangement they'd be happy with.
- Dan
On Sunday 23 December 2001 4:09 pm, Dan Kegel wrote:
Roger Fujii wrote:
Alexandre Julliard julliard@winehq.com wrote:
My conclusion is that there clearly isn't enough support in the developers community to justify changing the license. So I'm not going to proceed with any change, either now or in the foreseeable future.
hurrah.
I'm sad. The LGPL seems like the clearest hope we have of protecting Wine against companies that want to take it and never contribute code back.
Whether or not Wine *needs* "protection" from this is another question. If I have a super improved version of Wine and don't distribute it, no harm is done to anyone. IMO, the "danger" of someone creating a proprietary Wine is a strawman - there's already a set of proprietary Win32 implementations out there from some outfit in Redmond, and it hasn't killed Wine development AFAICS :-)
Its protection might not be airtight -- but it would clearly communicate the spirit. And my impresson was that the majority of Wine developers agree.
before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs.
Agreed, programs that generate code should specify what license the generated code is under.
"Agreed"? My view is that compilers (or any "program that generates code") should have *NO* say whatsoever in licensing of the output. Or do you want to see VC++ prohibiting the development of software competing with MS offerings?
This inadvertant problem is precisely why *GPLed stuff has to be scrutinized carefully if you care about commercial relationships (most *GPL projects don't care) and is why commerical interests are wary of projects with a *GPL license.
I think it's clear that Wine cares, and should be careful not to alienate companies like Codeweaver and Transgaming. One way to deal with Transgaming might be to start a campaign to get people to buy Transgaming subscriptions, or perhaps try to rummage up enough of a one-time payment to get Transgaming to contribute their current changes back. I suspect that there's some such arrangement they'd be happy with.
IMO, the current license is working just fine. Wine is getting developed and used by plenty of people: as was pointed out earlier, using a more restrictive license would have harmed Wine, rather than helping. (I'm reminded of the proverb about the monkey with a jar of sweets here: in situations like this, if you force an "all or nothing" choice on people, they will choose the latter...)
James.
On Sun, 23 Dec 2001 09:10:45 -0800, James A Sutherland wrote:
On Sunday 23 December 2001 4:09 pm, Dan Kegel wrote:
Roger Fujii wrote:
Alexandre Julliard julliard@winehq.com wrote:
[snip.]
"Agreed"? My view is that compilers (or any "program that generates code") should have *NO* say whatsoever in licensing of the output. Or do you want to see VC++ prohibiting the development of software competing with MS offerings?
[snip]
In fact, the VC++ license says that you may not use it to develop software not intended for the Microsoft Windows platform.
James A Sutherland wrote:
before this is concluded, I will add one thing just for the sake of archival (in case this comes up again). If ALL of wine were strictly LGPLed, basically, *all* propriatary extensions could no longer be included. Why? Because the output of winebuild will be LGPLed, thus no propriatary programs could use its output in creating a shared library. winebuild is like bison in this case, and the output of bison has a special exemption so that you can use it in something other than *GPLed programs.
Agreed, programs that generate code should specify what license the generated code is under.
"Agreed"? My view is that compilers (or any "program that generates code") should have *NO* say whatsoever in licensing of the output. Or do you want to see VC++ prohibiting the development of software competing with MS offerings?
Because generated code could be considered a derived work of the compiler, programs that generate code need to expressly disclaim rights to the generated code to avoid restricting the use of that code. If the compiler vendor fails to expressly spell out the licensing of the generated code, users of the compiler are left in an unclear legal position.
- Dan
On Sun, 23 Dec 2001, James A Sutherland wrote: [...]
I'm sad. The LGPL seems like the clearest hope we have of protecting Wine against companies that want to take it and never contribute code back.
Whether or not Wine *needs* "protection" from this is another question. If I have a super improved version of Wine and don't distribute it, no harm is done to anyone. IMO, the "danger" of someone creating a proprietary Wine is a strawman - there's already a set of proprietary Win32 implementations out there from some outfit in Redmond, and it hasn't killed Wine development AFAICS :-)
Well, this outfit probably does not use any code from Wine. But I am pretty sure that if this line of products were taken out of the streets tomorrow for good so that it were impossible to buy any computer with this product or to buy the product itself in stores, well if that unlikely event were to take place I am sure that we would see a lot of companies (both users and vendors) very eager to contribute to Wine to ensure that there is still a platform to run their legacy applications on ;-) I am sure that we would see Wine and Winelib make big progress, at least for couple of years... So in that way they are harming the development of Wine :-) Ok it's a bit far fetched, but still, their is some truth in the above if you think about it.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
I think it's clear that Wine cares, and should be careful not to alienate companies like Codeweaver and Transgaming. One way to deal with Transgaming might be to start a campaign to get people to buy Transgaming subscriptions, or perhaps try to rummage up enough of a one-time payment to get Transgaming to contribute their current changes back. I suspect that there's some such arrangement they'd be happy with.
I tried to do just that and got rejected by the online payment system for some odd reason....I wonder how many others have experineced this and thus........
just a fyi
lee -===
-
Dan Kegel -
Daniel Sabo -
dfd -
Francois Gouget -
James A Sutherland -
Roger Fujii