Re: opencpn: binaries without source.
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
Reply to: