TBeck, when you release the public beta, will you please share its source code?
I'd love to play with TAK's technology, but Windows is only one of several OSes I use, so a portable codec would be much more useful. Even if the source is big and complex, I'd like to see it, and maybe get started rewriting it in C.
Thanks!
TBeck, when you release the public beta, will you please share its source code?
No.
When i release the source code it has to be in a form usable as a reference:
1) Written in C.
2) Clean.
3) Well documented.
Otherwise it would only hurt TAK's reputation.
All this will be very much work and i will do it step by step. I can not tell you a release date now.
Thomas
Thomas,
Getting the source code into such a form is exactly what I'm interested in. Are you willing to accept help?
Getting the source code into such a form is exactly what I'm interested in. Are you willing to accept help?
Yes, but later...
I will ask for help, when i myself have written a reference codec. Then other coders shall look for failures, especially for portability issues.
I am convinced, that i have to write the reference codec, because
1) i want to deceide, how fast it goes. My time for working on Tak is limited. I don't want to be under external pressure. I would have to explain too much because of the lack of documentation.
2) i have to check the code written by others. I really don't want to do this with the whole codec.
3) it's my baby! I have to take care for it.
4) I definitely will not release the source code, before i have written a paper about the codec.
When the time has come, i will happily accept your help!
Thomas
why do you spend so much time on fixing all bugs, if you plan to rewrite the whole thing?
why do you spend so much time on fixing all bugs, if you plan to rewrite the whole thing?
Do you want to say, that you would wait with testing and bug removal until the whole software is done?
I myself am always testing any module when it is new or i have modified it. I really don't know how to make some non trivial software without continous testing and debugging. But possibly others can do.
I don't plan to rewrite the whole software. I will translate it to another language that isn't too different from the current one. This should be much easier if the current version is clean.
Surely the translation will introduce new bugs. But that's no reason for not to remove design errors of the current version.
BTW: There haven't been many bugs in the evaluation and alpha releases... I have found most of the bugs through my continous internal testing.
I don't plan to rewrite the whole software. I will translate it to another language that isn't too different from the current one. This should be much easier if the current version is clean.
Sure, it's easier, but not an easy task, if you ask me.
But as it seems time is not the most important factor for you.
Still waiting for something to play with
Although the question might have been answered before in the alpha/beta testing threads, I guess this is the right thread to have it included as well for reference:
Thomas, do you already know which software license you will use for the codec?
Although the question might have been answered before in the alpha/beta testing threads, I guess this is the right thread to have it included as well for reference:
Thomas, do you already know which software license you will use for the codec?
When i release the source code i want it to be used by others. I will choose a license which makes this easy. Probably GNU. But i have to admit, that i don't know too much about the differences of open source licenses. I will deal with this when the source code is ready.
And it will take some time until the source code is ready. Reasons:
1) The codec source is far more complex than for instance FLAC.
2) It has to be translated from Delphi to C.
3) It has to be cleaned up.
Development of the codec started in 1997. I had no plans to publish it, i only wanted to evaluate, what improvements of commonly used lpc technologies are possibly. Therefore the source was made to perform thoses evaluations and not with a later publication in mind.
Currently i am working on more features for the binary releases to make TAK useful. One could say, it would be better to first build a cleaner code base. Well, i have thought about this, but came to the conclusion that 9 month since my first announcements at hydrogen were really enough. It was time for a working public release.
I wouldn't expect a source code release within the next 6 month. First i will perform a clean up of the existing (Delphi) source code and this will possibly be done stepwise and simultaneously to the addition of more features to the binary releases. Then i will translate the cleaned source to C.
This is much work and unfortunately no fun. Therefore no promises regarding a release date for the source code.
When i release the source code i want it to be used by others. I will choose a license which makes this easy. Probably GNU. But i have to admit, that i don't know too much about the differences of open source licenses. I will deal with this when the source code is ready.
Highly recommended:
O'Reilly - Understanding Open Source and Free Software Licensing
I can also help you with your questions and the like.
If you go with BSD, it'll make it somewhat more likely for TAK to get hardware support, since basically anything can implement it, closed source or not. I'm not too well versed on licenses though.
When i release the source code i want it to be used by others. I will choose a license which makes this easy. Probably GNU. But i have to admit, that i don't know too much about the differences of open source licenses. I will deal with this when the source code is ready.
Highly recommended:
O'Reilly - Understanding Open Source and Free Software Licensing
I can also help you with your questions and the like.
Thanks! It's highly probable that i will ask you.
When it's time... I am not too good in doing many different things simultaneously. Therefore i don't deal with the licensing details now.
@Thomas: Why convert the source code to C? If it's Pascal then let it be in Pascal. If you decide to later release the source code, let other people try convert it to C.
Besides, Pascal is now also cross-platform thanks to FreePascal.
Just keep in mind that, as the copyright owner, you can release it in as many licenses as you want.
Scenario: perhaps a GPL license for general release plus, should DAP manufacturers come a-callin' who dislike the GPL, a proprietary license for them (or perhaps BSD?) on a fee schedule (perhaps with bonus 'integer-math-only' support). If you go that route, you'd need to ensure you never use other contributors' code in the non-GPL fork or, alternately, only accept contributions to your fork that also include a copyright transfer to yourself.
But, this is all for later, of course.
-brendan
bhoar is right on the money: for purposes of comparison, consider that FLAC is licensed under both the (L)GPL and a BSD license, which might explain (besides its quick decode speed) why it's gained the most traction in the hardware market compared to other lossless codecs.
I've been waiting with bated breath for TAK, though as a Linux user I realize that I have some time to wait now. But I'm excited nonetheless.
Thomas, is the source code release dependant on your publishing a paper about your technology? How advanced are you with that? Or will the source code release be your "previous works" insurance?
Thomas, is the source code release dependant on your publishing a paper about your technology?
Yes.
How advanced are you with that?
I am spending any free time on improving TAK. Before the release of a (decoding) SDK and a WinAmp plugin i definitely will not work on a paper.
Or will the source code release be your "previous works" insurance?
Does this mean "source code release as protection of my ideas"? I think so.
Protection would be very important for me. It would break my heart (here i can get really pathetic...), if someone would steal my ideas.
But i doubt, that a source code release would mean much protection, before TAK has become a bit popular.
BTW: Here is a link to the TAK Faq (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=52276&view=findpost&p=467944).
Probably no new info for you, but i think, it's a good idea to put some links to it into the TAK threads.
Protection would be very important for me. It would break my heart (here i can get really pathetic...), if someone would steal my ideas.
Releasing source code will never protect your ideas, no matter what license you choose for your codec. Quite the opposite, source code would make your ideas much more "stealable".
There are only two ways to protect your ideas currently: trade secrets (that is, no source code release) or patenting.
Releasing source code will never protect your ideas, no matter what license you choose for your codec. Quite the opposite, source code would make your ideas much more "stealable".
There are only two ways to protect your ideas currently: trade secrets (that is, no source code release) or patenting.
Yes.
But what i want is:
If my ideas are good, i want to get the reputation for them.
No problem with others using my ideas, if this is guaranteed (at least for some time).
Thomas
No problem with others using my ideas, if this is guaranteed (at least for some time).
The only way to guarantee that is, again, patents. In that case, your licensing terms could be simply "credit me" instead of "give me cash".
Software licences can't do that because they protect your copyright (your code), not your ideas.
No problem with others using my ideas, if this is guaranteed (at least for some time).
The only way to guarantee that is, again, patents. In that case, your licensing terms could be simply "credit me" instead of "give me cash".
Software licences can't do that because they protect your copyright (your code), not your ideas.
Again i agree.
"guarantee" was misleading. My english should definitely be improved... It's difficult for me to express, what i mean.
Let's say "a fair chance".
If you go with BSD, it'll make it somewhat more likely for TAK to get hardware support, since basically anything can implement it, closed source or not. I'm not too well versed on licenses though.
i don't like BSD ... look what happened with crossover office ... i rather user LGL.
i don't like BSD ... look what happened with crossover office
What, in God's name, are you talking about?
And no, LGPL won't get TAK far with regards to hardware support.
i don't like BSD ... look what happened with crossover office ... i rather user LGL.
I don't understand you. What is the problem with crossover office?
Wine is LGPL, not BSD. And Crossover Office may be closed source, but they contribute a -lot- back to the Wine project.
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?
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.
Why not?
Corporate mindset. Go figure it out.
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 . . .
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
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?
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.
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."
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.
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.
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.
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.
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
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...
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.
@Tom : You might want to check out www.sosinvention.com
' 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?
' 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.
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!
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 (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
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...