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.
If you do decide to accept this standard then I hope that minimally you can
get your friends at the BBC and related organisations to accept removing
their demands for royalties of the applications implementing their XML
specification. I would prefer that were linux to adopt such a standard that
it were released under GPL for those who wish to adopt rather than for those
who might be able to simply via some form of dispensation from a commercial
organisation.
If Linux cannot accept their so called standard due to the nature of its
licensing then perhaps work is still needed on an open standard since the
body of work represents a requirement. The proposal of the original posting
was such an open document.
On the other hand, if you only want your application to accept those demands
then by all means implement it, but then also refrain from even suggesting
to the open source community that such an open standard already exists when
evidently that is not the case, as you did in your rather terse submit.
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.
n.
From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
Reply-To: paul@xxxxxxxxxxxxxxxxxxxxx,A list for linux audio users
<linux-audio-user@xxxxxxxxxxxxxxxxxxxx>
To: A list for linux audio users <linux-audio-user@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: [LAU] Proposal: OpenDAWS (long)
Date: Wed, 06 Jun 2007 13:05:58 -0400
On Wed, 2007-06-06 at 18:21 +0200, Nick Copeland wrote:
> It seems a bit sad that any Linux advocate should be backing this
operation,
> it would cost about $1500 per year to get access to any kind of support
for
> the SDK or advice on best practices and cosiderably more if you really
want
> to participate. You could stump up $175 per year yourself to propose
changes
> as long as you can find somebody paying the full price or more to back
you.
> It is a commercial directive not an open movement. From a perspective of
> Linux audio it is already a pain that the Midi Manufacturers Association
> want cash for their specifications.
>
> So is the argument for this specification will be 'the professional
> applications will be using it' hence it becomes the standard?
>
> The whole specification is delivered outside of a GPL, products using
its
> specifications are expected to pay royalty licensing and as such should
not
> be advocated as a part of any open source movement.
>
> The proposal here was for an open format, not a closed consortium
format,
> the difference may be subtle and is apparantly lost on some people.
I'm not entirely sure what your objections are. I have the whole AAF
spec in front of me, downloaded for free. The BBC has been pushing AAF
towards more and more open sub-standards over the years, including its
soon-to-be-released adoption of XML rather than a totally ugly AAF-only
format for the file itself. There is no licensing fee, no license, no
patents. I am almost wondering if you are looking at the same thing I
am. I've gotten excellent support from the main members of the steering
committee, who happen to work for the BBC and are quite involved in its
open source work (Dirac and more).
I am not going to spend time on supporting a "new" (i.e. LA-specific)
interchange format when the vast majority of ardour users need
interchange with proprietary applications, several of which already
support AAF (not AAF-XML, yet). It has the industry more than a decade
to get the rather pitiful state of affairs that AAF represents already,
and I don't hold out hope of any magic bullets. There is a lot of
collective wisdom that went into its design, even though it does smack
of design-by-committee.
IMO, the real problems with AAF as it currently stands is its horrendous
complexity and its inability to be filesystem neutral.
--p
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
_________________________________________________________________
Like puzzles? Play free games & earn great prizes. Play Clink now.
http://club.live.com/clink.aspx?icid=clink_hotmailtextlink2
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
