TAK - Source code release and conversion, From Topic ID: 50958 Options

[graue]

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]

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

[graue]

Thomas,

Getting the source code into such a form is exactly what I'm interested in. Are you willing to accept help?

[TBeck]

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

This post has been edited by TBeck: Jan 2 2007, 16:24

[pest]

why do you spend so much time on fixing all bugs, if you plan to rewrite the whole thing?

[TBeck]

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.

[pest]

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

[Fandango]

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?

[TBeck]

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.

[rjamorim]

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.

[Firon]

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.

This post has been edited by Firon: Jan 18 2007, 05:32

[TBeck]

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.

[pepoluan]

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

[bhoar]

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

This post has been edited by bhoar: Jan 21 2007, 01:01

[Heliologue]

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.

[jido]

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?

[TBeck]

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.

Probably no new info for you, but i think, it's a good idea to put some links to it into the TAK threads.

[rjamorim]

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.

[TBeck]

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

[rjamorim]

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.

[TBeck]

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

[kwanbis]

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.

[rjamorim]

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.

[beto]

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?

[Firon]

Wine is LGPL, not BSD. And Crossover Office may be closed source, but they contribute a -lot- back to the Wine project.

This post has been edited by Firon: Jan 30 2007, 22:07