Slashdot Mirror

Does this mean that if third-party users access my web site, they will be "stopped" with the typical warning that the site is secured with an unknown certificate - and make them go through the ususal steps to add it, etc?

You tell me.

In all seriousness, if you install the certificate chain properly (just follow their instructions), you're fine. They verify you, then don't charge to verify the certs that are tied to you. Makes more sense to me.

Not only do they have to not distribute ffdshow, they also have to not even tell anyone about ffdshow for fear of running afoul of the "inducement" precedent set in MPAA v. Grokster.

They can tell them about one of the free or cheap H.264 decoders you can download. All of them properly licensed so there is no legal problem. They can probably even make some money for promoting them.

Never mind - I see they do volume licensing http://corecodec.com/oem

CoreCodec for OS X...this is the best solution I can come up with now, and it sucks.

Thanks, Mr/s. AC, for the link to the thread on their forums.

(I'm not so critical of betaboy. It kind of looks to me like he just has a little trouble communicating, lacks some experience with the law and with understanding what is still, to him, technical legalese, something which is not all that uncommon among geeks, especially young geeks.

Admitted, some geeks follow the siren call down the marketing path, like the Bill & Steve Show, but this does not seem to be the case here.)

(Oh, and for those of us still puzzled by the spelling challenge, I think that "counsel's advice" seems to be what he was trying to say, whether he was talking about pro se or getting advice from his law student roommate or just trying to appear like he could afford more legal help than he can or whatever.)

Although you are an anonymous coward, I am still going to respond. Perhaps I'm feeding a troll here, but that's a risk I'm willing to take.

For the record, my name is Carlos Averett. I'm not particularly hard to find - I used to go by "cyt0plas" here and on other sites. I have anti-EULA posts going back several years.

Nuff said on "CEO" claim. And it's about as Inc. as my toosh.
The CEO, "betaboy", as you put it, is Dan Marlin. I'm sorry if his handle isn't "manly" enough for you. As for the ",Inc." part, we are incorporated. It is part of the legal name, and serves to identify that this is a legal entity, and that it is a corporation (as opposed to, for example, an LLC.)

This is a fly-by-night outfight that lies, cheats, steals, and covers it up as best he (betaboy) can.
This is a strange claim to make - our customers come by the web site, and buy our products. Our products do what they claim to do, and Do them very well. We have never refused to give a refund. If selling software is "theft", I guess we stand guilty.

As for the "fly-by-night" aspect, we have multimedia software (written by us) for PalmOS, Symbian, Linux, OS X, Windows CE/Mobile, and Windows NT2+. We run on ARM, MIPS, x86, x64. This is the result of years and years of in-house development.

Only thing is, he's an idiot that lies so much he can't keep it straight himself.
We're a company, and made up of a number of different people. Sometimes, this leads to differences of opinion and/or policy. It happens. Since I am not, for example, Dan Marlin, you shouldn't really be surprised if he says different things than me. If you really don't believe it, our "Contact US" page is at http://www.corecodec.com/contact-us.html . Heck, we can set up a conference call.

Those that uncover this are banned and forum threads deleted.
Disjointed, irrelevant, factually incorrect threads (such as this one) get deleted in our forums. A couple of Google searches show your post to be utterly false. So, don't be surprised when we delete threads like this from our forums. It's hardly some "mass censorship" on our part when we delete posts by trolls.

Webpage cites registered trademark status but nowhere is such a trademark registered.
Well, this one is bogus. Check Tess if you don't believe me. Do an advanced search for "CoreCodec". We currently hold trademarks on Matroska, CoreAVC, CoreCodec, BetaPlayer, CorePlayer, CorePhone, CoreOS, and the CoreCodec logo.

It's all a sham based on previously-done but modified open source projects.
We wrote players. The (mobile) players originally used open-source decoders, and were released as open-source. The decoders were slow.

We have some phenomenal developers, and developers (unsurprisingly) want to be paid. Good developers want to be paid well. It happens, and that's a good thing. So, we re-did the decoders, removed all the open-source code, paid all the patent fees, and put out a legal player that can be used by companies, and in products. It's more efficient than any other software product, and often faster than hardware solutions on the same device (Google "CoreAVC Benchmarks") if you don't believe me.

Some of our projects are still open-source (Matroska, for example), and we are in the process of reworking and releasing several of our internal projects (Enterprise-grade Certificate Authority) as open-source. I make no apologies for wanting to pay the developers well - they certainly earn it. This does take money, and selling software is a reasonable way to earn it.

http://www.corecodec.com/forums/index.php?topic=981.msg5780

"In the end the counsels advise on what we were to do..."

