license?

[fredemmott]

This project is licensed under the GPL which means that others can’t distribute it when using GPL-incompatible libraries; I can’t find a clear description of if libNDI is GPL-compatible

[dodgepong]

This plugin does not distribute the NDI library -- that is why it instructs users to download the redistributable on their own.

This plugin does include the NDI library headers from the SDK that allow the plugin to interact with the NDI runtime, which are released under the MIT license.

[fredemmott]

Sorry, it’s not just about distributing NDI - if it’s linked/tightly coupled (though there’s a lot of disagreement on what that means), it’s still not OK if it depends on the shared library

[dodgepong]

OBS as a GPLv2 application (and by extension, its plugins) is only considered to depend on and the NDI runtime if they are considered two parts of one program (i.e. you can't use one independently without the other). This is true for OBS plugins, because plugins need OBS to work. However, this is not the case for the NDI library, since the NDI plugin is written such that if the NDI plugin does not exist on the system, it does something else (in the case of the NDI plugin, that "something else" is "nothing"). OBS continues to work as expected and nothing is broken or degraded. Thus, there is a clear argument for the two applications to be considered separate and independent.

[fredemmott]

However, this is not the case for the NDI library, since the NDI plugin is written such that if the NDI plugin does not exist on the system, it does something else (in the case of the NDI plugin, that "something else" is "nothing")

dynamic linking/dlopen are generally not considered valid compliance mechanisms, even if there were a stub implementation that does nothing.

OBS continues to work as expected and nothing is broken or degraded.

... except the NDI plugin is broken, so whether you think of obs-ndi or obs+obs-ndi as a combined work, it's still broken.

That said, closing: I don't think this can't actually be fixed/clarified (depending on your viewpoint) without libndi's real implementation being made available under a free license, as libobs is GPL

[fredemmott]

For reference, as it's a bit hard to find: http://514f211588de67e4fdcf-437b8dd50f60b69cf0974b538e50585b.r63.cf1.rackcdn.com/Utilities/SDK/NDI_SDK_v2/NDI%20License%20Agreement.pdf

[fredemmott]

Some others consider this non-distributable over at https://obsproject.com/forum/threads/ndi.47104/page-2 and were considering IPC-based solutions.

[dodgepong]

That was prior to NewTek releasing the headers under the MIT license. Also that SDK license is for v2, where the latest is 3.5 I believe.

[fredemmott]

That was prior to NewTek releasing the headers under the MIT license

The library is also relevant, not just the headers.

Edit: though yes, the others agreeing is before that change

Also that SDK license is for v2, where the latest is 3.5 I believe.

That is the license that the NDI header files included in this project link to, via http://new.tk/ndisdk_license/ - is there a newer link?

[dodgepong]

That said, I agree the IPC solution is less ambiguous and would like to see someone implement it. It's too bad that the person who started working on it never finished.

[btorellALTA]

Mmm, I'm not sure about the license. It's possible the link is outdated, or the version number refers to the version of the license rather than the version of the library.

All that said, I still feel like it's ambiguous and open to interpretation, but I am not a lawyer or GPL expert by any means. If NewTek were to release the library under a GPL compatible license, I would be thrilled.

[fredemmott]

IPC seems a little fun, and would basically mean making a completely new wire + frame format - as you can't use the OBS frame formats without pulling in libobs (assuming that no-one has enough spare manpower to do a clean spec of them + clean implementation)