What, in God's name, are you talking about?

And no, LGPL won't get TAK far with regards to hardware support.

they took all that was made with WINE, and created a closed source derivative.

Then WINE changed to GPL.

Why not?

Dude, you have no clue whatsoever.

1 - Wine was never BSDish. It was first licensed under the MIT license, and later under the LGPL. It was never under the GPL either.

CodeWeavers - makers of Crossover Office - pretty much OWNS wine. They also hire the Wine project leader, Alexandre Julliard, and several other key developers. So, it's the other way around: you should be thanking CodeWeavers for releasing parts of their software under the LGPL.

Subject: Wine license change
From: Jeremy White (jwhite@codeweavers.com)
Date: Wed Feb 06 2002 - 17:54:05 EST

Folks,

Some recent events have occurred that have made me change my opinion about a Wine license change.

During my involvement in the Wine project, I have always striven to make sure that I, and my company, did what was best for the Wine project. I believe Wine's success will help to make the world a better place. To that end, often through difficult personal negotiations, I have always insured that all of my contracts require that all code changes be returned to Wine. This, in effect, treats Wine as an LGPL product.

You can argue that the flexibility granted by the Wine license has meant that I received some business I would not otherwise have had. Gav, for example, has pointed out that Corel would never have worked on Wine if not for its license. There are two ironies there - first, Corel has always been a great Wine citizen, IMO, never 'abusing' the license. Second, while we did work with Corel to help them with Wine, we never signed a contract with them. Their lawyers and I were never able to agree on a contract that we thought would sufficiently protect Wine. Fortunately for me, we were able to work with Corel without a contract, but this issue to this day creates unnecessary friction between my company and Corel.

However, with some recent events I cannot disclose, it is clear to me that the opportunity for Wine to be used in a proprietary product is too tempting and has caused some harm to the Wine project. Based on experience, I feel strongly that the potential for harm is great enough that CodeWeavers needs to take two actions. First, we would like to release all new code we develop under an LGPL style license. Second, I would like to open another call for a license change and thereby strongly add my voice to Alexandre's.

Thus, I would like to call for a change in the Wine license. I think we all agreed that the LGPL formed the basis for a good 'alternate' license strategy. Eben Moglen, the counsel for the FSF, has kindly offered to help review licensing strategies for Wine. The goal is to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine. I think it it is great that we have, in Eben, not only the leading legal scholar on free software licensing, but a great hacker to boot. I think he will clarify exactly what is possible and what is not possible with GPL style licenses and insure that the license we choose will meet our goals.

When Alexandre last brought up this issue, he was very disappointed. He felt that there was not enough support from the 'silent majority' of Wine developers for a license change. His overriding lament to me was 'No one cares'. He further felt that since a small number of major Wine contributors objected, that it was not appropriate to change the license.

I would like to ask for a more formal process. I would like each and every contributor to Wine to send Alexandre a private email with an 'Agree' or 'Disagree' opinion, so that he can more truly assess what the contributors to Wine really want. The specific question I wish to pose is as follows:

Should the Wine project switch to a license which has as its goal to attempt to secure some form of Copyleft protection for Wine while still permitting proprietary software to link and bind with Wine?

Finally, in closing, I wanted to summarize our position. We plan to release our future work under an xGPL style license, and we would like the rest of the Wine community to join us. If the bulk of the community wants to stick with the current license, then we will probably end up making a separate CVS development tree. Anyone would be free to use our work from that tree, under the xGPL-style license terms the FSF's lawyers recommend.

Thanks,

Jeremy

Anyway, the point remains that, if TBeck releases the sources under the LGPL, he won't see much hardware support, if any. CodeWeavers chose the LGPL specifically to avoid people (other than themselves) making money out of it. If that was TBeck's goal, I wouldn't expect him to be warmly welcomed by hardware makers.

1) BSD for the decoder to achieve maximum hardware playback support. It's perfectly ok if hardware bound decoders are closed source. In what important aspect could they be optimized by the developers? Specific optimizations for their hardware i suppose. And because they are hardware specific, they anyhow would be of little use for TAK's mainstream library.

2) Possibly i would prefer GPL or LGPL for the encoder part, to have the opportunity to check the compatibility of possible improvements performed by others to TAK's specification.

Erm, no. The GPL won't prevent people from creating forks (if that's what you want).

Quote from: TBeck on 2007-01-31 14:43:50

1) BSD for the decoder to achieve maximum hardware playback support. It's perfectly ok if hardware bound decoders are closed source. In what important aspect could they be optimized by the developers? Specific optimizations for their hardware i suppose. And because they are hardware specific, they anyhow would be of little use for TAK's mainstream library.

Besides that, there's the point of the corporate mindset I mentioned before. "We are going to invest time and resources on optimizing it for our platform, and if we open source the changes we make, some competitor with a similar platform will just take our work and use it freely. No thanks, we'll go with FLAC."

Quote

2) Possibly i would prefer GPL or LGPL for the encoder part, to have the opportunity to check the compatibility of possible improvements performed by others to TAK's specification.

You would need the QPL for that, but I strongly advise against it, because any project using QPL strongly stinks of being a project that will just grab improvements submitted by third parties and close them back into some non-free form.

(more specifically, you can fork software under the QPL, but you can't distribute the original QPL'd code - you must distribute your own code as patches against the original)

The way for you to guarantee compatibility is actually quite easy: determine that you are the definitive source for the TAK specification and reference implementation. If someone else wants to improve it and break compatibility, it's his problem.

The effects that GPL would have on your code would be that
1 - FLAC and WavPack wouldn't be able to benefit from your code (but maybe from your ideas, if they reimplement them) because it would taint their BSD license
2 - It would be forbidden to include it with closed source software. For instance, Winamp wouldn't be able to bundle your encoder, like they do with FLAC.

A solution to (2) would be using the LGPL instead of GPL.

Quote from: rjamorim on 2007-01-31 14:55:16

Erm, no. The GPL won't prevent people from creating forks (if that's what you want).

In practice it does, as you can include all of the fork code into yours, if you feel like.

But yes, if the fork is a "conceptual" one, i mean, you want to go one way, the forker another, it can't prevent it.

The fact, that i never heard about an important QPL project, possibly should tell me something

Ok, probably BSD is a good option for the encoder too.

' date='Jan 31 2007, 13:01' post='468403']
@Tom : You might want to check out www.sosinvention.com

Quote

' date='Jan 31 2007, 13:01' post='468403']
@Tom : You might want to check out www.sosinvention.com

Is that site some sort of scam?

but apparently it's reputable

Quote from: ...Just Elliott on 2007-01-31 21:57:10

but apparently it's reputable

Where did you find about its reputability?

I searched the web high and low for third party opinions about their services and the legality of their "solution", and came out empty-handed.

All in all, it sounds too suspicious. If it really worked, nobody would be filing patents - it's much easier and cheaper to obtain copyrights on something, and they last much longer!