codec buddy, fluendo, etc.

[Jeff Spaleta]

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?

-jef