On commercial forks FOSS projects | Hacker News Reader

On commercial forks FOSS projects

drewdevault.com

83 pointsals029 comments

Streamlabs is not an illegal commercial fork. They violated the trademarks of OBS but not GPL. The code was always available https://github.com/stream-labs/streamlabs-obs

Bringing up together with what TikTok did is kinda dishonest

It's also quite prominently displayed on https://streamlabs.com/

https://streamelements.com/ appears to be a different thing than StreamLabs, and StreamElements is what the article references as a violation.

StreamLabs is only mentioned as part of the ecosystem that would benefit from commercial collaboration in the FOSS process, alongside vanilla OBS users.

Article got updated it was there when I've read it but now removed, see the archive

>recent (and illegal) commercial forks of a popular FOSS streaming platform called OBS Studio by companies like TikTok, StreamLabs

https://web.archive.org/web/20211218121304/https://drewdevau...

Ah, gotcha. Agreed with your initial comment, and glad to see the article appears to have been amended to match.

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

>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.htm...

How exactly does that work, what if the plugin was created before the program?

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.

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.

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.

>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.

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.

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.

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

I would argue that the kernel community with their very lax attitude toward GPL violations (let's not sue them, because all those "poor" companies are really not doing this intentionally and we don't want to alienate them) has contributed to the rampant disregard for OSS licenses from commercial companies. If there was real economic consequences companies would think more thoroughly about following licences.

It's weird that StreamElements is getting dragged into these discussions. TikTok is involved in a copyright issue. StreamLabs was involved in a trademark issue. StreamElements is in the same industry as StreamLabs, but offers OBS integration through a plug-in.

A strange article that focuses on a straw man instead of the core problem.

> The understanding of intellectual property among gamers and the companies which serve them differs substantailly from that of free software, and literacy in the values and philosophy of free software among this community is very low.

This is plainly false. Game devs are thoroughly aware of IP law, and the huge variety of licensing contracts and obligations. I mean, we have to be, otherwise we'd be having constant problems with software and business partners on one end, and with internet randos stealing and cloning our work for their own benefit the other hand.

And OSS licenses are typically the least complicated ones - and the values of OSS are very well understood, and many game companies contribute what they can as well.

So what's the real problem here? It's that a huge international video streaming conglomerate decided to intentionally violate software licensing conditions, in order to get a product to market faster.

This was not an accident due to "lack of understanding". Maybe it was a case of "get it to market first, we'll swap out that component later"? Or maybe "go ahead and bundle it in, nobody will be able to sue us in our jurisdiction"? Who knows.

But throwing gamers and game developers under the bus, just because some games-adjacent megacorp is behaving badly, is a really weird look.

> throwing gamers and game developers under the bus, just because some games-adjectent (sic) megacorp is behaving badly

oohhhh not sure about that - games are a team sport, even for "loner" game devs. The strange bedfellows of publishers, engine/tooling makers, and wild-eyed coders and artists is not new.. the personal actions of game developers, let no one tarnish their intelligence! cheats on FOSS license, you bet it happens IMHO

I'm saying that doing something like compiling a flagship OSS application into your core product doesn't happen accidentally due to a "misunderstanding" when you're a huge corporation.

P.s. thanks for the typo - fixed!

TikTok and other companies only represent the ethos of the modern society: take whatever you want, give nothing in return.

> TikTok and other companies only represent the ethos of the modern society

I'm not sure this is a modern phenomena.

More discussions in this thread:

https://news.ycombinator.com/item?id=29592103

tldr; if you fork gpl code, you have to gpl your fork.

People love to hear themselves talk, myself included.

I don’t think that’s quite correct. you need to publish the software before this kicks in. If you fork a web framework and build a website with it for example you don’t have to GPL the website. If you sell or make the fork available then it does, is my understanding.

A tree falling in the forest can either make a sound or not.

If someone is looking however, it must emit a sound.

In that sense your criticism is a vacuous one.

The website would be GPL, but since you're not giving anyone binaries you also don't have to give anyone the source.

Distribute is the key word. In general, companies can fork GPL code to power the backend of public or internal services, without being required to publish their modifications, but once they distribute the software (allowing binaries/scripts to be downloaded, including it in app, embedding it in firmware...), then they must open up the source.

You do if the license is AGPL 3.

Reply on news.ycombinator.com