codec buddy, fluendo, etc.

[Luis Villa]

I'm applying some editing love because it is really good and probably
deserves to be published somewhere. ;)

On Feb 10, 2008 2:58 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> proprietary data ( which is taken to mean copyrighted in such a way

copyrighted->encumbered

> Such open data does
> not need to be created using open tools, though of course that is
> preferable.

I'm trying to think of a case where one can create open data, but only
with proprietary tools, and failing- I must be missing something
obvious, though.

> We recognize that the line between code and data can be muddy,
> especially when we cross hardware or network boundaries or use
> emulation.  We will continue to work on refining the policy in these
> areas. We recognize that our policy decisions will inevitable be prune

prune->prone

> We will limit any Fedora specific patching of upstream code projects
> which aims to remove user access to legally obtainable proprietary
> helper executables (plugins) or legally obtainable proprietary data.

I'm not entirely sure I follow this sentence. Does 'which aims to
remove user access' apply to the patch, or the upstream code projects?

> Some upstream projects have built frameworks which make it easier for
> end-users to access legal proprietary plugins.  These plugins are
> outside the scope of our packaging repository which we directly
> control. While we continue to endeavor to users to use and contribute

endeavor to users to-> hope (prefer?) that our users will ?

> to the development of open tools over proprietary solutions, we
> recognize that our users make their own choices.. and the the upstream

the the -> the

> projects similarly make their own choices as to what to functionality
> to expose to end users.
>
> If upstream projects that use plugin detection technology are willing
> to support a choice of both open and closed plugins for the same task,
> then we are content to pass on that choice to the user.  But if an
> upstream project prefers to only present proprietary solutions and
> makes no room for an open choice for the same task.. then we have
> cause to disable that plugin detection technology in our releases.

have cause to->will ?

Overall, seems fairly solid as a manifesto and a policy.
Luis