I tried to resist.... really.....
"J.Brown (Ender/Amigo)" ender@enderboi.com wrote:
Possibly, however remember that license may not always be for the application - it is for the product, including any proprietary works not GPL'ed, or support rights. It is also however true that the GPL'ed portion of the code may have no other restrictions placed on it's use.
other than the restrictions that the GPL imposes...
Going back to the user, how could a user who brought this infringing product be benefited from the developer suing? Mostly, they may not. In other cases, they benefit from the fact the code is again public, and they have a far easier way to see about getting bugs fixed, etc.. the usual benefits a good open-source project has.
Here is a good counter-example. Sun Microsystems developed a toolkit that would convert linux network drivers source to function with Solaris (their proprietary OS). It was just a toolkit. They weren't distributing driver binaries. AFAIK, this use is perfectly legal to do with the GPL. What happens? The GPL GNUts get all bent out of shape because it allowed use of their drivers under a proprietary OS, so Sun yanked it, even though they were not in violation. As a *USER*, this is a negative impact placed on me by the linux developers to exercise my rights, since it impedes my ability to USE GPLed software.
The usual argument about Gpl, that courts would not accept the action because there is no material interest (money) for Linus Torvalds, for example, in Linux, is akin to mine, but my point of view is not legalistic.
That's a load of bull, of course. A copyright has been violated.. it's like with a trademark - if someone violates a trademark, the owner comes very likely to forgoing his rights on that mark for not enforcing it.
You are confusing copyrights and trademarks. A copyright is not invalidated due to lack of an active defense. A trademark would.
All I wanted was installshield support! :p
All I want is for VirtualDub to work! :)
"Dimitrie O. Paun" dimi@cs.toronto.edu wrote:
I feel rather dismayed by the whole discussion.
Maybe this is so because the way you approached the issue. See, you are concerned with the semantics of things, the 'why',
I think the better question is "what" as in what is trying to be accomplished?
centuries. Second, even suggesting that a LGPL Wine will the an evil 'intelectual property' monster is ridiculous. Just a reminder, most open source projects are (L)GPL and _that_ community is the only significant force in today's society fighting against such things as software patents, DCMA, SSSCA, etc.
I would not equate the LPF with the FSF. They have very different agendas.
If we agree up to this point, what is the 'syntax' I was referring to? Well, IMO this is a stronger Wine that keeps evolving and that has a life of its own. Wether this is good or not for users it's irrelevant.
You probably meant something other than what you wrote here. Existence for the sake of existence is useless. I would presume the point of wine is to provide a WINXX environment on top of x86 platforms. If M$ was sued into oblivion tomorrow, and Wine was a *perfect* 95/98/ME/XP emulator, there would be no need for future development (other than to port to new platforms). The point is that the end goal is to attempt to be the perfect emulator for the USER - not to keep wine going indefinitely.
Some may say yes, others (e.g. Microsoft) may say no. I submit that we that this goal as axiomatic and we go from there.
Now, I can argue that this very axiom eliminates any sort of proprietary licence, but I will not do it since it's understood by everybody here. I will just look at the two possible options: BSD vs. LGPL. There are two points in my axiom:
- we should try to make Wine stronger (e.g. evolve faster)
- Wine should have a life of it's own
Let's look at the first part: make Wine evolve faster. LGPL pros: -- _far_ bigger code base for sharing/reuse
and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL.
-- _far_ bigger developer base
Can you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD?
-cons: -- we may lose developers that are opposed philosophically to the GPL ideals -- less commercial freedom when using the code base
Setting philosophy aside, there are many companies that will not touch *anything* with the letters GPL in it, due to what is perceived (rightly or wrongly) to be its consequences. It is not an overstatement to say that *GPL is a net discouragement to commercial development - the GPL and FSF are openly hostile to proprietary software - PERIOD. Anyone who claims otherwise must also believe that M$ is "encouraging innovation".
I can also add a few more cons: -- FSF discourages use of LGPL -- Discourages commercial companies for its use/development. -- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL.
BSD (just negate the above)
And now for the second part: Wine should have a life of its own. This is, to my mind, the crucial part. The problem with a BSD licence is that it does not ensure that.
and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying.
The cool and amazing thing about the (L)GPL is that it puts in place the right feedback loop (or vicious circle if you will) that ensures a project a life of its own independent of who's developing and maintaining it: the bigger the project becomes, the more people will use it, (up to now BSD and GPL are the same), the more people will contribute to it, the bigger the project becomes!!! It's the equivalent for the 'rich get richer', but the currency is not money but usefulness/code. It is simple, yet brilliant.
This is an artifact of "open software". GPL is a *part* of open software - it is not the definition of open software. I don't believe anyone here is advocating making wine non-open.
The problem wine has is that it is not a small endeavor like most GPLed software. If you look at the larger projects (gcc, gdb, openoffice, apache, x11, mozilla..), you will find the ones that are most successful long term are the ones with active corporate involvement. With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free".
As a side question, what IS the difference between what's available on winehq vs codeweavers?
On Sat, 15 Dec 2001, Roger Fujii wrote:
"Dimitrie O. Paun" dimi@cs.toronto.edu wrote:
I feel rather dismayed by the whole discussion.
Maybe this is so because the way you approached the issue. See, you are concerned with the semantics of things, the 'why',
I think the better question is "what" as in what is trying to be accomplished?
That's exactly what I was saying. We should not concern ourselves with other people's agendas (or their 'why'). We should just look at the 'what'. And in our case, I claim the 'what' is simply to chose a licence that maximizes Wine's development.
If we agree up to this point, what is the 'syntax' I was referring to? Well, IMO this is a stronger Wine that keeps evolving and that has a life of its own. Wether this is good or not for users it's irrelevant.
You probably meant something other than what you wrote here. Existence for the sake of existence is useless.
No, I meant what I said. By 'syntax' I was referring to the 'what'.
I would presume the point of wine is to provide a WINXX environment on top of x86 platforms.
True, but that was not the point of the discussion. We weren't debating what Wine should do, we where debating what licence we should choose for Wine. I thought that was a well understood point in this thread.
Let's look at the first part: make Wine evolve faster. LGPL pros: -- _far_ bigger code base for sharing/reuse
and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL.
Yes, one way. BSD-style code can be used in (L)GPL code, not the other way around. So, in our case, other (L)GPL projects could use Wine code, but Wine (with the current licence) can not make use of code from (L)GPLed projects.
-- _far_ bigger developer baseCan you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD?
Yes. I'm certain of this. Most open source developers prefer the (L)GPL to the BSD licence. Let's look at SourceForge (today, 20:05 EST): OSI Approved: 19939 GPL: 14507 LGPL: 2016 BSD: 1331 Artistic: 608 Mozilla: 309 MIT: 301 Apache: 179 Propriatary: 449 Public Domain: 622
-cons: -- we may lose developers that are opposed philosophically to the GPL ideals -- less commercial freedom when using the code base
Setting philosophy aside, there are many companies that will not touch *anything* with the letters GPL in it, due to what is perceived (rightly or wrongly) to be its consequences.
GPL is one thing, LGPL is another.
It is not an overstatement to say that *GPL is a net discouragement to commercial development - the GPL and FSF are openly hostile to proprietary software - PERIOD. Anyone who claims otherwise must also believe that M$ is "encouraging innovation".
Again, there is a huge difference between GPL and LGPL. GPL is not even an option for Wine, so let's not talk about it.
I can also add a few more cons: -- FSF discourages use of LGPL
I don't care what FSF does, or its political agenda. This is the very 'why' I want so much to avoid. However, not even the FSF would suggest GPL for Wine, due to its nature. Remember, FSF's own glibc is LGPL for crying out loud!
-- Discourages commercial companies for its use/development.
It does not. This is all misconception, and people will learn. If they don't and the code is useful, someone who understands that will make a succesful business out of it, and people will learn the hard way.
-- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL.
Quite the contrary -- LGPL add _stability_ which should help businesses long term.
And now for the second part: Wine should have a life of its own. This is, to my mind, the crucial part. The problem with a BSD licence is that it does not ensure that.
and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying.
I am quite aware that there are successful BSD-licenced project. But it is my firm believe that in the long term, the (L)GPL creates the right framework to give a project a life of its own. Right now it's hard to say, because most projects are still maintained/developed by their creators, we don't know how things will evolve in 15-20 years and beyond. But from a business point of view, it is quite important that you can 'predict' a little the future long term, and the LGPL gives you _much_ better means than the BSD licence.
The problem wine has is that it is not a small endeavor like most GPLed software. If you look at the larger projects (gcc, gdb, openoffice, apache, x11, mozilla..), you will find the ones that are most successful long term are the ones with active corporate involvement. With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free".
Certainly availability is very important. But not at all costs. If so, just use MS Windows, it's here today, and works a hell of a lot better than Wine does (or even hopes of working in the near term).
-- Dimi.
"Dimitrie O. Paun" wrote:
If we agree up to this point, what is the 'syntax' I was referring to? Well, IMO this is a stronger Wine that keeps evolving and that has a life of its own. Wether this is good or not for users it's irrelevant.
You probably meant something other than what you wrote here. Existence for the sake of existence is useless.
No, I meant what I said. By 'syntax' I was referring to the 'what'.
Your statement implies that wine should do whatever it takes to remain alive ( go propriatary, emulate mac finder...) which is not what I think you meant.
I would presume the point of wine is to provide a WINXX environment on top of x86 platforms.
True, but that was not the point of the discussion. We weren't debating what Wine should do, we where debating what licence we should choose for Wine. I thought that was a well understood point in this thread.
But is it? If what I said was paramount, one wouldn't hesitate to choose a (complete wine + proprietary libs) over (incomplete wine that's nonproprietary). Now, I will agree that a complete wine that's free is preferable, but is this realistic? It seems to me the argument here is whether to maximize the free software base, or of maximizing the complete sw combo.
Let's look at the first part: make Wine evolve faster. LGPL pros: -- _far_ bigger code base for sharing/reuse
and how to do arrive at this? the modified BSD license is professed by FSF to be compatible with the GPL.
Yes, one way. BSD-style code can be used in (L)GPL code, not the other way around. So, in our case, other (L)GPL projects could use Wine code, but Wine (with the current licence) can not make use of code from (L)GPLed projects.
ok... get what you were trying to say now. Though one could use LGPLed stuff if it is in library form (obviously). Wouldn't think this is much of an issue though - is there a lot that can be taken from somewhere else? And one could always ask for an exemption....
-- _far_ bigger developer baseCan you actually say for certain that the gain of developers by using LGPL is less than the loss of developers by using BSD?
Yes. I'm certain of this. Most open source developers prefer the (L)GPL to the BSD licence. Let's look at SourceForge (today, 20:05 EST): OSI Approved: 19939 GPL: 14507 LGPL: 2016 BSD: 1331 Artistic: 608 Mozilla: 309 MIT: 301 Apache: 179 Propriatary: 449 Public Domain: 622
All this says is that on sourceforge, the number of GPLed apps is larger than any other license. Just because I like X11/BSD, doesn't mean I don't contribute to GPLed projects. Yes, there are some people that only do GPL stuff, just as there are some people that don't/can't. How does one quantify this ratio?
GPL is one thing, LGPL is another.
I know that. You know that. Managers may or may not know that. Plus, there are various parts of LGPL that are quite fuzzy, which never builds confidence in the legal realm. I've had this argument happen to me a couple of times in different companies. And given that they like to choose the SAFER thing to do, we know what got axed.
I can also add a few more cons: -- FSF discourages use of LGPL
I don't care what FSF does, or its political agenda. This is the very 'why' I want so much to avoid. However, not even the FSF would suggest GPL for Wine, due to its nature. Remember, FSF's own glibc is LGPL for crying out loud!
yes, but what FSF does influences how people perceive what the *GPL means. As for LGPL glibc, see: http://www.topology.org/linux/gpl.html. It's stuff like this that give commercial companies the willies....
-- Adds more confusion to the mix - LGPL ramifications is less understood than the GPL.Quite the contrary -- LGPL add _stability_ which should help businesses long term.
Statements like (From LGPL):
When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.
is anything but stable.
And now for the second part: Wine should have a life of its own. This is, to my mind, the crucial part. The problem with a BSD licence is that it does not ensure that.
and how do you arrive at this conclusion? I would say that apache, X11, BSD would disprove what you are saying.
I am quite aware that there are successful BSD-licenced project. But it is my firm believe that in the long term, the (L)GPL creates the right framework to give a project a life of its own. Right now it's hard to say, because most projects are still maintained/developed by their creators, we don't know how things will evolve in 15-20 years and beyond.
X11 is ancient. BSD is ancient. Both have been relatively active in their lifetime. Contrast that with GNU projects of that same duration (gnuemacs, gcc) and you will see that there were bigger dead times with those projects than their non-gnu counterparts. My problem with LGPL in Wine's case is that it (LGPL) has a pretty dated notion of linking/executable. Let say for speeds sake that wine created a mmaped file which is an 'image' of a running windoze executable's address space. What this core image is (is it now a derived work?) is really unclear. As technology gets more sophisticated, this whole notion of executable/libraries is going to go away, and it seems to me that having a license based on a concept of "library" is not too forward seeing.
But from a business point of view, it is quite important that you can 'predict' a little the future long term, and the LGPL gives you _much_ better means than the BSD licence.
This can be answered off-line, but I'm curious how you come to this conclusion. If anything, I would presume just the opposite.
With this in mind, I think wine is better served by having its use proliferate and being more complete (even at the expense of having propriatary extensions), than having something that is incomplete but "free".
Certainly availability is very important. But not at all costs. If so, just use MS Windows, it's here today, and works a hell of a lot better than Wine does (or even hopes of working in the near term).
But I don't want to run an os that crashes on me every chance it gets. Realistically Wine's *real* problem has very little to do with the licensing, but its competitors. Programs like vmware and plex86 lessens the need for something like wine, especially since wine is so far from being complete. I doubt that wine will ever be as good as the the virtual cpus, but this may not be an option for some....
Dan Kegel dank@kegel.com wrote: Could it be as simple as the wine cvs tree accepting LGPL'd contributions along with old-license contributions?
Not if you want a "pure" LGPL distribution.
False. See above.
what I meant by "pure" is that it can ONLY be licensed as LGPL. Since the original source was BSD, portions will always be BSD. AFAIK, the current LICENSE file must still be included.
Or need one go so far as requiring all new contributions to the cvs tree be under the LGPL?
even further.
False. People can continue to submit code that's BSD-licenced. It will turn LGPL the moment it's applied to the tree.
I don't think "distribute under LGPL" is the same as "changing the source license to LGPL". Only the copyright holder can replace the header, as the original permission for the copyright requires the original header to be there. I don't see how you can exclude the current LICENSE file without agreement from the copyright holders, as your ability to use the source is contingent on that file being there.
Remember: any BSD-lincenced code can be used in LGPLed code, but not the other way around. If BSD-lincenced code is used in LGPLed code, it becomes LGPLed automatically, by the magic of the LGPL.
compatible with != IS. If what you are saying is correct, then there is nothing stopping FSF from commendeering all BSD software, slapping GPL on it, and releasing that distribution.
-r
Roger Fujii wrote: Let's look at SourceForge (today, 20:05 EST):
OSI Approved: 19939 GPL: 14507 LGPL: 2016 BSD: 1331 Artistic: 608 Mozilla: 309 MIT: 301 Apache: 179 Propriatary: 449 Public Domain: 622
This is realy interesting table. I thought that SourceForge hosts "open_source" projects __only__ but I see 449 proprietary packages as well.
Their Mission Statement reads:
SourceForge.net's mission is to enrich the Open Source community by providing a centralized place for Open Source Developers to control and manage Open Source Software Development.
just my 0.02 euro
Igor
it's like freshmeat - the use one catagory to define 'other' licences: Other/Proprietory.
Before they will approve a account creation request, they first look at the license.. it must still be open-source. Proprietory in SourceForge terms doesn't mean closed-source :)
- Ender
This is realy interesting table. I thought that SourceForge hosts "open_source" projects __only__ but I see 449 proprietary packages as well.
Their Mission Statement reads:
SourceForge.net's mission is to enrich the Open Source community by providing a centralized place for Open Source Developers to control and manage Open Source Software Development.
just my 0.02 euro
Igor
-
Dimitrie O. Paun -
Igor -
J.Brown (Ender/Amigo) -
Roger Fujii