Slashdot Mirror
Wine Continues To Move Towards License Change
uhmmmm writes "The Wine developer's votes are in. Wine will change license, as was suggested would happen, but it's not yet decided to what exactly. Alexandre notes 'We now have to decide the implementation details, like the exact
license used, whether to require copyright assignments, etc.'"
Hi there,
:
I'm in favour of a change in the Wine license that allows to
- Keep the Seurce Code Open
- Let any software company to use it with their products in a way that WineHQ and the SoftwareCompany both beneffit from it.
Wine, everyday a little bit close to implement all of the Win32 function calls, is seen as a very good oportunity for software makers. But...
(Yes, I know, it's not the best thing. I love to see Linux native software only mysef. But if this new license allows a company to have a "Linux Version", IMHO this is a Good Thing for Linux.. Others have done it already: MusicMatch, Kylix 1.0 come to my mind.),
But, of course, the terms "GPL", and "Open Source" are a heavy obstacle (but untrue) for companies interested in making money in any platform. Specially when they associate GPL and OpenSource with and "Viral License".
Yes, there's Microsoft's FUD (remember Ballmer about "Linux as Cancer" and the likes?), lot of mis-information or simply plain lack of knowledge. And this can (is) prevent(ing) many companies to offer "Linux Versions" of their products. Quicken anyone? Children games? Stationary-making programs? software that comes with your hardware?.
So, with WINE offering a new license that allows a for-proffit company to sell Linux-products is good for Linux. With Wine offering a new license that is at the same time Open and usable by SoftwareMaker Inc. is a goog thing.
Hell, maybe they will even supply (paid) developers to the Wine project!
Those are my thoughts. What do you thing? Why I am right? why I am wrong? I am very interested in the Wine project. And I will read this discussion.
All the best.
You _think_ it's the best. I disagree. The pro-corporate BSD license allows closing of the source, which means less rights for the user. The GPL doesn't have that problem.
BSD is not the licence to obsolete all others. the future is dual licencing, IMO.
//rdj (you don't think I'd claim that extra mod-point, do you?)
No one can understand the truth until he drinks of coffee's frothy goodness.
--Sheikh Abd-Al-Kadir, 1587
Not to mention it was specifically stated that they didn't want to use the BSD style license as they felt it was hurting the project. Wow. What a concept. People believe that the BSD license may be hurting their efforts. Last I read, they wanted to use a license which prevented these entities from taking the WINE project and not contributing back to it. Doesn't sounds like they want to be very BSD to me. In fact, sounds like the BSD concept is the root of the desired license change.
Get over it. A license is a license. Just because you may or may not have a personal opinion on a license one way or another doesn't mean the rest of the world will share your opinion. In fact, it seems the Wine team feels poorly about using a BSD style license. Go figure.
Lastly, GPL does not have negative connotations unless you've been feeding at the Microsoft camp lately. The concept behind GPL code is simple. Either you get it or you don't. Either you want to contribute back or you don't. There is nothing negative about it other than they simply don't want you stealing other people's efforts unless you're going to return your efforts for the good of all. So basically you are saying that companies don't like GPL code because they can't legally steal it? Sounds like an ethics check is in order.
Not trying to be a troll...hear me out.
I've been mulling over the GPL and BSD licenses for some time, trying to think of a way that businesses can make money while the community still benefits. (Isn't everybody?) So where does this come together?
Perhaps the scientists have the right idea. There's currently a strong leaning in the scientific community about the free release of journaled articles six months after publication. The journal gets to make money, but the research makes it into the public domain after a short time period.
Perhaps the approach that WINE can take would be for contributions to go GPL after a certain time period, say, six months or a year. A business can make money during that time, but as commercial systems become 'abandonware' after a period of time, the code can return to the community. Licensees could always choose to forego the time delay, publishing immediately.
What do others think? Is this a good balancing point? It just occurred to me that this is what ID has been doing with Doom and Quake.
"It remains to be seen if the human brain is powerful enough to solve the problems it has created." Dr. Richard Wallace
Alexandre posted the results of his survey to the Winedev newsgroup this morning (in my timezone).
Of people who expressed an opinion and who had contributed code, the results were roughly 2 to 1 in favor of moving to the LGPL.
Of people who expressed an opinion and who had NOT contributed code, the numbers were more favorable to remaining with the X11 style license.
<opinion source="me">
People who code prefer LGPL, people who bitch don't.
</opinion>
www.eFax.com are spammers
From reading the archive, I think Jeremy White was making another point. The problem is not so much that TransGaming is not sharing code. The problem is that everybody knows that they are doing a lot of heavy lifting to make games work. JW says that prior to TransGaming entering the field, the bulk of contributions to WINE were game related. Since no one wants to duplicate TransGaming's work, non TransGaming DirectX contributions have dropped off to almost nothing. He also mentioned that one developer spent three weeks duplicating some InstallShield functionality that CodeWeavers developed. Basically, proprietary companies are being seen by developers at large as "owning" particular segments of Wine development. In short, JW is worried about an ongoing brain-drain.
There is another problem. He says that he and other core developers are often hired to implement spot bits of functionality that allow particular applications to be ported to *nix. The current licence encourages the clients to want to own the for hire work even though it is the end result (the application can be sold on *nix.) that is important and not a few snippets of code to WINE. If WINE were LGPLed, WINE developers would still be hired to assist with application porting but they wouldn't waste their time on work that doesn't advance the overall effort. This bears some explicit pointing out for would be trolls. The LGPL means that the ported applications remain the property of the clients yet would allow the changes to WINE to go back into the main tree. JW wants a clear set of rules so clients know before the fact what belongs to the project and what belongs to them.
The Wine project might be well served by imitating Sleepycat and their dual-licensing model for Berkeley DB.
Berkeley DB started as a small embedded database library which only supported hash tables and btrees. Since it was written for BSD Unix as a replacement, it was released under the BSD license. After a few years, it was widely used, but it still only offered access methods. When Netscape wanted more features, such as transactions, disaster recovery and multiple-user support, Sleepycat Software was founded to further develop Berkeley DB (on the strength of a licensing deal with Netscape).
The new version of the software was released under the Sleepycat license, an OSI-approved license which allows Open Source applications to use Berkeley DB, but (unlike the GPL) appears to be compatible with any Open Source license. For proprietary applications, Sleepycat offers a more traditional licensing option to companies who don't wish to distribute their source code. Revenue from such licensing funds additional development of Berkeley DB, to the benefit of all. (For example, Berkeley DB 4.x adds replication and high-availability functionality that surely would not exist without the funding received through this dual licensing.)
Perhaps the Wine project should follow this example? Wine could be placed under a license like Sleepycat's, which would allow Wine to be freely used by Open Source projects (whether GPL or not), and proprietary companies could pay for a license which allows proprietary use. Funding from such licensing could be used to further develop Wine, to the benefit of proprietary and Open Source users alike.
BSD or LGPL licensing allows proprietary companies to profit from the hard work of the Open Source developers without giving anything back. Sleepycat's licensing model forces them to give something back, either by contributing more Open Source code back to the community, or by paying cash for the privilege of avoiding that -- which could then be used to fund development that would benefit the Open Source community.
It's a win-win situation, and it would ensure that contributors don't get exploited. It could also lead to funding that might greatly accelerate the development of Wine, even more than relying on companies like Corel to contribute back changes they've made to the codebase.
I'm not a contributor to Wine, but I'd suggest they consider following Sleepycat's example -- it appears to work well for them, why not for Wine?
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay