On Wednesday 06 June 2007, Paul Davis wrote: > 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/opensour >ce.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. > AAF may be the way to go once the XML version is available. XML must be text oriented (my proposal points to binary files but does not include them inside the XML itself). Once one can create such stuff, even without any SDK, the issue becomes moot. Question is whether AAF is overkill or whether it is suited for ... linux audio? What I have in mind mirrors the way a program like Sonar stores its data (in its proprietary binary format) in a textual, open manner Does Ardour already support (the binary) AAF? Does anything else we might be playing with? What type of XML stardard would opensource developers readily support in some form or another? _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
