Hacker News Reader

Comment by Jonnax | Hacker News Reader

Can someone provide some context for this post?

Are there calls to change Blender's license?

Are add-on developers violating GPL? The post mentions that a bridge between open source and proprietary needs to be open source but the add-on itself doesn't?

Is it just a "how dare you sell products closed source products on top of blender?"

The business model of providing support is all well and good but it's just one. If the software is super easy to use then why would you pay?

View on HN

Somebody recently launched a new site "Blender Depot" which hosts a bunch of Blender add-ons and provides a batch install feature.

Some of the add-ons on this site are commercial plugins available for sale by their authors. All Blender plugins have to be GPL so this sort of redistribution is legal but some of these authors have been rather upset about it. So a large argument ensued on the Blender forums about the GPL, the ethics of software redistribution even when copyright law says it is okay, etc.

So the classic case of "I chose GPL because everybody chooses GPL because it's the most used licence but I forgot to read what it actually says and I'm upset"

I suspect not so much I forgot to read then "I hope nobody is gonna use parts of license I don't like, oh shit" e.g. wanting it both ways.

Well, to be fair, I've been there myself. It's an eye opening experience to put it mildly.

I think the referenced forum discussions are [0][1] for anyone else trying to find them?

[0] https://blenderartists.org/t/introducing-blender-depot-brows...

[1] https://blenderartists.org/t/yet-another-discussion-about-th...

Thank you for providing the context.

I don't think using an API of a GPL software means your software "has to be" GPL. For example, not all software running on Linux using Linux APIs (syscalls) is GPL.

It's an area of open legal debate, with a spectrum of what it means to be using an API and what constitutes a derived work.

From what I can see, Blender is trying to pretend it's a hard-and-fast rule, and they are requiring addon authors to label their work as open source to sell on their store.

> From what I can see, Blender is trying to pretend it's a hard-and-fast rule

Well yeah it's a debate - I guess this is their side of the debate. Arguing for something isn't 'pretending'.

I think if it did mean that, Linux would be abandoned by most major companies overnight, as you could not develop non-GPL binaries for it; I do however believe Blender is in the wrong here.

>I don't think using an API of a GPL software means your software "has to be" GPL.

We should GPL the software that is calling the Api of the GPL software.

>not all software running on Linux using Linux APIs (syscalls) is GPL

This is because linus Torvold(Other contributors) has given the syscall exception along with GPL-2.0. That's why there exists all kind of proprietary software running on top linux os.

Note: I am an open source officer I deal on this topic very often

Linux has an explicit exception in its license so that user space software doesn’t fall under GPL. https://github.com/torvalds/linux/blob/master/LICENSES/excep...

> NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of "derived work".

That's not an actual exception but a note clarifying what the GPLv2.0 covers.

Linux’s exception is because you need its header files to compile c code that uses the kernel. If someone created an extension that provided a json api to blendr, it seems that would need to be open source but callers would not since nothing would need to be compiled against gpl code.

Whether or not "using an API" requires your software to be GPL depends on how it's implemented.

Going by GNU's description of what does and does not extend the GPL requirement[1] and how Blender plugins works, to me at least it seems they very clearly have to be GPL. Unless someone took the route that is common in closed source Linux drivers of having a small open source module that communicates with a binary blob where the majority of the actual interesting code is, but I have not seen any Blender plugins like that.

The Linux kernel actually provides a specific license exemption[2] for the headers that makes software using syscalls not bound by the GPL.

[1] https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins

[2] https://www.kernel.org/doc/html/v4.18/process/license-rules....

Actually this is exactly what we did with the renderman addon for Blender. And AFAIK how other renderer addons work.

Frankly if you want to be doing any meaningful computation in your addon it probably makes sense to go this route and have the closed source part in C while the addon "bridge" is python.

I remember such story with «Blender-OSM» addon by Vladimir Elistratov.[0]

[0] https://github.com/vvoovv/blender-osm/issues/42

Maybe all the confusion seen in this thread about what does and doesn't fall under GPL is the reason people take issue with it, moreso than what it actually does.

Sounds similar to the argument about WordPress, third-party plugins, and the GPL from a while back.

> Some of the add-one on this site are commercial plugins available for sale by their authors. All Blender plugins have to be GPL

Just a side-note about the distinctions between open-source, free software, and commercial software. The US government considers any software that has a license and is available to the public “commercial”. So all GNU software in their view is commercial. It’s not a legal distinction of whether money is charged, it’s whether the software has a license and is public.

U.S. law governing federal procurement (U.S. Code Title 41, Chapter 7, Section 403) defines "commercial item" as including "Any item, other than real property, that is of a type customarily used by the general public or by non-governmental entities for purposes other than governmental purposes (i.e., it has some non-government use), and (i) Has been sold, leased, or licensed to the general public; or (ii) Has been offered for sale, lease, or license to the general public ...".

