On Sun, 24 Oct 1999, Mark Taylor wrote:
> > Now, the lame authors need to ask themselves: "Do we want to use the
> > software we devloped to help increase the amount of free (freedom)
> > software in the world?"
>
> Yes we do, but what about the competing desire to make MP3 as popular
> as possible to fend of evil such as the SDMI?
It's already quite popular, too popular in fact. The homogenus nature of
the high-quality low-bitrate market on the internet is dishearting.
SDMI wont work. Like DVD, people will find ways around it's protections
(yes, CSS is completely cracked now) and even the hardware players will
not have to worry.
I dont think there really is anything to worry about in that regard.
> Also, it seems like splitting hairs to say you can give away lame.exe,
> but you cannot give away lame.dll. Dont you just have to make a few
> minor changes to your front end code to use lame.exe rather than
> lame.dll? If that is the case, then there is not much difference
> between the .dll and the .exe.
In a way, that's exactly my point.
Why not require non-gpl compatible apps to use the exe:
* Using the exe is almost the same as the dll, the dll is just a
little easier.
* We want lame everywhere.
* Lame offers nothing super-major over non-gpled alternitives.
Why require non-gpl compatible apps to go the exe route:
* We want more OSS, and we want more people to use OSS. We should
give every advantage we can to OSS.
* Using hte exe is almost the same as the dll.
It really isn't a big deal.
Though, it might be prudent to dual-licence here... I dont know what the
offical statement is RE: including LGPLed code in GPLed apps, as someone
might want to produce a 'better' (as in AAC quality) encoder, and GPL it
(because it *IS* novel, and they might want to give free software a
advantage) but they might want to use some lame code.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
