Re: [LAD] At the hands of Professor Keller and Raymond

From: Jörn Nettingsmeier <nettings@email-addr-hidden-hochschule.de>
Date: Mon Jul 27 2009 - 21:33:30 EEST

hi bob!

welcome to the linux audio developers' community, thanks for joining
this list.

i'm sorry that you are joining for rather unfortunate reasons, but
licensing issues are always controversial and have a way of attracting
hot-heads... so please don't be offended. i'll try to refrain from
taking sides, as you and raymond seem to have some history togesther...

the way i see it (and i may be mistaken, all my facts come from this and
previous threads), your code is including other code which is licensed
under the gpl. you can only legally do this if your code is also put
under the gpl. which means that the moment you distribute your
application, its source code must be made available, as it is now a
derivative work of the other code you included (no matter how small),
and its license demands that. no way around this.
(strictly speaking, not even a busy travelling schedule, because you are
not under obligation to some random strangers, but to the license of
part of your software).

which means that raymond has a point. and he is also entitled to forking
your project any way he sees fit. so much for the legal part.

as to communication skills, raymond, i think you should go get a nice
cup of coffee, tone down a bit, see what happens. this bears all the
hallmarks of a excuse my french pissing contest, which might be
explained by the history of your mutual correspondence, but from the
outside, it looks like no big deal at all, and should sort itself out
nicely.

bob, i'm not a lawyer, but the way i see it, your options are:

* comply with the gpl, which means your code is gpl also, and the source
has to be available the moment a binary version comes out (even
previews, betas, whatever). and then you have the risk that somebody
"takes control away" from you. (not really a problem, see below.)

* take your code proprietary, which means replacing all gpl code by
self-developed or more leniently licensed code. that doesn't change the
fact that all your code written up to *now* is covered by the gpl, but
you could then relicense it and all future development any way you see fit.

obviously, as a lover of (and believer in) open-source, i would warmly
recommend option #1, although i've been with universities long enough to
 know about the difficulties involved in fund-raising for open source
projects.

as for "control", well, of course there is always the possibility of a
fork, but then it's a fair free market for users and mindshare. if you
decide to go proprietary, any gpl fork will likely see considerable
uplift, and more than one company have made themselves obsolete by such
a move - that's always the risk.

on the other hand, if you decide to open up your stuff and encourage
participation, your application will profit from an enlarged user and
contributor base, while you still maintain control.

as for taking patches: if people want to contribute and you can
incorporate their work, great, it will make your project stronger.
sometimes, your idea of software architecture might differ from that of
a contributor, so you will reject patches. perfectly ok. of course, once
many people have found their patches been turned down for reasons not
entirely transparent or logical to them, there is new potential for a
fork. or there may just be personality clashes, leading to a fork
eventually. that's how it is. but market forces have a way of
eliminating weak branches of a project rather speedily.

i hope i was able to contribute some clarifying remarks. please take
everything you read here with a metric grain of salt, and be aware that
licensing issues happen to be very important to the open source crowd.

it would be great to have you and your team join the open source
community at large and see you on this list in the future - you will
find there is quite some knowledge here that might be worth tapping into.

best,

jörn

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Jul 28 00:15:06 2009

This archive was generated by hypermail 2.1.8 : Tue Jul 28 2009 - 00:15:06 EEST