This is from a convicted liar (Beatboy). There is no "counsels". He is lying. Making it up. Read this thread to see what a fucking liar this jerk is.

I am the author of CoreAVC for Linux.
Regardless of the cause, CoreCodec and I have resolved the conflict, and CoreAVC-for-Linux should be back online soon. In addition, the patches for 1.7.0 are ready to go, and Linux users should see a nice performance improvement on Dual-core machines (compared to 1.5.0) once it is available.

In the end the counsels advise on what we were to do was out of scope (including copyright) when we looked at all the great feedback everyone has provided us. The DMCA does allow for reverese engineering for compatibilty purposes and hence in the end no matter what the 'other points' are the DMCA takedown request was wrongly sent.

Alan has been great about this and we are now working with him now on making his new version compatible with CoreAVC v1.7.

I am the author of CoreAVC for Linux.
Regardless of the cause, CoreCodec and I have resolved the conflict, and CoreAVC-for-Linux should be back online soon. In addition, the patches for 1.7.0 are ready to go, and Linux users should see a nice performance improvement on Dual-core machines (compared to 1.5.0) once it is available.

In the end the counsels advise on what we were to do was out of scope (including copyright) when we looked at all the great feedback everyone has provided us. The DMCA does allow for reverese engineering for compatibilty purposes and hence in the end no matter what the 'other points' are the DMCA takedown request was wrongly sent.

Alan has been great about this and we are now working with him now on making his new version compatible with CoreAVC v1.7.

I am the author of CoreAVC for Linux.
Regardless of the cause, CoreCodec and I have resolved the conflict, and CoreAVC-for-Linux should be back online soon. In addition, the patches for 1.7.0 are ready to go, and Linux users should see a nice performance improvement on Dual-core machines (compared to 1.5.0) once it is available.

In the end the counsels advise on what we were to do was out of scope (including copyright) when we looked at all the great feedback everyone has provided us. The DMCA does allow for reverese engineering for compatibilty purposes and hence in the end no matter what the 'other points' are the DMCA takedown request was wrongly sent.

Alan has been great about this and we are now working with him now on making his new version compatible with CoreAVC v1.7.

From the forum thread at CoreAVC discussing this, the founder of CoreAVC says "Again without going into all the details... this is mostly about reverse engineering without permission under the DMCA... by us giving Alan permission.... problem solved".

Without seeing the coreavc-for-linux code I can't say whether or not he had to reverse engineer anything about CoreAVC to get it working, but it doesn't seem like hooking up a DirectShow filter via a (relatively) standardized API would need anything like that. Since this claim was made under the DMCA, he would have had to be reverse engineering something related to copy protection. Perhaps there is some sort of product activation that had to be hacked around to get the codec working on a non-windows platform?

http://www.corecodec.com/forums/index.php?topic=981.msg5695
it looks like coreavc are looking to work with the project to get it all legal and hunky-dorey.

We normally answer complaints on the SiteTruth blog (www.sitetruth.net), but since this was posted here...

The street address,

CoreCodec, Inc.
10 Larkspur Way
Palm Coast
Florida
USA
32137

CoreCodec, Inc.
10 Larkspur Way
Palm Coast, Florida 32137
USA

As for the SSL cert, if you connect to https://www.corecodec.com, the site sends back an SSL cert for "services.corecodec.com". Browsers complain about that. We ignore the certificate as a mismatch. That's equivalent to having no SSL cert, as far as we're concerned. There's no penalty; it's just ignored.

Your SSL certificate checker has issues. Even when checking an SSL-enabled URL, with a valid commonName, it breaks because it's the wrong host.
Your check page
Wrong host for SSL certificate. Certificate for "services.corecodec.com", actual host "www.corecodec.com". (Peer certificate commonName does not match host, expected www.corecodec.com, got services.corecodec.com)

There's a reason we don't link to https://www.corecodec.com/ - the SSL cert is appropriate for the URLs we call it under. Disregarding that, pulling a https cert for a different host, then complaining that it's not "valid" is bad practice.

Many sites don't use SSL on their main domain - they often use secure.theirdomain.com, ssl.theirdomain.com, etc. It's still a SSL cert for the domain, what's the problem?

Also, your "address checker" needs some real work too - we get a negative rating because we don't have an address on the site. We have a "Contact Us" link on nearly every page on our sites. From the details, it looks like your address regex could some tweaking - it thinks "Windows Mobile, PocketPC" is an address, but our street address isn't.

Your SSL certificate checker has issues. Even when checking an SSL-enabled URL, with a valid commonName, it breaks because it's the wrong host.
Your check page
Wrong host for SSL certificate. Certificate for "services.corecodec.com", actual host "www.corecodec.com". (Peer certificate commonName does not match host, expected www.corecodec.com, got services.corecodec.com)

