Folks,
Some recent events have occurred that have made me change my opinion about a Wine license change.
During my involvement in the Wine project, I have always striven to make sure that I, and my company, did what was best for the Wine project. I believe Wine's success will help to make the world a better place. To that end, often through difficult personal negotiations, I have always insured that all of my contracts require that all code changes be returned to Wine. This, in effect, treats Wine as an LGPL product.
You can argue that the flexibility granted by the Wine license has meant that I received some business I would not otherwise have had. Gav, for example, has pointed out that Corel would never have worked on Wine if not for its license. There are two ironies there - first, Corel has always been a great Wine citizen, IMO, never 'abusing' the license. Second, while we did work with Corel to help them with Wine, we never signed a contract with them. Their lawyers and I were never able to agree on a contract that we thought would sufficiently protect Wine. Fortunately for me, we were able to work with Corel without a contract, but this issue to this day creates unnecessary friction between my company and Corel.
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.
Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. I think it it is great that we have, in Eben, not only the leading legal scholar on free software licensing, but a great hacker to boot. I think he will clarify exactly what is possible and what is not possible with GPL style licenses and insure that the license we choose will meet our goals.
When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.
I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:
Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine?
Please privately let Alexandre (julliard@winehq.com) know what you think, and then publicly respond to this thread as you feel appropriate.
Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.
Thanks,
Jeremy
Jeremy White wrote:
Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine?
Since I like the (L)GPL licenses, I have no problem and would favour that. If my voice counts, since I'm not that long working for wine.
On Wed, Feb 06, 2002 at 04:54:05PM -0600, Jeremy White wrote:
Some recent events have occurred that have made me change my opinion about a Wine license change.
...
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.
OK, when the last discussion was going on, I started out with the opinion that the change would be good and changed it to not so good, because if proprietary stuff that *is* part of the windows kernel (or drivers) needs to be implemented, this can't be done with an LGPLed wine. My final idea (which I never mailed) was, that maybe a X11-licensed kernel (including wineserver and driver emulation) and LGPLed dlls for the rest would be the best solution.
ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On Wed, 6 Feb 2002, Joerg Mayer wrote:
OK, when the last discussion was going on, I started out with the opinion that the change would be good and changed it to not so good, because if proprietary stuff that *is* part of the windows kernel (or drivers) needs to be implemented, this can't be done with an LGPLed wine. My final idea (which I never mailed) was, that maybe a X11-licensed kernel (including wineserver and driver emulation) and LGPLed dlls for the rest would be the best solution.
Yeah, that could work. But I still don't understand your objections about the proprietary drivers: LGPL would work just fine with that. What's your concern?
-- Dimi.
On Wed, Feb 06, 2002 at 07:51:04PM -0500, Dimitrie O. Paun wrote:
Yeah, that could work. But I still don't understand your objections about the proprietary drivers: LGPL would work just fine with that. What's your concern?
Look at the copy protection stuff that transgaming have added to their tree: they licensed it and thus quite likely can't publish the source for this - but I still want to see this in the binary only releases they make :-) Other scenarios I can imagine: drivers for hardware - think of a company that wants to port their software to Linux via wine but continue using a dongle or something like that: the dongle code is quite likely to go into the kernel itself (and may need some support for that by the wineserver).
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Joerg wrote:
OK, when the last discussion was going on, I started out with the
opinion
that the change would be good and changed it to not so good, because
if
proprietary stuff that *is* part of the windows kernel (or drivers)
needs
to be implemented, this can't be done with an LGPLed wine. My final
idea
(which I never mailed) was, that maybe a X11-licensed kernel
(including
wineserver and driver emulation) and LGPLed dlls for the rest would be the best solution.
I'm not sure why a re-implementation of proprietary stuff can't be done with an LGPLed Wine. If that was the case, wouldn't it be next to impossible for just about any LGPLed product to mimic the behaviour of a proprietary application? (eg KDevelop vs MSVC?)
Regards Chris Green Massey-Green Software Labs
Joerg Mayer wrote:
proprietary stuff that *is* part of the windows kernel (or drivers) needs to be implemented, this can't be done with an LGPLed wine. My final idea
Why not? If you write an app that looks like Word and behaves exactly like it, you should have no problem even though the original is proprietary code. It's not that you copy the program. The only problem could be that they could ask you how you got the knowledge to write that code in the first place, because it might not be documented anywhere. If you say that you had to reverse engineer it, then you would be in trouble (in some countries) but as long as you honour the license of the vendor and still get the same result. If that were so I guess that the entire wine project would be in trouble.
Hi Jeremy et al,
Well, for my 2c worth (or about 1c in US currency :)) I suspect most people who don't look at the license would assume that Wine is xGPL anyway, as so many Linux-type things are... so from a typical user's point of view they'd probably not notice the difference. The occasional contributor to Wine (myself included) probably thinks in terms of the GPL for any Linux-oriented, source-code included, project.
Personally, I'd be happy to see Wine converted to xGPL - just to make sure that there is a minimal chance of Wine forking in the future. I do believe that the xGPL licenses are the best way to avoid a fork in the project.
The other thing I just wanted to check was whether Alexandre was expecting to get a lot of emails saying yea or nay - if he's expecting it, I'm happy to send to him, but I'd hate to be part of an email flood of his mailbox :)
Regards Chris Green Massey-Green Software Labs
"Chris Green" chris@massey-green.com writes:
The other thing I just wanted to check was whether Alexandre was expecting to get a lot of emails saying yea or nay - if he's expecting it, I'm happy to send to him, but I'd hate to be part of an email flood of his mailbox :)
Please go ahead and fill my mailbox. I really want to know what everybody thinks.
This little offtopic but....What ever happend to TWINE? Is there anything of TWIN left that would be used moves to LGPL?
Steven
__________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com
Jeremy White wrote:
Folks,
Some recent events have occurred that have made me change my opinion about a Wine license change.
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.
If you can't be specific , then I can't lend any weight to your claim. You say there is a potential threat, but for all I know your just trying to scare everyone into a quick decision.
When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.
I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:
This is ridicules.. If you have something to say then post it to this group. Private emails to Alexandre aren't going to stimulate meaningful conversation.
Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.
So lets get this straight, if no one wants to change to the LGPL you'll fork the code? I don't have anything necessarily against the LGPL, but your email sounds all wrong.
Daniel Walker
So lets get this straight, if no one wants to change to the LGPL you'll fork the code? I don't have anything necessarily against the LGPL, but
your >email sounds all wrong.
I don’t see how there can be a problem here. The current license allows anyone to do whatever they please with the code. You should be happy they are asking.
Steven
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Steven Edwards wrote:
So lets get this straight, if no one wants to change to the LGPL you'll fork the code? I don't have anything necessarily against the LGPL, but
your >email sounds all wrong.
I don?t see how there can be a problem here. The current license allows anyone to do whatever they please with the code. You should be happy they are asking.
I know, but he isn't asking , he's saying he's going to do it regardless..
Daniel Walker
On Wed, Feb 06, 2002 at 07:08:39PM -0800, Daniel Walker wrote:
When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.
I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:
This is ridicules.. If you have something to say then post it to this group. Private emails to Alexandre aren't going to stimulate meaningful conversation.
I don't think anything in Jeremy's message suggested that conversation was a requirement. He's looking for feedback to get an idea of how members of the Wine community feel. But if you're open to being persuaded that the LGPL would be a Good Thing for the Wine community, I can try to oblige you.
Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.
So lets get this straight, if no one wants to change to the LGPL you'll fork the code? I don't have anything necessarily against the LGPL, but your email sounds all wrong.
One thing to bear in mind is that others already ARE forking the Wine code. Given the nature of their work, Codeweavers must maintain a separate CVS tree locally; although we're fortunate in that their fork is open to backporting to the official tree. Other companies are forking with no intention to contribute back (see Lindows.com); still others (Transgaming) have made reintegration of their work contingent on turning an profit.[1] Jeremy is at least being courteous enough to let us know where /his/ company is going with the Wine code, and is inviting the rest of the Wine community to come along with him.
Cheers, Steve Langasek postmodern programmer
[1] I'm not judging here, just using them for illustrative purposes; I was among those who signed off on the current Wine license, and I recognize that the Wine license allows such uses.
Steve Langasek wrote:
On Wed, Feb 06, 2002 at 07:08:39PM -0800, Daniel Walker wrote:
When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.
I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:
This is ridicules.. If you have something to say then post it to thisgroup. Private emails to Alexandre aren't going to stimulate meaningful conversation.
I don't think anything in Jeremy's message suggested that conversation was a requirement. He's looking for feedback to get an idea of how members of the Wine community feel. But if you're open to being persuaded that the LGPL would be a Good Thing for the Wine community, I can try to oblige you.
Go for it ..
One thing to bear in mind is that others already ARE forking the Wine code. Given the nature of their work, Codeweavers must maintain a separate CVS tree locally; although we're fortunate in that their fork is open to backporting to the official tree. Other companies are forking with no intention to contribute back (see Lindows.com); still others (Transgaming) have made reintegration of their work contingent on turning an profit.[1] Jeremy is at least being courteous enough to let us know where /his/ company is going with the Wine code, and is inviting the rest of the Wine community to come along with him.
I realize that there are many forks. That wasn't what I was getting at .. I didn't get the feeling of him "inviting" anyone to do anything ..
Daniel Walker
On Wed, Feb 06, 2002 at 08:17:39PM -0800, Daniel Walker wrote:
I don't think anything in Jeremy's message suggested that conversation was a requirement. He's looking for feedback to get an idea of how members of the Wine community feel. But if you're open to being persuaded that the LGPL would be a Good Thing for the Wine community, I can try to oblige you.
Go for it ..
The choice of the current license, IIRC (and someone correct me if I'm wrong -- it's been a long time) was guided by concerns that companies be able to build commercial products around it without fear of other companies taking their source code, doing nothing to improve Wine, and putting the first companies out of business by out-marketing them. In addition, there was the concern that companies be able to port their existing Windows apps to Unix via Wine without being subject to a license that forces them to release their proprietary code.
An LGPL licensing scheme is not in conflict with the second of these goals; and Wine looks a lot different now than it did when the current license was adopted, which may contribute to that. As to the first goal of fostering an environment in which companies can build on top of Wine ... it seems that one of the most successful companies incorporating Wine in their products, and the one that (at least from what I've seen) gives the most back to the Wine community, is not put off at all by the idea of having to release their source code; and from what I read of Jeremy's comments, he would much rather prefer that /everyone/ do likewise. For companies that are committed to Open Source, a copyleft license like the LGPL *enhances* the competitive advantage of those contributing back when compared with BSD-like licenses that don't guarantee continued Openness.
I imagine that, as a hard-working entrepreneur trying to stick to his principles, it's difficult for Jeremy to watch other companies come in and use his code without contributing anything back. I concede the possibility that switching to an LGPL license might turn some companies away from using Wine, and I would welcome evidence of that, as it would help us quantify the effect of such a license change; but in the absence of such evidence, I think we should consider the fact that the benefits to the Wine *community* from having Codeweavers around is substantial, regardless of whether the LGPL would encourage proprietary development *surrounding* that community.
One thing to bear in mind is that others already ARE forking the Wine code. Given the nature of their work, Codeweavers must maintain a separate CVS tree locally; although we're fortunate in that their fork is open to backporting to the official tree. Other companies are forking with no intention to contribute back (see Lindows.com); still others (Transgaming) have made reintegration of their work contingent on turning an profit.[1] Jeremy is at least being courteous enough to let us know where /his/ company is going with the Wine code, and is inviting the rest of the Wine community to come along with him.
I realize that there are many forks. That wasn't what I was getting at .. I didn't get the feeling of him "inviting" anyone to do anything ..
I think it is very much an invitation. It's clear to me from Jeremy's message that he believes the LGPL is the right business decision for Codeweavers, even if that means a fork. But forking is bad, after all, and he'd rather have a consensus in favor of LGPL if he can help it.
Steve Langasek postmodern programmer
Daniel Walker wrote:
Jeremy White wrote:
Folks,
Some recent events have occurred that have made me change my opinion about a Wine license change.
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.
If you can't be specific , then I can't lend any weight to your claim.You say there is a potential threat, but for all I know your just trying to scare everyone into a quick decision.
[...]
As someone with absolutely no connection to anyone at Codeweavers, I think Codeweavers' actions over the past two years or so more than sufficiently establishes the fact that they deserve to be given the benefit of the doubt in regards to statements like these. You can agree or disagree with their position as you wish, but I think such extreme skepticism is unwarranted and ungrateful.
-- James Juran jamesjuran@alumni.psu.edu
As someone with absolutely no connection to anyone at Codeweavers, I think Codeweavers' actions over the past two years or so more than sufficiently establishes the fact that they deserve to be given the benefit of the doubt in regards to statements like these. You can
agree
or disagree with their position as you wish, but I think such extreme skepticism is unwarranted and ungrateful.
Amen
_________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Jeremy White wrote:
... 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.
Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. ... Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.
It's about time. Putting Wine under the xGPL is the best way I can think of to ensure its future. The xGPL makes it possible for competitors to cooperate for their common good - which is pretty amazing. As Bob Young said at the formation of the Gnome Foundation (http://news.zdnet.co.uk/story/0,,s2080853,00.html): "There's been a fundamental problem of getting industry consortium to work together... But we don't have a single corporate lawyer in the room. We haven't signed a single licence among any of us... With the GPL, we have eliminated the need for trust." See also http://lists.essential.org/pipermail/random-bits/2001-June/000589.html
- Dan
On Thu, 7 Feb 2002, Dan Kegel wrote:
It's about time. Putting Wine under the xGPL is the best way I can think of to ensure its future. The xGPL makes it possible for competitors to cooperate for their common good - which is pretty amazing.
This is a fundamental point which we haven't had a chance of discussing last time as we argued over silly future (unlikely) possible changes in copyright law.
One important argument was that building a thriving economic environment around Wine is essential for its success.
Everybody agreed on this premise, IIRC.
The argument followed that BSD license is better for creating such an environment, and hence better for Wine, since more business will contribute more code back.
This, I'm afraid, is entirely false.
I argue that in fact, the BSD license is a STRONG DETERANT for businesses to contribute code back, while the LGPL provides an INCENTIVE.
Note that I do not care, for the purpose of this discussion, about businesses which don't intend to contribute code back. They are of no help to Wine, and thus irrelevant (if not a little harmful, for reasons so eloquently explained by Alexandre).
A BSD license is a STRONG DETERANT for a business to contribute code back. The reason for this is that they have no guarantee that another business will not improve a little the code, and thus get a competitive advantage. Or that other companies will not use that code on top of the code they wrote but not released, and thus again, get that edge. This is a fantastic _deterant_ for releasing code back. In fact, Gav validated exactly this point when he tried to argue for the BSD license last time:
<talking about the DCOM work> But there are companies out there who will benefit significantly from commercial use of this code, and who can afford to sponsor a portion of the development cost. Until such a sponsorship happens, we cannot apply the WineHQ license to that code.
In other words, they needed that code. They invested some money do get it. They are happy with the results. Why not release the code? They have what they needed in the first place? The reason is clear -- it cost them to get there, they can not aford to bring everybody there for free. I can 100% understand that. But if the code was under the LGPL, it would not matter, because even if they brought everybody there, other companies could not step ahead of them, since if they did, they themselves could have used that code.
In other words, TG could have kept Direct3D proprietary, released everything else back under LGPL, and they could have _known_ they still have the competitive edge in the D3D work! This is why the LGPL is in fact an _incentive_ for such colaboration.
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.
In economic terms, for Wine, one spells death, the other, life.
-- Dimi.
"Dimitrie O. Paun" dimi@cs.toronto.edu wrote:
[skipped]
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.
In economic terms, for Wine, one spells death, the other, life.
I don't want to participate too much in the license wars, but just want to add my supporting voice to the above words. I'm wholly for the license change.
While I do want to contribute further to this debate, I need some time to gather my thoughts. In the meantime though, I want to address Dimitrie's quote - and fundamental misunderstanding - of me below.
"Dimitrie O. Paun" wrote:
A BSD license is a STRONG DETERANT for a business to contribute code back. The reason for this is that they have no guarantee that another business will not improve a little the code, and thus get a competitive advantage. Or that other companies will not use that code on top of the code they wrote but not released, and thus again, get that edge. This is a fantastic _deterant_ for releasing code back. In fact, Gav validated exactly this point when he tried to argue for the BSD license last time:
<talking about the DCOM work> But there are companies out there who will benefit significantly from commercial use of this code, and who can afford to sponsor a portion of the development cost. Until such a sponsorship happens, we cannot apply the WineHQ license to that code.
In other words, they needed that code. They invested some money do get it. They are happy with the results. Why not release the code? They have what they needed in the first place? The reason is clear -- it cost them to get there, they can not aford to bring everybody there for free. I can 100% understand that. But if the code was under the LGPL, it would not matter, because even if they brought everybody there, other companies could not step ahead of them, since if they did, they themselves could have used that code.
In other words, TG could have kept Direct3D proprietary, released everything else back under LGPL, and they could have _known_ they still have the competitive edge in the D3D work! This is why the LGPL is in fact an _incentive_ for such colaboration.
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.
The current license, by contrast, allows many other alternate models that are worth trying. In the case of the DCOM code, there was something that we had a need for with our current subscriber base, but we could not afford to do the work just for that base, since it is not yet large enough. Instead, we have this business model: a) Do the work up front, proving that it works, covering a small portion of the cost from our current subscribers. b) Talk to potential sponsors who need the work c) If they agree on a price, release the code under the Wine license.
The TransGaming subscription model is simply this writ large, trying to get the individual users to act collectively as sponsors of the work.
The LGPL simply slams the door shut on that whole model, saying in effect "It's my way or the highway".
At the same time, I believe that I understand the main concern of the LGPL proponents: the current license allows the possibility of benefiting from the project without any contribution. Where I differ from them is that someone else's code is not enough to keep my employees eating. What I need as a contribution is not code, but cash.
Anyhow, I'm going to go and put my thinking cap on, and try to see if I can think of some arrangement that might work better for everyone.
-Gav
-
Alexandre Julliard -
Chris Green -
Dan Kegel -
Daniel Walker -
Dimitrie O. Paun -
Dmitry Timoshkov -
Gavriel State -
Gerhard W. Gruber -
James Juran -
Jeremy White -
Joerg Mayer -
Steve Langasek -
Steven Edwards