3 ms·

At first glance I cannot find any indication that streamelements violates the OBS license. They distribute a plug-in for OBS, separately, and that’s usually not

At first glance I cannot find any indication that streamelements violates the OBS license. They distribute a plug-in for OBS, separately, and that’s usually not considered a GPL violation, even if the plug-in is closed source. A quick google didn’t turn up any discussion alleging a GPL violation either. The article cites no discussion either. See https://streamelements.com/obslive https://streamelements.com/obslive

tyingq 5y ago
>They distribute a plug-in for OBS, separately, and that’s usually not considered a GPL violation, even if the plug-in is closed source. That doesn't appear to be Gnu's position. Obs plugins definitely "share complex data structures". "If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL..." "If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing [or shipping] complex data structures...that can make them one single combined program" "If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program" https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLPlugins https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htm...
- Drakim 5y ago
  How exactly does that work, what if the plugin was created before the program?
  - deleted 5y ago
    [deleted]
  - wolrah 5y ago
    The theoretical dividing line (I don't think this has ever gone to court) is whether the plugin interface is specific to the GPL application. The prevailing view is that if a GPL application is just implementing a pre-existing plugin API (for example VST or NPAPI) then obviously plugins built for that API can't be held to the licensing of one particular host application. On the other hand, if said API is specific to the GPL application then the GPL applies (for example Linux kernel device driver interfaces). I'm not sure if it's ever even happened, but it's interesting to contemplate the possibility of a proprietary application implementing compatibility with an existing GPL app's plugin API.
    - bombcar 5y ago
      It’s down to the definition of “derivative work” and the FSF may not have it legally correct (they may be overstating what can be considered derivative from a legal viewpoint) - as it has never reached litigation we don’t have a final solid answer. And even if it did we’d only have a precedent that may be hard to apply.
- Xylakant 5y ago
  But it's clearly not as simple. The GPL triggers on distribution of the combined work - the user is free to link GPL'ed and other code with incompatible licenses as long as they do not redistribute. For example, the kernel modules for VirtualBox are distributed in source form under a commercial license and need to be compiled on the users box against the kernel header. Distributing the modules in binary form would likely be a violation, as would be distributing OBS with the closed source plugins - but that's not what happens here. So the GPL only triggers when a work incorporating GPL code is distributed, so the question here boils down to "does the plugin itself contain GPL code" and not to "can it be loaded into a GPL'ed program on the users computer." The GPL does not and cannot force a license on some piece of software that only implements an API - it can only affect software that directly incorporates code. Think about it this way: If the mere ability to be loaded as a pieces of software into a GPL'ed program is sufficient to force the piece of software under GPL, then I could just write a small GPL program for any piece of closed source software and force it under GPL. That clearly doesn't work.
  - tyingq 5y ago
    >so the question here boils down to "does the plugin itself contain GPL code" and not to "can it be loaded into a GPL'ed program on the users computer." I don't think it's that simple either. You mentioned the Virtual box kernel modules. There's plenty of discussion, some from Linus that some kernel modules are "derived works of Linux" and some are not. The binary Nvidea kernel drivers had to skip using a zero-copy DMA feature because of this, even if they shipped standalone. I suspect the same situation exists here. OBS, for example, has some very specific structs, header files, api functions, and other ways of interacting with plugins. A plugin made to work with OBS could very well be a derivative work, regardless of whether it ships with OBS or not. Distribution of the derivative work alone triggers the GPL in that case.
    - Xylakant 5y ago
      I’m not saying it could not be. I’m saying that a cursory search of the internet provides no substantial allegation that this is the case - and the article just asserts so, without any further citations or discussion.
- ranger_danger 5y ago
  The GPL only applies when you're redistributing a program or its code. A plugin that is downloaded later, and not necessary for the basic function of the program itself, while at that point could technically constitute a combined work, typically just sits on your computer forever at that point. Only if you were to then re-redistribute both that program AND the downloaded plugin, then there is a possibility of a GPL violation if the license of the plugin is incompatible.
  - outsomnia 5y ago
    If the plugin itself has no function or meaning standalone, without being linked to the GPL'd work, it's considered by the GPL to be a "derived work". And at least on GPL v2 that OBS uses, it operates at the point of "distribut[ing] or publish[ing]" that. v2 sect 2b You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. https://www.gnu.org/licenses/old-licenses/gpl-2.0.html https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

tyingq 5y ago

>They distribute a plug-in for OBS, separately, and that’s usually not considered a GPL violation, even if the plug-in is closed source. That doesn't appear to be Gnu's position. Obs plugins definitely "share complex data structures". "If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL..." "If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing [or shipping] complex data structures...that can make them one single combined program" "If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program" https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#GPLPlugins https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.htm...

Drakim 5y ago
How exactly does that work, what if the plugin was created before the program?
- deleted 5y ago
  [deleted]
- wolrah 5y ago
  The theoretical dividing line (I don't think this has ever gone to court) is whether the plugin interface is specific to the GPL application. The prevailing view is that if a GPL application is just implementing a pre-existing plugin API (for example VST or NPAPI) then obviously plugins built for that API can't be held to the licensing of one particular host application. On the other hand, if said API is specific to the GPL application then the GPL applies (for example Linux kernel device driver interfaces). I'm not sure if it's ever even happened, but it's interesting to contemplate the possibility of a proprietary application implementing compatibility with an existing GPL app's plugin API.
  - bombcar 5y ago
    It’s down to the definition of “derivative work” and the FSF may not have it legally correct (they may be overstating what can be considered derivative from a legal viewpoint) - as it has never reached litigation we don’t have a final solid answer. And even if it did we’d only have a precedent that may be hard to apply.
Xylakant 5y ago
But it's clearly not as simple. The GPL triggers on distribution of the combined work - the user is free to link GPL'ed and other code with incompatible licenses as long as they do not redistribute. For example, the kernel modules for VirtualBox are distributed in source form under a commercial license and need to be compiled on the users box against the kernel header. Distributing the modules in binary form would likely be a violation, as would be distributing OBS with the closed source plugins - but that's not what happens here. So the GPL only triggers when a work incorporating GPL code is distributed, so the question here boils down to "does the plugin itself contain GPL code" and not to "can it be loaded into a GPL'ed program on the users computer." The GPL does not and cannot force a license on some piece of software that only implements an API - it can only affect software that directly incorporates code. Think about it this way: If the mere ability to be loaded as a pieces of software into a GPL'ed program is sufficient to force the piece of software under GPL, then I could just write a small GPL program for any piece of closed source software and force it under GPL. That clearly doesn't work.
- tyingq 5y ago
  >so the question here boils down to "does the plugin itself contain GPL code" and not to "can it be loaded into a GPL'ed program on the users computer." I don't think it's that simple either. You mentioned the Virtual box kernel modules. There's plenty of discussion, some from Linus that some kernel modules are "derived works of Linux" and some are not. The binary Nvidea kernel drivers had to skip using a zero-copy DMA feature because of this, even if they shipped standalone. I suspect the same situation exists here. OBS, for example, has some very specific structs, header files, api functions, and other ways of interacting with plugins. A plugin made to work with OBS could very well be a derivative work, regardless of whether it ships with OBS or not. Distribution of the derivative work alone triggers the GPL in that case.
  - Xylakant 5y ago
    I’m not saying it could not be. I’m saying that a cursory search of the internet provides no substantial allegation that this is the case - and the article just asserts so, without any further citations or discussion.
ranger_danger 5y ago
The GPL only applies when you're redistributing a program or its code. A plugin that is downloaded later, and not necessary for the basic function of the program itself, while at that point could technically constitute a combined work, typically just sits on your computer forever at that point. Only if you were to then re-redistribute both that program AND the downloaded plugin, then there is a possibility of a GPL violation if the license of the plugin is incompatible.
- outsomnia 5y ago
  If the plugin itself has no function or meaning standalone, without being linked to the GPL'd work, it's considered by the GPL to be a "derived work". And at least on GPL v2 that OBS uses, it operates at the point of "distribut[ing] or publish[ing]" that. v2 sect 2b You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. https://www.gnu.org/licenses/old-licenses/gpl-2.0.html https://www.gnu.org/licenses/old-licenses/gpl-2.0.html