There's a reason we don't link to https://www.corecodec.com/ - the SSL cert is appropriate for the URLs we call it under. Disregarding that, pulling a https cert for a different host, then complaining that it's not "valid" is bad practice.

Many sites don't use SSL on their main domain - they often use secure.theirdomain.com, ssl.theirdomain.com, etc. It's still a SSL cert for the domain, what's the problem?

Also, your "address checker" needs some real work too - we get a negative rating because we don't have an address on the site. We have a "Contact Us" link on nearly every page on our sites. From the details, it looks like your address regex could some tweaking - it thinks "Windows Mobile, PocketPC" is an address, but our street address isn't.

Your SSL certificate checker has issues. Even when checking an SSL-enabled URL, with a valid commonName, it breaks because it's the wrong host.
Your check page
Wrong host for SSL certificate. Certificate for "services.corecodec.com", actual host "www.corecodec.com". (Peer certificate commonName does not match host, expected www.corecodec.com, got services.corecodec.com)

There's a reason we don't link to https://www.corecodec.com/ - the SSL cert is appropriate for the URLs we call it under. Disregarding that, pulling a https cert for a different host, then complaining that it's not "valid" is bad practice.

Many sites don't use SSL on their main domain - they often use secure.theirdomain.com, ssl.theirdomain.com, etc. It's still a SSL cert for the domain, what's the problem?

Also, your "address checker" needs some real work too - we get a negative rating because we don't have an address on the site. We have a "Contact Us" link on nearly every page on our sites. From the details, it looks like your address regex could some tweaking - it thinks "Windows Mobile, PocketPC" is an address, but our street address isn't.

Your SSL certificate checker has issues. Even when checking an SSL-enabled URL, with a valid commonName, it breaks because it's the wrong host.
Your check page
Wrong host for SSL certificate. Certificate for "services.corecodec.com", actual host "www.corecodec.com". (Peer certificate commonName does not match host, expected www.corecodec.com, got services.corecodec.com)

There's a reason we don't link to https://www.corecodec.com/ - the SSL cert is appropriate for the URLs we call it under. Disregarding that, pulling a https cert for a different host, then complaining that it's not "valid" is bad practice.

Many sites don't use SSL on their main domain - they often use secure.theirdomain.com, ssl.theirdomain.com, etc. It's still a SSL cert for the domain, what's the problem?

Also, your "address checker" needs some real work too - we get a negative rating because we don't have an address on the site. We have a "Contact Us" link on nearly every page on our sites. From the details, it looks like your address regex could some tweaking - it thinks "Windows Mobile, PocketPC" is an address, but our street address isn't.

http://www.corecodec.com/index.php?option=com_smf& Itemid=29&topic=3204.msg18973;topicseen#msg18973

is a hacked site. only goes to show, if you mess with gpl, you get gpl. they use gpl code in the comm. products.

CoreCodec do this... They found a clause in the GPL (clause 7) that states that if you don't have the patents/licenses to redistribute you can't. Since they are the only company with licenses they can release under GPL but nobody else can - single generation opensource, courtesy of the GPL.

I'm surprised others haven't exploited this hole.. it means you can take any GPL code, add your own licensed and/or code, and deny others redistribution rights. Sure, you have to give them the source, but it's useless to them.

Hehehe, here you go: http://www.corecodec.com/TCMP Player

This player has codecs for AAC which hopefully will do the job. This is the player I use for playing Seinfeld episodes on my Clie TJ37.

Though I use a PocketPC, I still like to avoid Windows Media. Instead, I use these tools for a nearly perfect experience:

PocketDivXEncoder is a wonderful tool, using mencoder to encode video to PDA-sized mpeg-4. Lots of options for video (including rotation) and audio, but not enough to be confusing. More importantly, audio and video stays in sync, I can estimate file size before encoding, and it supports multiple resolutions to support more than one platform.

For playback, I use BetaPlayer, a very capable (and GPL!) video player, with excellent mpeg-4 support. Full speed playback on my older 300MHz Toshiba e355 device, and it doesn't even kill my battery. Excellent support on the CoreCodec BetaPlayer Forum.

On a nearly daily basis, I use TyTool to extract last night's Daily Show from my Tivo as a 480x480 mpeg-2, then use PocketDivXEncoder to convert it to a ~64MB 320x240 mpeg4 file. Extraction, converting the .ty to mpeg-2, and encoding to mpeg-4 takes about 12 minutes on my A64 2800. I don't bother to edit out the ads, since it's very easy to skip them in BetaPlayer. Before I found this, I rarely touched my PDA. This is most certainly the KILLER APP for me.