On Wed, 2007-06-06 at 20:47 +0200, Nick Copeland wrote: > By your own remarks there are already issues with the specification that may > require modifications and optimisations for an open system, such as Linux > for example, so you recognise the possiblity that changes would be required. > Those changes would have to be raised through the consortium via a paying > member as the consortium does not accept requests from outside of their cosy > liittle circle. Should the community to accept that requirement? > > You state that you do not understand my objections? They are simple, I stand > on the side of open source, open standards, and general implementation > without fees, demands, legal recourses or other futher liabilities, and as > yet this organisation posts documents refering to the liabilities of those > who implement their specification. please send me a link to the documentation that leads you to believe there is a requirement to pay a licensing fee or more in order to use AAF, or liability issues, etc. the entire SDK for AAF is downloadable from SourceForge. the AAF FAQ states: -------------------------------------------------------------------- 4.4. What are the licensing terms for the AAF SDK? The AAF SDK is licensed under a perpetual, royalty-free license. Users are allowed to download source code, make derivative works, include these works in their products and charge for these works. ---------------------------------------------------------------------- the FAQ continues: ----------------------------------------------------------------------- 4.9. If I can get the AAF SDK free, why do I need to join the AAF Association? You should join the AAF Association to get support for the SDK and to participate in the development of future capabilities of AAF. AAF is fundamentally a shared industry initiative, built out of the contributions of its members. No one is required to join; the association is open to everyone. Members share benefits such as access to the support network and participation in developer conferences and the technical committee. -------------------------------------------------------------------------- the SDK license is somewhat similar to the initial Mozilla public license, in that if you distribute a modified version of the SDK you have to send your changes back in to the AAF Association. otherwise, there is no obligation to interact with the AAF Association at all. at one time, the SDK included libs from MS for "structured storage" (think filesystem-inside-a-file) but the SDK now has the option to build using GNU equivalents (GSF or something like that). in 2000, the AAF presented a entire roadmap for their planned adoption of an open source strategy. the PDF of the slides is easily available: http://www.aafassociation.org/passed_events/2000-11-DevCon_SanteFe/opensource.ppt so i am totally lost and confused by your suggestions. > Strangely enough, your promotion of this consortium amost seemed targetted > at preventing the implementation of an open and hence competitive > alternative, and that seems strangely close to business practices of several > frowned upon companies. sigh. i've spent 5 years struggling with inter-operability issues with DAWs, to no particular avail. the issues are large, and complex, and to date nobody appears to have done a particularly outstanding job of it. i don't believe that the right answer is to start another "standards" definition. if i was convinced that using AAF required licensing fees, or that the people who define the standard would pay no attention to organizations or individuals outside the AAF, then i would probably avoid using it, and would certainly not "promote" it here. --p _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
