Patrik Stridvall ps@leissner.se writes:
They might even have an implementation from scratch with no
Wine code at
all. I can see no difference between for example their DLL and a
Microsoft DLL
running under Wine, regardless of Wine being GPL or LGPL or
whatever.
There is no difference whatsoever, as long as it is not based on Wine code. We can't (and shouldn't) prevent anybody from reimplementing a dll from scratch.
My point exactly.
What we can (and should IMO) prevent is people using our own code against us.
Yes, but does the example below ...
Then we have the middle case by have say the Crypto API that is a part of ADVAPI32. Does distributing a whole file replacement of dlls/advapi32/crypt.c represent a violation of GPL or LGPL? In that case why? The Crypto API is largely independent of the rest of ADVAPI32 it could as well be a separate DLL.
... really violate the LGPL IYO (In Your Opinion)?
I really can't see why it is significant that Microsoft put the Crypto API in ADVAPI32.DLL instead of say a seperate DLL, say CRYPTO32.DLL.
Any protection that (L)GPL provides is to a large part based on myth and legend.
I think you are very mistaken here. The protection is based strictly on copyright law, and if anything is certain it is that copyright law is going to become even stronger in the coming years.
There are certainly a lot of people that _wish_ to make copyright law stronger. However even more important is a copyright law that make logical sense.
I think doctrine of derived work is one of the most serious mistakes in how copyright law today is formulated. The basic idea is a good one and I support it, but I really think it should have been formulated in term of combined works instead of derived works.
That is, if you combine your work with somebody elses work and distribute it together you must have the permission all the authors of all parts the combined work consists of.
But that is exactly what the doctrine of derived work says, you object, what is the difference?
Well, the difference is subtle. Under a strict doctrine of combined work ONLY distribution of the combined work is prohibited not providing a work that can be combined with another work to form a combined work regardless of whether this was intended or not.
Under such a doctrine, the (L)GPL doesn't make any sense (and thus have no power) if all if you only provide patches. Note that you only have to accept the (L)GPL if you distribute the (L)GPL:ed work and you don't.
The fact that end user can combine your work and the (L)GPL:ed work, perhaps using a script you wrote, perhaps not, doesn't matter att all under a strict combined work doctrine since no distribution is taking place.
The big question for the future is the doctrine of derived work really a strict doctrine of combined work?
Note that 1. This is the only thing it AFAIK has been used for in actual court cases 2. This might be the only possible constitutional interpretation of copyright law, because otherwise somebody (A) can prevent somebody else (B) from "speaking" based on what some third party (C) can used the "speech" lawfully acquired from B together with some "speech" lawfully acquired from A. Especially since what C might do is most likely not even be illegal.
In addition our situation is even easier since the dll interfaces are already defined for us; the difficulties you see are purely imaginary, I don't think there would be any technical problem applying the LGPL to Wine.
Technical problems perhaps not, but does it help? Especially given how much it might hurt.
The GPL is another story, but we clearly don't want to go there if Wine is to remain useful for running proprietary applications.
Agreed.
In addition hypocritical people at for example Slashdot also seems to wish to apply different standard at open source licenses and proprietary licenses.
So company cries that their products shouldn't be hacked (having a part replace) should be ignored despite their insistance that a paragraf of their license has been violated, while any violations of the (L)GPL doing essentialy the same thing (replacing a part) should be strictly enforced. :-)
If you don't understand the fundamental difference between the GPL and a standard EULA, I'd suggest studying the issue a bit more. And www.gnu.org is probably a better reference than Slashdot to learn about this kind of things <g>
Oh, I read both these sites and more.
Sure there is a difference, as the current law is written, but the big question does it make sense that there is a difference?
The fundamental issue is the same. 1. I am the author of some work 2. You would like to use my work in some way. 2. I'm prepared to make the work available to you under some conditions
As a side note, because of copyright as some sort of public contract not all possible conditions are enforcabled. For example first sale doctrine says I can't control what happends to a specific copy of a work once I have sold it.
But that doesn't change the fact the situations are basicly the same and I was not talking about law here rather about morality. I said hypocritical didn't I?
True, but that doesn't worry me so much, since very few non games depend of DirectX and this allows us concentrate on what is really important getting commonly used productivity applications to run under Wine.
In short, because you don't care about games Wine doesn't have to support them. I strongly disagree with this sentiment; even though I don't care much about games myself, I want Wine to be able to run them just like other applications. And again, DirectX is just one example of something that could happen with any other part of Wine.
What I mean is that, we can't have everything. We don't have the resources to do everything. We have to make priorities and people playing games are people that are unlikely to provide a lots of new developers or other resources for the core Wine project as it is organized.
Companies on the other hand wanting to run their productivity application are much more likely to provide resources developing Wine further especially after we reach the point there their normal applications run close to perfectly and they wish to make their more unusual application to run as well to be able to provide a say all Linux desktop.
Therefore I'm happy to leave things like DirectX to companies like Transgaming for the time being since people that wants to play games are more likely to be happy with the way they can support Transgaming ie paying a monthly fee.
That is true, but I still think we made the right choice. If we had made Wine LGPL we might have prevent Transgaming from entering the market and a change now might prevent others from doing so.
I don't think so; they would certainly have had to make some adjustments to the business model, but I think it is definitely possible to build a business on an LGPL code base. Of course these days building any kind of business is quite difficult, but I don't think LGPL vs. X11 is going to be the difference that makes otherwise successful businesses fail.
Using your strict interpretion of the LPGL it will significantly increase the cost of entry to the market, thus requiring higher risk of entering the market, even with a basicly sound business model.
I think it is very dangerous for us to reject the help we can get to increase the mind share of Wine and derivates as a whole, inspite of any inconviences for the core Wine project.
Wine has not yet accieved the breakthrough on the desktop market that Linux did on the server market and until then we need all the allies we can yet, regardless of their actually "loyalties".
Well, I strongly disagree. Wine is supposed to be a free implementation of Windows; if making it successful requires making it non-free, we might as well stop right now.
"He who defend everything, defends nothing"
Need I say more?
Anyway we are not going to convince each other. I take note that you are opposed to the change, even if I admit I'm a bit surprised; it seems last time we discussed licenses you were quite favorable to the LGPL.
Well, with age comes wisdom (or senility). :-)
Seriously, we made that choice we made in hope that it would be a good one and I think it is to early to say that the choice was a bad one. Changing licenses out of panic is a bad idea. Let calm down and think this through properly.
Patrik Stridvall ps@leissner.se writes:
Therefore I'm happy to leave things like DirectX to companies like Transgaming for the time being since people that wants to play games are more likely to be happy with the way they can support Transgaming ie paying a monthly fee.
Then I guess you are also happy to leave OLE support to company Foo, and networking support to company Bar, and multimedia support, common controls, etc. to yet other companies. After all, people who need these features would be happy to support these companies, right? As long as the free version of Wine runs Solitaire we don't need anything else, right? Or is it different because the applications *you* care about need these features but not DirectX?
Using your strict interpretion of the LPGL it will significantly increase the cost of entry to the market, thus requiring higher risk of entering the market, even with a basicly sound business model.
No, IMO it will lower the cost of entry, because more code will be available. So if you want to make money with Wine you won't need to first buy all the pieces you need from the various companies that hold them proprietary. Transgaming could probably never have entered the market if all the development that was done before them had not been released as free software.
Well, I strongly disagree. Wine is supposed to be a free implementation of Windows; if making it successful requires making it non-free, we might as well stop right now.
"He who defend everything, defends nothing"
Need I say more?
What do you suggest defending then? Nothing? The ability to run only your favorite application? I still don't understand your position, and I can't say you seem to really understand it yourself.
Seriously, we made that choice we made in hope that it would be a good one and I think it is to early to say that the choice was a bad one. Changing licenses out of panic is a bad idea. Let calm down and think this through properly.
There is absolutely no panic here, I've been thinking about the opportunity of such a change for months now, if not years. And in any case any change would be very gradual since it only applies to new code.
Alexandre Julliard wrote:
There is absolutely no panic here, I've been thinking about the opportunity of such a change for months now, if not years. And in any case any change would be very gradual since it only applies to new code.
I am strongly in favor of switching to LGPL at some point in the next year. It's the Right Thing to Do, and will probably increase my motivation to submit patches.
This is not a dig at Transgaming at all. They are doing good work with good intentions. Relicensing should be done on a timetable that makes sure Transgaming isn't suprised and annoyed at it somehow. - Dan
What do you suggest defending then? Nothing? The ability to run only your favorite application? I still don't understand your position, and I can't say you seem to really understand it yourself.
The key question here is whether or not switching Wine to the LGPL will, in the long run, harm or help the Wine project.
A useful thread I pull from Patrik's comments is the concern that switching to the LGPL will discourage corporate participation in Wine, and that the resulting loss of effort will end in a net loss for the Wine project.
As I've weighed this issue from CodeWeavers perspective, it strikes me that the issue is a wash - there are ways in which a shift to the LGPL would help us, and ways in which it would harm us.
It would help us in several ways. First, since we've always effectively treated the Wine code base as though it were LGPL, we would gain the protection that the LGPL offers. If someone else takes the code we've worked on, and competes with us, we would gain back any improvements that they make. For example, if Wine had been LGPL, then Transgaming would have been oblidged to release Installshield fixes back (after all, they do follow on work that we did). With better InstallShield support, for example, our CrossOver customers might have a wider range of plugins that would successfully install. This is a pretty minor problem; I can't think of a significant plugin affected by this. Further, I think I understand why Gav has has hesitated on this issue, and I firmly believe that Transgamings intentions with regards to the Wine project are honorable and good.
However, I can imagine alternate scenarios where we could have all of our hard work used against us by others who are more ruthless than Gav, and so the LGPL would at least offer us some protection from that threat.
A second benefit is simplicity. I spend a lot of time discussing license issues with my customers, and fighting very difficult battles to preserve the integrity of the Wine code base (and while that sounds noble and all bear in mind that a single, coherent source code base that I can fully use is a key part of my business strategy). So, if the license were LGPL, my negotiating requirements would be simplified. In fact, I would feel free to encourage my clients (and my company) to ruthlessly take advantage of every possible opportunity to create competitive advantages, because I feel that the LGPL would protect the integrity of Wine.
Of course, there are a number of downsides. First of all, it is possible that I would have fewer clients; the LGPL is complex license, and it's core premise can deter many people. It is widely believed in the Wine community that Corel would have never touched Wine if it had been LGPL, and Corel's contributions to Wine were very significant (the irony of course, is that AFAIK, Corel treated Wine as though it were LGPL).
Second of all, the LGPL does, oddly enough, take away some freedom on my part. Today, I have a full range of choices available to me with every product I release or help a client to build. After a switch to LGPL (and after enough time had passed for the LGPL'd pieces to be significant), I'd have to be very cirumspect every time a public release of a product was made to be certain that I had all of my licensing ducks in a row. For example, right now, we don't provide a copy of the source code contained within our CrossOver Plugin Wine tree. The only changes we have not published back into the main WineHQ tree are ones specifically required to interoperate with a Linux/Netscape plugin. The changes we made to Wine would never have been accepted by Alexandre as being good or generally useful patches, and yet they could conceivably give someone who wished to replicate our proprietary Linux plugin code a good insight into how to go about doing so. To be honest, we sweat a lot of blood and tears to learn how to do that right, and it would hurt if someone were able quickly knock off CrossOver Plugin because we were forced to show that code. On the other hand, we also had a heck of a lot of work on the Plugin code that has nothing to do with Wine, and I'd like to see someone knock that off quickly <grin>.
With all that, speaking on behalf of CodeWeavers, I would neither call for nor oppose a switch to the LGPL. Since that change would impact me and my customers somewhat slowly, I think I could make the necessary adjustments in time. The most important thing is for us to continue to have a vital and thriving Wine community.
Finally, speaking strictly on a personal basis, and with no corporate considerations whatsoever, I would welcome a change to the LGPL; I have always preferred it to BSD style licenses (and to the GPL, for that matter); with LGPL projects, I feel more certain that I know exactly where I stand and how my code will be used.
Jeremy
-
Alexandre Julliard -
Dan Kegel -
Jeremy White -
Patrik Stridvall