App note: Porting the Helix MP3 decoder to PIC32MX microcontrollers

Comments

1. hlipka says:

   March 4, 2012 at 11:40 pm

   Note that this isn’t useful for the PIC32MX1xx/2xx series. They have only 32k RAM, and this decoder eats all but 512 bytes of this.

   Reply
2. mrpippy says:

   March 5, 2012 at 5:09 am

   I’m not a lawyer, but in reading the RPSL I’m not totally convinced that the run-time library loading technique avoids making the entire product a derivative work. The relevant parts of the RPSL:

   You may create a Derivative Work by combining Covered Code with other code not otherwise governed by the terms of this License and distribute the Derivative Work as an integrated product. In each such instance, You must make sure the requirements of this License are fulfilled for the Covered Code or any portion thereof, including all Modifications.

   Mere aggregation of another work not based on the Covered Code with the Covered Code (or with a work based on the Covered Code) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. If You deliver the Covered Code for combination and/or integration with an application previously provided by You (for example, via automatic updating technology), such combination and/or integration constitutes a Derivative Work subject to the terms of this License.

   RTLL avoids “combining” covered code (the Helix MP3 decoder) with other/proprietary code until both hex files get programmed into flash.

   An app note certainly isn’t going to carry binding legal advice, but to me the app note is far too casual in presenting RTLL as a technique that won’t require proprietary application code to be open-sourced, without ever acknowledging that a) to the best of my knowledge, this technique doesn’t have the blessing of RealNetworks/Helix, and b) lawyers may not agree.

   Reply

Leave a Comment Cancel reply