[alsa-devel] Replace include/list.h with non-GPL implementation

[Takashi Iwai]

On Fri, 24 Jul 2015 09:34:19 +0200,
Clemens Lang wrote:
> 
> On Thu, Jul 23, 2015 at 09:03:31PM +0200, Takashi Iwai wrote:
> > Well, the linked-list macro is a trivial thing each beginner
> > programmer starts writing at school.  And, the API itself can't be an
> > issue.
> 
> I agree, but that does not necessarily mean that the license wouldn't
> apply. Consider this thought experiment. You write a two-page prose
> article on how a linked list works. Obviously, the concept of a linked
> list is trivial -- but does that mean copyright doesn't apply to your
> article? I think we have a similar situation here; the concept of a list
> may be trivial, but that doesn't mean the implementation is.

Sure, it can be written differently.  But my point is that it is (or
must be) trivial to write a linked list code for C programmer.  We can
easily drop the existing code and replace with our own.

> > That is, it'd be enough just rewriting the existing list.h (e.g.
> > renaming variables, shuffles the call order, rephrase the comments) by
> > ourselves without introducing a big piece of codes of even a different
> > license, IMO.
> 
> Unless you re-implement a list from scratch that provides the same API
> that wouldn't really help you.

So why not writing from scratch?  We just need only a few things:

struct list_head
list_entry()
list_for_each()
list_for_each_safe()
list_add()
list_add_tail()

I guess the definition of struct list_head will be identical in high
probability if any other people write from scratch (maybe someone put
next before prev).  The rest are all obvious implementations.  The
execution order might be different, and the comments are different --
this is what I mentioned in my previous post.

> I'm fully aware that it may not be
> obvious whether somebody only modified an existing file heavily or
> re-implemented it, but unless you start from scratch you won't free
> yourself from the original copyright (and thus, the license). That's
> also one of the reasons why I'm proposing to use a modified version of
> an existing implementation rather than re-writing it from scratch.
> 
> A re-implementation would also have to be tested, which the existing
> list already is. Additionally, I think the proposed change simplifies
> iterating over a list. Currently, you always need list_for_each()
> followed by list_entry(), which would be simplified to a single
> statement with this change.

How can you be sure that the adapted code would work with alsa-lib?
You'd need to check in a similar manner no matter whether you adapt
from other or you write it.

About the list_for_each(): we can replace them with
list_for_each_entry().  This would be a nice cleanup.


thanks,

Takashi