codec buddy, fluendo, etc.

[John Babich]

On Feb 10, 2008 10:58 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> On Feb 10, 2008 10:20 AM, Karsten 'quaid' Wade <kwade at redhat.com> wrote:
> > There is a legal line and a moral line.  We are careful not to cross the
> > former, but we are having a hard time defining and keeping to the
> > latter.
>
>
> My moral line:
>
> We are not going to include closed source code directly in the
> repository we control, which is designed to execute on the computer
> architecture we build and release for.
>
> We will not include open source code that could only interact with
> proprietary data, but we will not hamper the user's ability to use
> proprietary data ( which is taken to mean copyrighted in such a way
> that is not distributable directly by Fedora, but still legally usable
> by individual users) whether that data is music, videos, web pages,
> documents,etc.  This does not mean that "useful" open data has to be
> available..but it must be demonstratable that open content can be
> created for consumption by the code in question. Such open data does
> not need to be created using open tools, though of course that is
> preferable.
>
> 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
> to inconsistency due to the complexity of the situation, and we
> apologize in advance.
>
> 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.
> 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
> to the development of open tools over proprietary solutions, we
> recognize that our users make their own choices.. and the the upstream
> 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.
>
>
> How's that for a manifesto?
>

That's pretty a good manifesto. I'd sign it.

Best Regards,

John "Live Free or Die Closed" Babich