I've spoken with multiple developers who interpet "LINQ" as LINQ to SQL. Yes, they are certainly related, but LINQ is not just LINQ to SQL. LINQ to SQL is likely the most well known LINQ Provider, although its only a small part of the LINQ umbrella. In fact, LINQ to SQL will likely fade into the sunset, as Microsoft will no longer be enhancing it, but rather focusing on the Entity Framework.
LINQ provides an abstraction for querying data, regardless of where that data resides. Consider the following line of code.
IQueryable<Comment> publicComments = comments.Where(x => x.IsPublic);
As a developer, I don't need to know where this data resides, or how it is retrieved. It could be translated into SQL by LINQ to Entities, LINQ to NHibernate, or LINQ to LLBLGen. It could be translated into CAML by LINQ to Sharepoint. It could be translated into Twitter's API access code by LINQ to Twitter. The bottom line is, as a developer consuming LINQ, I don't have to worry about it. If I am using a tested and proven LINQ provider, the internal details of that data access have already been hashed out by the provider developers.
The number of LINQ providers continues to grow, and its well worth your time to learn the abstraction. LINQ to SQL may fade away, but LINQ will not.