On 10/9/18 9:56 PM, Alec Leamas wrote: > On 09/10/18 21:46, Sebastiaan Couwenberg wrote: >> On 10/9/18 9:35 PM, Alec Leamas wrote: > >>> Yes, they must be separate packages - as a starter, they are separate >>> upstreams That said, at a glance it looks possible to add such packages >>> to the non-free section. If so, what needs to be considered in such a >>> scenario? >> >> If the plugins cannot be built from source, non-free is not really >> appropriate either. Despite what the policy footnote says. >> >> If there are plugins that have license issues, that restrict >> modifications for example, those cannot be included in main and must go >> to non-free. The opencpn package in main cannot Depend on nor Recommend >> packages in non-free, if opencpn cannot work without non-free components >> its needs to go to contrib, which like non-free is not officially part >> of Debian (which implies not built on the buildds, not included in >> various QA systems, etc). > > This part is no problem. It's the plugins which depends on opencpn, not > the other way around. > >> For the benefit of its users OpenCPN should have a plugin manager to >> distribute its plugins, so that they don't have to be packaged, and >> hence don't have to conform to the distribution policies. > > Perhaps. But as it is, the plugins are basically distributed as github > repos + some prebuilt packages for wWndows and MacOS + some debian > packages in various shape. > > I have noted that the Nvidia closed-source drivers are available in the > debian repos. From a legal point of view, isn't this similar?
Bad example. The nvidia driver is more like non-free firmware, the core is closed but there is still code around it to integrate it with the system in question. Before spending much time debating non-free bits, your should focus on getting the free software components packaged properly. Kind Regards, Bas
