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@xxxxxxxxx> 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 _______________________________________________ fedora-advisory-board mailing list fedora-advisory-board@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-advisory-board
