I think that this message as well as many other bring up some very good points as to the needs of licensing within the wine project. Many other messages have been clearly in the realm of bsd-gpl feudalism. I think that trying to find a license to fit the needs of the project without first having a good understanding of the needs of the project is a serious error.
Yes, that is what I have tried to say in my reply to Jeramy.
We must define what we want to license to protect, but more importantly we must define what the we DON'T want the license to protect.
Because "What doesn't the license protect?", more popularly known as "What can we get away with?" is the first question ALL new business models will ask.
If the answer of that question is "Not Much" it might be very bad for most business module, but even worse if the answer to the question is "I don't know, it depends on your intent" or "I have no idea, the jury is still out" it will be very bad.
From my discussion with Alexandre last time he seems to believe
that whether or it was allowed to implement a few function in some DLL in a LGPL Wine by linking to a proprietary library depended on my intent. I reject this absurd idea most violently. However consider for a moment: What if he is right?
This means that with a LGPL:ed Wine: If somebody that had some proprietary library and thought hey with this library it should be quite easy to implement these functions in Wine that prevented these cool application to work. Some programming later... Great it works... Now I call Lindows, Red Hat, SuSE (whomever that distribute Wine) and tell them that I can license this library for $5 per end user to you. Some time later... Great at least some them accepted and the money keeps streaming in. Life is good.
Questions: Is his intent bad? Would you sue him for violating the LGPL? If he publish his proprietary library function wrappers under the LGPL. If he didn't? What about the Linux distributor? Under what circumstances would you sue it?
Another scenario: Joe Hacker has bought a proprietary library to use with his non Wine related hobby. One day he realizes that the one of his hobby related also proprietary Windows application he dual boots to since it never worked under Wine could be made to work by implementing the missing Wine functions with that library. He does so, it takes a weekend. It works. He puts out the patch to Wine under LGPL on a hobby related website for other that also owns the application and the library. He is happy since dual booting is but a memory. Life is good.
Questions: Is his intent bad? Will you sue him? If some months or so later the maker of the protrietary library finds the patch and contacts the Linux distribution like in the case above. Will you sue the him, the proprietary library company or the Linux distribution?
All this begs the questions: 1. Isn't it so, that as I claimed that the LGPL really doesn't protected this. 2. Or alternatively, if it really does make what some of the people above do illegal, do we REALLY want to use it?
It's pretty obvious that neither the a gpl license nor a bsd license are optimal. It only take the observation of the lack on consensus to see it.
Quite.
All that I can really offer is this suggestion: end feuding and start a process to
- Gather the requirements to the licensing of the wine project
- Determine if any combination of existing licenses can meet the
requirements 3. If no combination of existing licenses will suffice, write a license that does.
Fully agree.
Additionally, I advise that everyone abandon there preconceptions of licensing. There is no mandate that I know of to license the whole project under the same license, only use one license for any part of the project, only use existing licenses, license any part of the project to different groups under the same license.
Quite true. However, take care with viral licenses, they might spill over to the other parts all the same.
-
Patrik Stridvall