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

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