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?