It may well be that the API for a single timer is not copyrightable (under this ruling), but the collection of all APIs your module uses might still be. Similarly a novel or a chapter of one, or a poem, may be composed of simple enough sentences that no single sentence is worthy of copyright protection, but taken together in a given arrangement (or, if you will, "structure, sequence and organization") is a protected work. On an even lower level a novel is composed of words, none of which is likely to be copyrightable, but the whole still is.
As has been said over and over, there is no "non-GPL" and "GPL" parts of the kernel and its module API, but rather the _GPL prefix is merely a subjective expressed opinion of the author that if you use these, you are likely to be writing code that is intertwined enough with the kernel that you are likely to be creating a derived work. You still might very well be creating a derived work and thus violating the license even if you only use the non-_GPL symbols.
So, if you really *only* use the timer API, it might (or might not) be a short enough excerpt that it does not gain copyright protection, but the more of the kernel APIs you take (and that does include the non-_GPL ones, since those too are only licensed under the GPL), the more likely it is you are taking enough of it that you are in violation.
Note that there is a separate, untested argument that this ruling does not touch that actually loading your kernel module creates a work where your code and the kernel code are intertwined enough that it should be considered a derived work, in which case whoever loads it would violate the copyright of the kernel and, to the extent it's someone else than you, you would likely be liable for at least contributory infringement.
Also note that it is not the concept of timer or wrapping it that is copyrightable, but the specific way you do it, and in the case of the API the specific API you come up with. If there is only a single way or only a few ways to do it, it won't be protected. But there's ample room for creative choices there - for example, the particular names you use for the structures, fields and functions, none of which might be copyrightable in isolation. Put in another way, if two people implementing a timer API would be very unlikely to end up in the very same API (again including names, order of fields, ...), that tends to indicate that the choices are expressive enough to merit copyright protection.
The concept of a timer or a wrapped timer would be in the domain of patentability instead (but would probably fail for obviousness, which is a bar for patentability, but not for copyright). While I don't like the implications of this ruling, I do agree with the court that copyright law is clearly a more suitable fit for APIs (if they need to be protected at all) than patents, since there clearly is creative choice in how to write an API. If the API is exceedingly clever, the concepts there might warrant patent protection, but then that would not extend to the particular instance of the API, like function names.
Also note that the bar for copyrightablility is low but not nonexistent. A fairly trivial 9-line function like the rangeCheck() in this suit can already be expressive enough to be copyrightable. Presumably a similar level of expressiveness in an API would also merit copyrightability. I tend to think that the room for creative choices in a simple timer API is probably about the same as that in the rangeCheck() function, if not slightly more.
Re: Eh... It's a timer
As has been said over and over, there is no "non-GPL" and "GPL" parts of the kernel and its module API, but rather the _GPL prefix is merely a subjective expressed opinion of the author that if you use these, you are likely to be writing code that is intertwined enough with the kernel that you are likely to be creating a derived work. You still might very well be creating a derived work and thus violating the license even if you only use the non-_GPL symbols.
So, if you really *only* use the timer API, it might (or might not) be a short enough excerpt that it does not gain copyright protection, but the more of the kernel APIs you take (and that does include the non-_GPL ones, since those too are only licensed under the GPL), the more likely it is you are taking enough of it that you are in violation.
Note that there is a separate, untested argument that this ruling does not touch that actually loading your kernel module creates a work where your code and the kernel code are intertwined enough that it should be considered a derived work, in which case whoever loads it would violate the copyright of the kernel and, to the extent it's someone else than you, you would likely be liable for at least contributory infringement.
Also note that it is not the concept of timer or wrapping it that is copyrightable, but the specific way you do it, and in the case of the API the specific API you come up with. If there is only a single way or only a few ways to do it, it won't be protected. But there's ample room for creative choices there - for example, the particular names you use for the structures, fields and functions, none of which might be copyrightable in isolation. Put in another way, if two people implementing a timer API would be very unlikely to end up in the very same API (again including names, order of fields, ...), that tends to indicate that the choices are expressive enough to merit copyright protection.
The concept of a timer or a wrapped timer would be in the domain of patentability instead (but would probably fail for obviousness, which is a bar for patentability, but not for copyright). While I don't like the implications of this ruling, I do agree with the court that copyright law is clearly a more suitable fit for APIs (if they need to be protected at all) than patents, since there clearly is creative choice in how to write an API. If the API is exceedingly clever, the concepts there might warrant patent protection, but then that would not extend to the particular instance of the API, like function names.
Also note that the bar for copyrightablility is low but not nonexistent. A fairly trivial 9-line function like the rangeCheck() in this suit can already be expressive enough to be copyrightable. Presumably a similar level of expressiveness in an API would also merit copyrightability. I tend to think that the room for creative choices in a simple timer API is probably about the same as that in the rangeCheck() function, if not slightly more.