On 2002.02.09 13:52 Sean Farley wrote:
Thinking it over. I see no benefit for a change to the LGPL. The main reason was to force companies to give WINE their changes and/or additions to the code.
As several people have pointed out, they can get around this by writing API wrappers. Doing so they will have removed the only reason the LGPL was proposed in the first place. It would be quite easy to keep in sync with the WINE code base. A PERL script (or whatever) could be written to output a wrapper file. Another script could be used to make changes to any future code base to make use of the wrapper calls. As someone who did this for my last company (JAVA API using JNI calls to mirror their own C library), I can say this will take a minimal amount of work. They would only need to release the changes they made to the code (just the wrapper calls).
I don't see this as a problem. At least as a user of this companies product and a developer of Wine I could still modify the non-proprietary parts and use them with the proprietary parts instead of having to either take an all-free source/binary release or an all-proprietary binary-only release.
If you want to force the code out of others, a much stricter license than the LGPL or even the GPL will be required. Can anyone recommend one and have it still be open source?
I don't think we want to force the code out of others. Well, some people do, but that pretty much requires GPL which is not an option at all and shouldn't even be considered to remotely be an option.
Mainly what I'd like to be able to do is keep the proprietary stuff seperate from the free parts of wine. The LGPL accomplishes this and this is the LGPL's purpose, nothing more.
Of course if Lindows is nothing more than simple little one line bugfixes all over the place in Wine then LGPL would make it difficult for them. If they rewrote large portions then LGPL makes it easier for them.
-Dave