codec buddy, fluendo, etc.

[Jeff Spaleta]

On Feb 11, 2008 11:23 AM, Luis Villa <luis at tieguy.org> wrote:
> 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.

Does it matter?

The point we aren't going to demand users use an open toolset when
choosing to license the resulting content in an open way. Video
editting comes to mind.  Can you create theora videos through a
process which uses proprietary tools.. yes.  Do we demand that users
avoid doing that..no. Do we demand that contributors who are
contributing content for the Fedora project to use directly? In some
case...yes. In fact I think if pushed we'd probably demand that of all
contributions if we could.

>> 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?

Example, flash plugin download in firefox.  We could apply a patch to
our firefox which deliberately stopped our firefox binaries from going
out and finding Adobe's flash plugin when firefox detected a need for
it.  Doing this would be a deliberate effort to remove access to a
legal, but closed source, plugin that the firefox upstream developers
have chosen to make accessible to end-users of the application.  We
would have cause for such a patch if we felt that the firefox plugin
detection technology was not giving the end-user an equitable choice
between an open source and closed source plugin meant to perform the
same function.  If automatic detection of optional functionality does
not have built in support for choice, then I feel Fedora is free to
demand an open implementation where one exists, regardless of the
relative level of functionality  when compared to the closed source
implementation.

Also note that I am not talking about systemwide 'plugins'... I'm
talking about application technologies aimed at individual users on a
system.  If there was some upstream project that exist which meant to
automatically download proprietary plugins and install them
systemwide, I would endeavor to keep that technology out of our
codebase.  I draw a bright line between end-user application
customization and system-wide customization...even on single user
system.

>> 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 ?

Will passionately encourage our users to use and contribute......

It's more than hope. Hope is passive...we aren't going to be passive
about it. We aren't going to sit on our hands and wait for people to
'get it'.

We are going to take every damn opportunity to encourage people to use
and contribute open technology.  And where there are no opportunities
to engage people over this, we will create those missing opportunties
and challenge people to participate.

-jef"drink from the mental firehouse that is my mind"spaleta