Skip to main content

Topic: TAK - Source code release and conversion (Read 23927 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • kwanbis
  • [*][*][*][*][*]
  • Developer (Donating)
TAK - Source code release and conversion
Reply #25
What, in God's name, are you talking about?

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

Then WINE changed to GPL.

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

Why not?

  • rjamorim
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #26
they took all that was made with WINE, and created a closed source derivative.

Then WINE changed to GPL.


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.

2 - 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.

3 - To this day, they still contribute lots of code back to Wine.

Quote
Why not?


Corporate mindset. Go figure it out.
  • Last Edit: 30 January, 2007, 05:00:27 PM by rjamorim
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • kwanbis
  • [*][*][*][*][*]
  • Developer (Donating)
TAK - Source code release and conversion
Reply #27
Dude, you have no clue whatsoever.

i probably have too many things on my head ...

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.

sorry, i mean LGPL (i was asking for LGPL, remember?).

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.

i actually thought it was a problem with codeweavers ... but no ... anyway, the important thing, is that a company like codeweavers, was worried about the MIT (per your comments) type license, and wanted the LGPL, to protect WINE and themselves .... here is an open letter:

Jeremy White, the CEO of CodeWeavers, a major contributor to the WINE project, has put forward a strong proposal that the license of WINE be changed from its currently BSD-style terms to a GPL or LGPL ("xGPL") license instead. The change, if implemented, would ensure that all enhancements or extensions made to WINE by any individual or company would be available to benefit the WINE project. With the proposed new license, if you start from WINE source and modify or enhance what you get, you must make what you have done available to the WINE project -- which is a fundamental principle of the GNU General Public License (GPL) under which the Linux kernel is released. White says his motivation is to prevent companies from taking WINE and turning it into a closed, proprietary product, which is permitted by the current BSD-style license.

Here is Jeremy White's open letter to the WINE community . . .

Quote
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

  • rjamorim
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #28
Ok, I see you still have very little clue of what is going on. Let me explain:

1 - Wine was released under the MIT license

2 - Transgaming took the sources and made Cedega

3 - People at wine/CodeWeavers freaked out and moved on to the LGPL

4 - Neverthless, Transgaming contributed lots of code back to wine, making the hysteria at the CodeWeavers camp a moot point.


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.

I think you can imagine Xiph considered all that when choosing their license of choice. Still, they went with BSD instead of LGPL. Can you guess why?
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK - Source code release and conversion
Reply #29
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.

Only a first guess, because i have to learn far more about those licenses (when it's time, not now) before making my choice.

Possibly i will use different licences for the encoding and decoding part:

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.

  • rjamorim
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #30
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.


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

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)

Oh, and all legal disputes about the license must happen in Oslo


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.

There will be no protection against people appropriating your ideas (as we discussed before) and the crediting guarantee will be pretty much the same as if you used BSD.
  • Last Edit: 31 January, 2007, 10:03:40 AM by rjamorim
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • kwanbis
  • [*][*][*][*][*]
  • Developer (Donating)
TAK - Source code release and conversion
Reply #31
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.

  • TBeck
  • [*][*][*][*][*]
  • Developer
TAK - Source code release and conversion
Reply #32
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."

Exactly. My text was meant as an addition to this important point.

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 fact, that i never heard about an important QPL project, possibly should tell me something (besides me beeing ingnorant)...

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.

Ok, probably BSD is a good option for the encoder too.
  • Last Edit: 31 January, 2007, 10:21:47 AM by TBeck

  • rjamorim
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #33

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.


 

whatever


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


Qt. Is the only one. And it is dual-licensed under the GPL too.

Another thing I was thinking about the QPL: it would be a dumb choice, because some specific cases will actually require the encoder to be modified and compatibility broken. David Bryant mentioned situations where a developer had to break wavpack in clever ways to fit his needs (and it was OK, because the resulting files weren't meant to be played on winamp or decoded with official wvunpack). Keeping people from distributing these modified encoders wouldn't be very nice...

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


I agree. The GPL won't give you much more protection than the BSD, and could actually hamper the format's popularity.
  • Last Edit: 31 January, 2007, 10:30:39 AM by rjamorim
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • Shade[ST]
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #34
@Tom : You might want to check out www.sosinvention.com

  • rjamorim
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #35
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?
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

TAK - Source code release and conversion
Reply #36
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?

looks like it

but apparently it's reputable

i wouldn't use it.
err... i'm not using windows any more ;)

  • rjamorim
  • [*][*][*][*][*]
TAK - Source code release and conversion
Reply #37
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!
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org

  • bhoar
  • [*][*][*][*][*]
  • Members (Donating)
TAK - Source code release and conversion
Reply #38
Some thoughts:

On forking:  it is probably best to investigate both Trademarking of the name (if not already trademarked...) as well as licenses that cover forking rules, such as the the license used for truecrypt:  < http://www.truecrypt.org/license.php >.  That license makes it clear that modifications/forks *cannot* use the truecrypt name.  The reasoning for that has to do more with security/trust issues in this case, but I thought it should be noted here.

On choice of license:  I will reiterate that if you own all of the code, and you ensure that you never incorporate code owned by others, you can bi- or tri- license your code.  BSD (or the stronger GPL) releases to prevent thankless incorporation into closed source products (or any at all), plus private licenses of the same code to hardware people.  My point is that you don't have to worry about scaring away hardware companies by your choice of public-release license, as they can always negotiate with you for a direct license.

Note: the truecrypt example may not compatible with public/private license examples given, of course.

-brendan
  • Last Edit: 01 February, 2007, 12:02:54 PM by bhoar
Hacking CD Robots & Autoloaders: http://hyperdiscs.pbwiki.com/

TAK - Source code release and conversion
Reply #39
IMO, the more restrictive you want to be with your code, the less point there is to open source it. If you want protection from all that, well, keep your source :-)

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!

I've seen it mentioned on a few forums with following discussion, but I  couldn't give a direct source, sorry...
err... i'm not using windows any more ;)