RE: Installshield 6 (inter-proc) patches
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).
Not according to the David Elliot and I agree. Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released.
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.
:-) Of course you claim that. Even if it was a problem you probably wouldn't admit it since it might raise to price in any possible negotions with Transgaming. :-)
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.
As said above the only thing it would enforce would be file seperation so you more easily could integrate the part from Transgaming in your CrossOver product. Of course distributing it after that would violate Transgamings copyright, so you really need their permission after all. The point is LGPL wouldn't help you here.
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.
Does it? It seems you overestime any advantages of LGPL.
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.
The same question here: Are you sure you are not overestimating the protection LGPL provides?
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.
That is one of my objections as well.
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).
Side note: I am one of them.
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.
Exactly, it increases your cost of doing business.
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.
To be honest and actually say something in support of LGPL: This wouldn't be required even with a strict LGPL interpretation. You would have to provide object files for relinking but that would not be much worse than providing the binary. Reverse enginerring it will be almost as hard.
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.
Perhaps the clarifications above might make you change your mind?
The most important thing is for us to continue to have a vital and thriving Wine community.
Agreed.
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.
Well, perhaps it is because you misunderstood what the LGPL means?
(after all, they do follow on work that we did).
Not according to the David Elliot and I agree.
Ah, so the summer Andreas spent here working on InstallShield 1-5 was of no value, and the past two years that Alexandre has spent reworking the internal process and window communications infrastructure of Wine had no value, and the three weeks that Huw spent staring at hex dumps implementing Type 1 Typelibs was clearly just some insane British stiff upper lip sort of thing.
On 2001.12.15 10:40 Jeremy White wrote:
(after all, they do follow on work that we did).
Not according to the David Elliot and I agree.
Ah, so the summer Andreas spent here working on InstallShield 1-5 was of no value, and the past two years that Alexandre has spent reworking the internal process and window communications infrastructure of Wine had no value, and the three weeks that Huw spent staring at hex dumps implementing Type 1 Typelibs was clearly just some insane British stiff upper lip sort of thing.
WOAH THERE... That is /NOT/ what I said. I think even Patrick misunderstood what I was saying. First of all, my comment had nothing to do with your work on Install Sheild or any other parts of Wine not having value. Where did you get that from? On the contrary, I think the work that your company has done with Wine has been absolutely tremendous. Anyway, to get on to what I was actually talking about. Having been LGPL would have forced Transgaming to release their Installsheild fixes, at least the way that they did them. And I think that you are correct in saying that that could be very beneficial to your business. What I was saying is that /if/ they wanted to, they could write their own code as seperate binary objects and the LGPL would allow them to link it with the rest of the Wine or with the rest of specific DLLs as long as they provide a means for the end-user to relink it with a newer version of Wine. That means that if we had been LGPL and they wanted to keep Install Shield stuff proprietary then they would have had to reimplement everything or at least a good portion of what you did. However they would not have been required to have implemented the whole DLL, just the parts that they want to replace with their proprietary versions. They can also mix and match. For example, for some functions they could release a patch back to wine. But for functions which they rewrote completely they could under the LGPL distribute it binary only. This is still better than the current situation where they can do whatever the hell they want. That is all I am saying. Again, I think that this protection is very desirable and even though Patrick refers to it as very little protection, I consider it to be quite a bit of protection. I am all for the LGPL for this reason. I would /REALLY/ appreciate it if someone at TransGaming would please reply to this. The last thing the Wine project wants to do is alienate TransGaming, although they seem to be doing this themselves rather effectively. Now Lindows is a slightly different matter entirely. After reading their website last night it seemed to me as if it is one big heaping steaming pile of bullshit. At least that is what I got out of it. I am not trying to bash Lindows, but maybe they should take that as constructive criticism and actually do something other than have a website with a bunch of marketing-speak on it. I assume people working at Lindows do passively read this list, but has anyone actively posted any comments and/or patches? From the looks of it, Lindows intends to take the wine project, fix it (or put in some quick hacks) to make it run popular software, and release it as a product. No where do they say that they are going to release their modifications back to Wine. The closest thing to a statement like that is that they'll comply with all licenses which in Wine's case means jack. They also seem pretty adamant about keeping parts of their code closed-source in order to make money as a traditional software company. This is starting to smell very rotten to me, well actually, it has smelled pretty rotten for a long time but now that we are talking about licenses it does really bring up the issue. As a side note, Lindows got some bad press today from desktoplinux.com, linked to by Slashdot. Apparently I must not be the only one who read "Michael's Minutes" and thought he was full of it. I do however encourage Mr. Robertson to respond to this. And I would like to see something like Lindows succeed, it's just that it looks like a bunch of hot air right now. The article also mentions that in "Michael's Minutes" Mr. Robertson refers to a new way of distributing software and maybe that that is the key to his business. I guess only time will tell. -Dave
That means that if we had been LGPL and they wanted to keep Install Shield stuff proprietary then they would have had to reimplement everything or at least a good portion of what you did. However they would not have been required to have implemented the whole DLL, just the parts that they want to replace with their proprietary versions. They can also mix and match. For example, for some functions they could release a patch back to wine. But for functions which they rewrote completely they could under the LGPL distribute it binary only. This is still better than the current situation where they can do whatever the hell they want. That is all I am saying.
I believe, at least from a laymans perspective just having gone through 60 + messages that the above statement makes alot of sense from several angles......it seems to make sense because then what ,-everyone is 'compensated' yes ? , ie: everyone can live with it and to those that abuse it...'live with yourself' to whatever end that suits you. I am here because of 'linux' and its open-source model/comradry. I am not here to run ( no dis-respect meant whatsoever to various software models that have been mandatory for some business's ) something that requires me to install a M$ product as a workaround,- but then again I have that option not having huge requirements as a basic end-user/sm business. It is all fairly complex and I do 'not' pretend to understand all the various pro/cons but whatever is done I'd hope its in the best interest of wine/linux as without which, I'd not be as productive as I am. lee -====
Patrik Stridvall <ps(a)leissner.se> writes:
Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released.
It seems you really don't understand the LGPL. Modifications made to a library released under the LGPL are a derivative work of this library, and have to be LGPL no matter if they are in separate files or not. This is the standard interpretation that just about anybody except you agrees with. -- Alexandre Julliard julliard(a)codeweavers.com
On 2001.12.15 13:33 Alexandre Julliard wrote:
Patrik Stridvall <ps(a)leissner.se> writes:
Even according to a strict interpretation of the LGPL they would just have to provide their code in seperate files so everything could be relinked when new versions of Wine was released.
It seems you really don't understand the LGPL. Modifications made to a library released under the LGPL are a derivative work of this library, and have to be LGPL no matter if they are in separate files or not. This is the standard interpretation that just about anybody except you agrees with.
Read it again. Any modifications to existing code, yes. This is why I like the LGPL. However, if someone is reimplementing a portion from scratch they could make a successfull argument that their portion of the overall DLL was a seperate library and the LGPL /DOES/ state that you can link an LGPL library and your own library to form another library. The crypto part of ADVAPI32 was the example I used. Let's say I were to write a CryptoAPI implementation as a set of seperate source files. With the LGPL I could compile all of that stuff and refer to it as a library. What is a library? I would say one or more object files linked together form a library. I could then take my CryptoAPI library, link it with the rest of Wine's ADVAPI32 and distribute a libadvapi32.so that could be dropped into a wine install. Of course the LGPL states I would also at the very least have to provide at least binaries of my portion independently so that the end-user could take my library and link it with a newer version of Wine's ADVAPI32. This is why I think the LGPL is advantageous. Instead of being locked in to using the libadvapi32.so as distributed by me which could happen with the X11 license, with the LGPL license I must keep it in a seperate object file such that the parts of it that are LGPL can be updated. This is a Good Thing. I am honestly all for the LGPL on Wine's codebase. I disagree with Patrick saying that it offers us no protection or what he refers to as very minimal protection. I think the scenario I listed above is a very important one and illustrates exactly what the LGPL is supposed to accomplish. However, according to Patrick this is very little protection so why not keep it X11 license and thus avoid the deterrence that the LGPL might be to some people. NOTE Patrick: Consider this to be my reply to your message. The only thing we are arguing is that you consider this to be weak, while I consider it to be at least a little more protection that we currently have. At least it prevents people from taking what we have already done and forces them to reimplement if they don't want to play by the LGPL rules. Also note that I am only trying to point out, like you are, that the LGPL is not a whole lot of protection. But the little protection it does provide is very profound. I suppose if we want the definitive answer on this then someone ought to ask the FSF about it. -Dave
David Elliott <dfe(a)tgwbd.org> writes:
The crypto part of ADVAPI32 was the example I used. Let's say I were to write a CryptoAPI implementation as a set of seperate source files. With the LGPL I could compile all of that stuff and refer to it as a library. What is a library? I would say one or more object files linked together form a library. I could then take my CryptoAPI library, link it with the rest of Wine's ADVAPI32 and distribute a libadvapi32.so that could be dropped into a wine install.
If it is a completely separate library that doesn't contain portions that are derivative work of ADVAPI32, then yes you can do that. But you cannot for instance decide to reimplement CreateWindow and not release it simply by putting it into a separate file, which was what Patrik suggested; because your new CreateWindow will necessarily use internal functions and variables of USER32, and thus would be considered a derivative work. -- Alexandre Julliard julliard(a)winehq.com
On 2001.12.15 20:01 Alexandre Julliard wrote:
David Elliott <dfe(a)tgwbd.org> writes:
The crypto part of ADVAPI32 was the example I used. Let's say I were to write a CryptoAPI implementation as a set of seperate source files. With the LGPL I could compile all of that stuff and refer to it as a library. What is a library? I would say one or more object files linked together form a library. I could then take my CryptoAPI library, link it with the rest of Wine's ADVAPI32 and distribute a libadvapi32.so that could be dropped into a wine install.
If it is a completely separate library that doesn't contain portions that are derivative work of ADVAPI32, then yes you can do that. But you cannot for instance decide to reimplement CreateWindow and not release it simply by putting it into a separate file, which was what Patrik suggested; because your new CreateWindow will necessarily use internal functions and variables of USER32, and thus would be considered a derivative work.
Yes, I now realize in the mail I just sent out a few seconds ago that Patrick seemed to misunderstand me a little bit. You seem to be thinking more like I am. While I am thinking about this, there are some interesting things in the LGPL. One of these is that you can modify the LGPL library to work with your code. The catch is that you have to release source to the modifications and that the modifications must not require that your proprietary component be included. The text of the license mentions that if you modify a function that computes square roots to hook into your proprietary components that the function must still compute square roots. But in Wine's case, many functions don't do what they are supposed to do, or they do what they are supposed to do but that's not what actually needs to be done. This stuck out like a sore thumb to me, but maybe it's not such a big deal. Apparently my cryptoapi example was very clean cut. From my point of view it would only make sense that people would be allowed to make a proprietary section of a DLL as long as it was a seperate libary as specified by the LGPL. Your example is a bit more of a gray area. While I would hope that it couldn't be done, I am not seeing any language in the license preventing one from doing it. If CreateWindow were implemented from scratch as a proprietray "library" and called into functions provided by the LGPL library (Whether internal or not I would think) the LGPL would allow this. Accessing data I would think would also be allowed, again, whether internal or not I don't think makes a difference. Basically what we need to know is how much protection is offered by the LGPL and is it worth it. And by how much protection I mean after all the various interpretations of the LGPL have been brought out in court what can people get away with and what is clearly and most definitely going to be protected. -Dave
participants (6)
-
Alexandre Julliard -
Alexandre Julliard -
David Elliott -
Jeremy White -
lee -
Patrik Stridvall