It sounds like the database is set to FULL recovery mode and there are no transaction log backups being run. This is a very common problem.
If you don't want to do point-in-time restores, log shipping or anything along those lines and you are comfortable with only being able to restore to the point where the last full backup finished, set your database to SIMPLE recovery mode and shrink your log file to something sane.
If you are doing log backups, ensure that they are running without error and think about increasing their frequency.
It is also possible that something started a transaction hours/days/weeks/months ago and never committed it. Active portions of the log cannot be truncated, and those portions will not become inactive until the transaction commits or rolls back. Use DBCC OPENTRAN (MSDN is currently down, so I can't provide a link now) to troubleshoot that, it will show you information about the longest-running transaction in a database. If you find that you have a long-running transaction, you might have a hard time getting the application to commit. Of course, you can kill that connection but you will lose any database modifications that it has made in those hours/days/weeks/months. You may need to fix some code somewhere in the app.
Again, after you have resolved the problem, you will want to shrink your log file to something sane. You can use Performance Monitor to see how much space actually gets used over time. As a total shoot-from-the-hip number, I'd aim for a size that is 1.25 times your largest table (measured in GB, not in rows) and leave the file configured to grow.