Basically, the active logs are those logs that would be needed for crash recovery purposes and the beginning of the active log space is determined by two things: 1) the oldest uncommitted transaction and 2) the age of changed pages in the bufferpool(s) that haven't been persisted to disk yet (and these could be for already committed transactions).
With circular logging, the active space "wraps" through the logs and the current head of the active space moves as 1) the oldest transaction commits and/or 2) old pages in the bufferpool get flushed out. This is what I was referring to as log reclaim. In any case, the log space that gets used cannot wrap past this head point, otherwise log records that would be required for recovery purposes would be overwritten. Consider the case where you start a transaction and do some small amount of work -- but you don't commit it. Then you have a bunch of other transactions doing a whole lot of work, committing as they go. Eventually, because of the one open transaction, the log space is going to run out and applications trying to do work will get SQL0964N errors. This is why we suggest committing your transactions freely.
In the case of IMPORT, as the other person suggested, it will try to insert each row and just do one commit at the end. If it's a large import then this could fill your logs. COMMITCOUNT tells import to commit after every X rows inserted, to help alleviate log full situations. So, it's definitely useful to use COMMITCOUNT but you have to choose the value wisely. Setting it to something really small means that you're protecting yourself from these log full issues, but it does add a bit of overhead.
Hope this helps.
Kelly