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...
On Thu, Feb 07, 2002 at 03:50:56PM +0100, Andreas Mohr wrote:
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...
If that's the wish of the Wine community (as opposed to the wish of a group of armchair quarterbacks on Slashdot who've never written a line of published code), then there's no need for a license change at all. The present license allows one to take the Wine code and use/redistribute it under the LGPL at any time.
The primary reason to convert the WineHQ repository to LGPL is if we want to ensure that other companies/individuals don't contribute less back to Wine than is required by the LGPL when they make modifications. If you think that would be a bad thing, then vote against converting to the LGPL. I imagine that being bound by the LGPL would make Jeremy's position easier during contract negotiations, though, because it would leave his clients with no choice but to accept the terms that he already wants them to accept anyway. :)
Cheers, Steve Langasek postmodern programmer
On Thu, 7 Feb 2002 09:13, Steve Langasek wrote:
On Thu, Feb 07, 2002 at 03:50:56PM +0100, Andreas Mohr wrote:
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...
If that's the wish of the Wine community (as opposed to the wish of a group of armchair quarterbacks on Slashdot who've never written a line of published code), then there's no need for a license change at all. The present license allows one to take the Wine code and use/redistribute it under the LGPL at any time.
Does it matter if they have written code for Wine or not? I test out and attempt to debug bugs in Wine when they show up on FreeBSD. Let's just say that I have not been all that successful. :)
If not, let me say that I see no reason to change the current license. The LGPL may push proprietary code from the Wine core, but it will just push it into DLL's.
Remember that not everyone will contribute back. Why should you expect them to assuming you are not a Moonie? Maybe they have nothing to contribute back. Maybe they don't want to contribute back. Forcing them into sharing is not sharing.
As for commercial interest, I see that Apache+modssl has done quite well against any closed-source versions.
The primary reason to convert the WineHQ repository to LGPL is if we want to ensure that other companies/individuals don't contribute less back to Wine than is required by the LGPL when they make modifications. If you think that would be a bad thing, then vote against converting to the LGPL.
I strongly dislike coercement of any sort when it comes to open source. I would like to vote to keep the license as is, but I am only a user and part-time open-source developer. It must be that armchair quarterback in me trying to come out. :)
Sean -------------- scf@farley.org
On Thu, Feb 07, 2002 at 09:41:53AM -0600, Sean Farley wrote:
Does it matter if they have written code for Wine or not?
Yes. If they have not contributed, nor will contribute, code to Wine under the current license, then their opinions on the license have no impact on whether they will contribute to Wine in the future, and they should be ignored when examining the question of whether the LGPL is an ok license to use.
I test out and attempt to debug bugs in Wine when they show up on FreeBSD. Let's just say that I have not been all that successful. :)
Then you're not among the aforementioned Slashdot armchair quarterbacks. But then, I wouldn't expect anyone participating in the discussion /here/ instead of on Slashdot to be so. :)
If not, let me say that I see no reason to change the current license. The LGPL may push proprietary code from the Wine core, but it will just push it into DLL's.
The DLL model is already set by the Microsoft APIs. A company can't get around the LGPL this way and still have a useful product, even if the LGPL allowed it (which it doesn't). If the existing Wine DLLs are released under the LGPL, then modifications to those DLLs must be released under the LGPL as well.
Remember that not everyone will contribute back. Why should you expect them to assuming you are not a Moonie? Maybe they have nothing to contribute back. Maybe they don't want to contribute back. Forcing them into sharing is not sharing.
Under the LGPL, everyone /will/ contribute back, because that's what the LGPL requires. 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.
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. I'm not here to do free programming on behalf of companies that don't believe in Free Software and in the Community. It is the right of the copyright holder to choose the license, and although I usually disagree with the choice of a BSD license, I have no problem with people who choose such a license. I just think copyleft is better. :)
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, and trying to avoid forks leads to infrastructure issues as you need more and more management to make decisions and guide the project. 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. 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.
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?
Steve Langasek postmodern programmer
Steve Langasek wrote:
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 you really think of competing with MS then you should think about who will actually use wine. The you can decide on which is the best licence to support these users and also supports the developers.
Hello,
I haven't contributed anything sorry but i'd just like to state that dual licensing would make none commercial use and usage in open source projects possible but also get something back from companies.
At the moment everyone is allowed to resync with the wine code if there are changes but if you sold a license for releases to companies and they would have to purchase a seperate license for each release in order to be allowed to keep their code to themselves that'd discourage forking, brute force maybe.
As they try to make money, it is only fair to give something back to the wine developers.
Good luck and thanks, David
On Thu, Feb 07, 2002 at 09:13:15AM -0600, Steve Langasek wrote:
On Thu, Feb 07, 2002 at 03:50:56PM +0100, Andreas Mohr wrote:
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...
If that's the wish of the Wine community (as opposed to the wish of a group of armchair quarterbacks on Slashdot who've never written a line of published code), then there's no need for a license change at all. The present license allows one to take the Wine code and use/redistribute it under the LGPL at any time.
Eh ? How so ? :)
This wouldn't result at all in not having a need to change the license. Currently everybody can rob the hell out of us (yeah, I know, drastic words :). With "selective" licensing, you could make "beneficial" companies benefit.
Anyway, that was only some suggestion of some /. guy, not sure whether it's a good idea.
A few brief comments:
* LGPL may well be legal gibberish. Be sure to consult non-FSF lawyers as well as talking to the FSF. This is problematic because a gibberish license will discourage use. I know that I would be cautious linking source with a value of 100M against something LGPL, if I was worried about the risk that a judge might decide that by so doing I'd created a derived work, and thus had gnuified my entire source.
* Creating an LGPL tree will inevitably create public forks, not prevent them. There are many private forks already. These are necessary, because every corporate entity modifying Wine needs to have control over their own destiny. So far, there has been only one public Wine tree, precisely because everyone could do whatever they wanted with it. Creating an encumbered tree would end this state of affairs. Keeping track of the Wine source entirely unencumbered by the Gnu virus is too important to imagine that no one would do it. Whether this is good or bad depends on your point of view on forks.
* I don't understand the impetus for change. Is it because some companies are (finally, after many years of encouragement) starting to make use of their right to keep some of their work proprietary? What, exactly, is wrong with proprietary versions anyway? Didn't this all get hashed out years ago when the license was picked in the first place? Allowing proprietary enhacements is the single most important aspect to encouraging use of Wine technology. That's true even if the enhancements are entirely nontechnical, e.g. purely sales and marketing. I encourage anyone who thinks marketing an OS is easy to start selling their own version of Wine under any license and at any price point they choose. Competition is good.
Needless to say, assuming that anyone would listen to me anymore, I would oppose the creation of an LGPL fork.
doug. ridgway@winehq.com
On Thu, 7 Feb 2002, Douglas Ridgway wrote:
- LGPL may well be legal gibberish. Be sure to consult non-FSF lawyers
as well as talking to the FSF. This is problematic because a gibberish license will discourage use. I know that I would be cautious linking source with a value of 100M against something LGPL, if I was worried about the risk that a judge might decide that by so doing I'd created a derived work, and thus had gnuified my entire source.
This is so much FUD that even Microsoft would blush. If this would even be a _possibility_, no comercial company would release products on Linux, since they most likely link against glibc. I assure you the Oracle DB is worth more than 100M...
This is kind of argument that really show, in my mind, that the arguments pro-BSD are quite weak, really.
-- Dimi.
On Thu, 7 Feb 2002 15:26, Dimitrie O. Paun wrote:
On Thu, 7 Feb 2002, Douglas Ridgway wrote:
- LGPL may well be legal gibberish. Be sure to consult non-FSF lawyers
as well as talking to the FSF. This is problematic because a gibberish license will discourage use. I know that I would be cautious linking source with a value of 100M against something LGPL, if I was worried about the risk that a judge might decide that by so doing I'd created a derived work, and thus had gnuified my entire source.
This is so much FUD that even Microsoft would blush. If this would even be a _possibility_, no comercial company would release products on Linux, since they most likely link against glibc. I assure you the Oracle DB is worth more than 100M...
The lawyer currently contacted works for the FSF. Of course he thinks the LGPL is suitable. Contacting an outside (non-affiliated) lawyer is a wise thing to do.
Since the LGPL has not been taken to court, no legal precedence for it has been set. Has something happened recently to change this?
Sean -------------- scf@farley.org
On Thu, 7 Feb 2002, Sean Farley wrote:
Since the LGPL has not been taken to court, no legal precedence for it has been set. Has something happened recently to change this?
This is true, but the fact that open-source developers start spreding this low-life kind of FUD about the LGPL is really, truely sickening.
Of all the companies releasing _commercial_ software on Linux (more so, I might add, than on *BSD), none of them had issues linking against the LGPL. It's a sad day when the *BSD proponents attack the LGPL based on such disgusting FUD.
I'm sorry for the strong language, but it pains me to see the discussion derailed in such a fashion.
-- Dimi.
On Thu, 7 Feb 2002, Andreas Mohr wrote:
This wouldn't result at all in not having a need to change the license. Currently everybody can rob the hell out of us (yeah, I know, drastic words :). With "selective" licensing, you could make "beneficial" companies benefit.
Anyway, that was only some suggestion of some /. guy, not sure whether it's a good idea.
By way of compromise, and maybe keep Gav happy, would it make sense to license those parts of Wine that have fairly well established implementations as LGPL, and "stub dll's" as frre-for-all? I know it is a fuzzy distinction, and it could be a fair bit of work to actually do it and I guess it would need to be adjusted continually...
FWIW
Lawson
The Devil finds work for idle minds.
On Thu, Feb 07, 2002 at 06:39:01PM +0100, Andreas Mohr wrote:
On Thu, Feb 07, 2002 at 09:13:15AM -0600, Steve Langasek wrote:
On Thu, Feb 07, 2002 at 03:50:56PM +0100, Andreas Mohr wrote:
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...
If that's the wish of the Wine community (as opposed to the wish of a group of armchair quarterbacks on Slashdot who've never written a line of published code), then there's no need for a license change at all. The present license allows one to take the Wine code and use/redistribute it under the LGPL at any time.
Eh ? How so ? :)
This wouldn't result at all in not having a need to change the license. Currently everybody can rob the hell out of us (yeah, I know, drastic words :). With "selective" licensing, you could make "beneficial" companies benefit.
Anyway, that was only some suggestion of some /. guy, not sure whether it's a good idea.
Ok, I was assuming a dual license of the current license plus the LGPL, which is equivalent to the current license because the permissions it grants are a superset of those in the LGPL.
If you're talking about selective licensing, the problem you run into is getting approval from all of the copyright holders involved. There are 324 entries in the Wine AUTHORS file that I have on my system, and chances are that more than one of them would have to give approval for a new license for any given file within Wine. If people see a need to be able to license code under a license other than the LGPL, I see this as a strong reason to consider not switching to the LGPL at all, because of how difficult it would make relicensing.
Steve Langasek postmodern programmer
On Thu, Feb 07, 2002 at 04:29:47PM -0600, Steve Langasek wrote:
On Thu, Feb 07, 2002 at 06:39:01PM +0100, Andreas Mohr wrote:
On Thu, Feb 07, 2002 at 09:13:15AM -0600, Steve Langasek wrote:
On Thu, Feb 07, 2002 at 03:50:56PM +0100, Andreas Mohr wrote:
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...
If that's the wish of the Wine community (as opposed to the wish of a group of armchair quarterbacks on Slashdot who've never written a line of published code), then there's no need for a license change at all. The present license allows one to take the Wine code and use/redistribute it under the LGPL at any time.
Eh ? How so ? :)
This wouldn't result at all in not having a need to change the license. Currently everybody can rob the hell out of us (yeah, I know, drastic words :). With "selective" licensing, you could make "beneficial" companies benefit.
Anyway, that was only some suggestion of some /. guy, not sure whether it's a good idea.
Ok, I was assuming a dual license of the current license plus the LGPL, which is equivalent to the current license because the permissions it grants are a superset of those in the LGPL.
If you're talking about selective licensing, the problem you run into is getting approval from all of the copyright holders involved. There are 324 entries in the Wine AUTHORS file that I have on my system, and chances are that more than one of them would have to give approval for a new license for any given file within Wine. If people see a need to be able to license code under a license other than the LGPL, I see this as a strong reason to consider not switching to the LGPL at all, because of how difficult it would make relicensing.
Oh right, I didn't think of this particular communications problem in this case.
Another drawback of a license change might be that reverting from (L)GPL license to previous licenses is said to be very hard.
As nobody else didn't bring it up, I'd like to suggest that proponents of a license change create a web site scientifically discussing all pros and cons of a license change in a well-written form that can serve as a basis for a final decision on this topic. (instead of risking to have major flaming about pretty much irrelevant points on this list, that is ;-)
Right now it looks like the license change intention might face a grim future (whether that's good or bad - no idea), thus it'd probably be useful to have a detailed reference page on this very important problem.
Andreas Mohr wrote:
As nobody else didn't bring it up, I'd like to suggest that proponents of a license change create a web site scientifically discussing all pros and cons of a license change in a well-written form that can serve as a basis for a final decision on this topic. (instead of risking to have major flaming about pretty much irrelevant points on this list, that is ;-)
Right now it looks like the license change intention might face a grim future (whether that's good or bad - no idea), thus it'd probably be useful to have a detailed reference page on this very important problem.
I dunno, I've been through this kind of thing before, and it might be best to simply create the LGPL tree and see how people react to it. Talk is cheap, as they say.
- Dan
-
Andreas Mohr -
Dan Kegel -
David Speckbacher -
Dimitrie O. Paun -
Douglas Ridgway -
Gerhard W. Gruber -
lawson_whitney＠juno.com -
Sean Farley -
Sean Farley -
Steve Langasek