[Haskell-cafe] Re: [Haskell] Google Summer of Code 2009
gwern0 at gmail.com
Wed Feb 11 10:12:08 EST 2009
On Wed, Feb 11, 2009 at 10:00 AM, Jamie <haskell at datakids.org> wrote:
>>> Seems like it is ok to write H.264 in Haskell and released via GPL
>>> There is theora.org but H.264 would be ideal. Ditto for H.263.
>> Software patent issues are entirely orthogonal to the copyright issues of
>> who wrote what under which license. That's why software patents suck so very
> Thanks for the links. What I understand is some standard body create the
> specs, the role, the purpose, the protocols (i.e. H.323 by ITU
> Telecommunication Standardization Sector) then one can create programs that
> follow those protocols and don't have to concern about patent license at
> all, is that correct?
In general, you can't say that just because it was generated by some
standards body it will be usable. Standards bodies often only have to
make their work available under 'reasonable and non discriminatory'
terms, which should be read 'not ruinously high license fees' (see
). RAND terms are, of course, hopelessly strict for any FLOSS
> I just checked H.264 and yes JVT (the creator of H.264/MPEG 4/AVC
> specs/protocol) require patent licensing. Oh well... I guess JVT does not
> do something with x264/ffmpeg cause they are totally free, but let say if I
> include the H.264 code from x264/ffmpeg in my application and sell for some
> $$$ then JVT's lawyers could run after me, is that correct?
If JVT has patented any of the techniques in the x264/ffmpeg codebase,
then they can come after you if you distribute in *any* manner. An
example: the RIAA is still allowed to sue file-sharers even though the
sharers aren't seeing a penny in any way.
> I just checked H.263 and it looks like it does not require patent licensing
> at all (it is created by ITU-T Video Coding Experts Group (VCEG)) so one can
> write H.263 in Haskell and release freely without patent licensing issues.
> So writing H.263 in Haskell could be a good GSoC project. One mentioned
> that GHC produce slow code, well H.263 could be a good test case to improve
> GHC optimization over time. In The Computer Language Benchmarks Game,
> Haskell has some catching up to do. :)
It does sound like a reasonably discrete task, and it sounds like you
have a use for it; but I wonder if it's doable in a single summer?
More information about the Haskell-Cafe