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