https://dodcio.defense.gov/open-source-software-faq/#Q:_Is_o...

i noticed the same problem with the use of the term proprietary because that simply means non-standard. there is plenty of non-standard Free Software. and there is also plenty of commercially sold Free Software (RHEL for example)

the only term that i am aware of that really works is non-free.

"commercial software" has a well-used and generally accepted definition, regardless of how the DOD procurement rules define the term.

as more and more companies sell FOSS licensed software, that definition is going to change. commercial software as the opposite of Free Software worked as long as the majority of Free Software products were generally free as in beverage in addition to having a free license. "Commercial Open Source" is a thing. https://en.wikipedia.org/wiki/Commercial_open_source_applica...

> Some of the add-ons on this site are commercial plugins available for sale by their authors. All Blender plugins have to be GPL so this sort of redistribution is legal

Only if the people between blender depot has a copy distributed under the gpl? Granted, the most likely way they'd get a copy would be under the gpl (get a copy from someone that purchased the plug-in).

But it does not immediately follow that its trivial to legally redistribute the latest copy of a gpl plug-in, unless you purchase new versions as they are released.

Thank you for providing this context.

> All Blender plugins have to be GPL

Didn't the blog article just point out an obvious loophole of turning the addon into a bridge to an external non-GPL module, and putting some critical functionality into the non-GPL part?

Of course, developing such addons will be harder, but even moving just some pointless, trivial, easily rewritten code to the non-GPL part would force people who want to redistribute it to rewrite that part.

Or even completely subverting the spirit (but probably not the law) of the GPL by building a small non-GPL "DRM server" that is called and checked from the GPL'd module, and having the open source part refuse to work if this server isn't present? Of course, anyone would be invited to take the GPL'ed code and remove the checks, but it would shift the cost from "redistribute the version for free" to creating and maintaining a fork, which might be enough to get people to pay instead.

I think this is for the recent surge of quasi-open-source license changes some products have gone through. That's why they underline the difference between free software and open source.

Recently people started saying that the OSI's Open Source Definition is restrictive and obsolete, that having the sources available is enough, that it's not a problem to restrict usage, etc... That's why it's important to stress "free as in freedom" in free software and not "open as in you can see the source" in open source.

In a world without intellectual property, source available would equal free software.

I think the FSF has tried to squash too many semantic, technical and legal subtleties into the GPL, the words free, libre, etc.

No it wouldn't, for software to be "Free software" it must be GPL-or-other-copyleft-license licensed, which aside from being trivially impossible in a world without intellectual property laws, also has different outcomes than placing the source in the public domain. For example nothing prevents me from taking some public domain code and including it in my closed-source application, but the GPL forbids this.

In a world without intellectual property, your closed-source application would be a trade secret that would quickly get out.

No, for free software to be "Free Software" it must respect the Four Freedoms (https://www.gnu.org/philosophy/free-sw.en.html). GPL-or-other-copyleft-license happens to respect them, but so do the Apache, BSDs, MIT and other licenses which are not copyleft.

Note: "Copyleft" as opposed to simply Free Software entails reciprocity, e.g., the "viral" part of the GPL. See https://en.wikipedia.org/wiki/Copyleft

>The post mentions that a bridge between open source and proprietary needs to be open source but the add-on itself doesn't?

The post isn't very clear, but they way I interpret it is that the Blender add-ons do have to comply with the GPL.

Furthermore, I don't think that's new. Look at the answer in January 2017 to this question [0] on Blender Stackexchange by Jaroslav Jerryno Novotny:

>Blender also includes the Blender Python API, so every piece of code of the addon that uses some Blender Python API must be also licensed under GNU. This only applies to the addon script files or binaries.

Later on, it's clear that compatibility with closed source programs is restricted to sharing files - that is linking is not allowed:

>But you can do something like commercial render engines do: the export plugin is GNU (uses Blender API) and converts scene data to commercial application (ie. renderer) which is not GNU (doesn't use Blender API) and the licenses differ. This works because the addon is not dependent on the non-GNU application.

[0] https://blender.stackexchange.com/questions/72095/license-is...

If you post a long statement like this article and the first response from people is "I don't know what they're talking about or referencing" then you know you've written it very badly.

Or for people who are familiar with your product and industry, and not a general audience.

I don't have any additional context, but the overall style of the post makes it sound to me like it could be talking about a change in the add-on API license or something (in addition to a general pro GPL post). This is the strongest evidence I have:

> I expect that all add-on developers recognize and respect this concept.

Reply on news.ycombinator.com