Re: [avr-libc-dev] Adding (some) Procyon AVRlib functionality to avr-libc

[Joerg Wunsch]

As Ruddick Lawrence wrote:

> I guess the first thing to figure out is
> how you (and the other developers/maintainers) define the scope of avr-libc,
> and how best to design a complementary library (if at all) to house useful
> code that is outside of that scope.

Ideally, if there were enough volunteers to develop *and* maintain
such a library (this includes maintaining documentation, handling bug
and patch tracker submissions, rolling releases etc.), I could think
of the avr-libc project being able to house it as a relatively
standalone project.  It could get a separate top-level directory in
the CVS tree, and roll separate releases from there.

That way, users could decide whether they just need the low-level
stuff from avr-libc, or want a higher level of abstraction, and install
a second library on top of that.

However, the biggest issue with that approach is finding enough people
who are willing to actively work on that.  I don't see those who
currently maintain avr-libc having enough vacant resources to manage
such a project.  (That doesn't mean we were completely "out" of such a
project, it's only we've got our hands full with maintaining the
current state of avr-libc.)

So, volunteers welcome. ;-)

Lacking that, I agree with Eric that some fairly low-level interface
abstractions might also go into the "classic" avr-libc, thereby
extending its scope a bit.  However, if there were enough developers
for a separate library, its scope could be much beyond the current
avr-libc, so things like a generic HD44780 driver API could be there
as well.  (Feel free to pick the current implementation from the
stdioexample as a starting point.)

I agree to the person in that thread about the GPL issue; in order to
keep such a project under the roof of avr-libc, I'd say using the same
licensing conditions as avr-libc is pretty much mandatory, as this has
shown to cause the least trouble to every potential user so far.  This
in turn would not allow re-using code of Pascal Stang's library, but
of course, re-using ideas or APIs does not constitute a licensing
issue.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)