@YAFU To be clear. I think you are not very clear about the difference between ‘code collaborations’ and code contributed by developers hired by the BF. For me there is an important difference.
Contributor: person who works for 8 hours in a paid job, and dedicates a few hours of his free time to collaborate with Blender. Technically, for me, this is collaboration and, of course, they have my respect.
Developer: person hired by the BF to develop a specific area of Blender. This for me is not collaboration, it is simply doing paid work. Of course, they have my respect too.
Having said that. Tell me, is Campbell a collaborator or a worker?
Cheers…
GPL does not change at all depending on someone is a collaborator, contributor, worker or whatever you want to call it. So I still don’t understand where you want to go.
But since you ask, Campbell contributed to Blender even before he was hired. And when he was hired, he even contributed in spare time on weekends, like many other Blender developers.
From the moment that Luca participated in the thread respectfully giving his point of view, we should let (myself included) that now the discussion does not go to secondary issues and let those who know the most about licenses continue to argue about whether what he expressed is correct or not.
1 Like
The official Blender Foundation stance is to align with the Free Software Foundation (both USA and Europe) and the Software Freedom Law Center. They are the experts and should come with answers and guidelines.
Blender’s principle is very simple - to contribute to the freedom to use, share and build 3D software tools. Any effort to take that freedom away is against the principles. That is not a discussion topic or an opinion, it’s the founding statute of the Blender project. Anyone who wishes to contribute to Blender is meant to accept that.
24 Likes
Regarding this:
I respectfully disagree with your point about fair use, here’s why:
There is a fundamental difference between reimplementing a similar api and using an existing one.
When you use a function in an api you use the code someone else wrote in your own code.
I really don’t think this can be seen as fair use.
I’m glad to see the responses, and to see that we can have a logical and respectful discussion on this subject. And kudos to @LazyDodo for keeping things on track!
I’ll reply to some individual posts below.
1 Like
500 words or less be great, just saying 
2 Likes
Thanks for this response! I’m glad to see people taking the time to think and analyse matters themselves!
As you noted, I am indeed very passionate about this matter. I have been invested in open source and digital freedom for several years (as are many other people in this community, of course), and dissecting copyright law and licensing is a big part of the effort.
You fairly point out that some of my opinions are stated as facts, and while that was not my intention, it’s hard to write so much without phrasing some things that way (otherwise it could have been even longer). That’s why I ask people to treat my text as an opinion, and invite everyone to do their own independent research. Thanks for acknowledging that!
And of course, what I’ll saying here, is again, simply my interpretation.
As for your point on bundling, yes, I expected such a response. I did skip over some logical steps, in the interest of “brevity” (however ironic that may seem). My point about bundling was tangential to my main argument, which is why I didn’t go into detail there. I am aware of the nuances of the “aggregate” clause, having read the license several times (I also had it open while writing, for referencing).
The thing with the aggregate nuances is that the works that they claim as exceptions to the aggregate “exemption” are the works that would already be considered a “larger program” and therefore already subject to the terms of the GPL (according to the FSF’s interpretation), even if it had not been bundled. Basically, the aggregate exceptions are somewhat redundant, as those works that cannot be bundled with a GPL licensed program, without also being distributed under the GPL, would already be subject to the to the GPL anyway (again, according to the FSF).
So I maintain that bundling does not change anything. I am saying that if we interpret copyright law such that a program is not subject to the GPL when distributed independently, it will also not be subject to the GPL when distributed in an aggregate, as it was not seen as a derivative (or was fair use) under copyright law anyway. Conversely, if we were to conclude that such a bundled program is subject to the GPL, then this program would still be subject to the GPL if distributed separately.
Basically, it boils down to the idea that what the GPL considers a “larger program” is bound by what a court would see as derivative work under copyright law.
Thanks again for your contribution to the discussion, and your moderation effort!
2 Likes
Haha, tell me about it! Sorry for the huge post, it wasn’t my intention, but it just kinda… Happened. I managed to keep my response to you just under 500! Even though I hadn’t seen this post yet
1 Like
That pretty much sums it up, and is not much of a change from before.
In the Oracle vs Google case, it was an independent piece of software that only re-implemented an existing API of a copyrighted work, but did not interact with it in any other way. A Blender add-on is not doing the same, it is not re-implementing Blender’s API, the API is there just the “common language” through with the add-on more or less tightly interacts with Blender to form a combined piece of software.
4 Likes
I am not a lawyer and the opinions expressed herein are my own.
I think the big issue with your interpretation is that, to the best of my knowledge, neither the SCOTUS ruling nor current EU law assert that plug-ins / add-ons aren’t derivative work.
The copyrightability of APIs and what is considered a derivative work are two separate questions. If APIs aren’t protected under copyright, as is the case in the EU, then your interpretation would imply that all software that has dependencies and interacts with these dependencies through an API would not be bound by the license of the dependencies. I don’t see a legal basis for that claim.
Firstly, an API re-implementation copies all the functions/data structures of an API, while a plugin only makes use of some of those APIs, meaning that the amount of copied material (remember, this is only about some function names) is much smaller, making it even more likely to be seen as fair use by a court.
Usage of the API is certainly not equivalent to implementing an API. The former makes use of the functionality provided, which is protected by copyright, while the latter does not.
The other thing supporting my interpretation, is that otherwise, a legal paradox would occur. […]
I don’t think there is any paradox. If there is only one dependency providing such an API, the derivative work is bound to follow the license of that software. If there are multiple dependencies under different licenses that provide the same API, the developer would choose the license of the dependency that is actually used (e.g. that of the library or host application). It would also be possible to release it under multiple licenses for each API implementation. Note that this is about the implementation of the functionality behind the API not the API itself.
I’d also like to point out that Blender’s current “official” position on the licensing matter contradicts itself. The currently accepted notion is that you can make a Blender add-on which consists of a GPL licensed Python portion, and a closed source binary, called by the Python code, as long as they are not shipped together. […]
It does not contradict the FSF’s position outlined in the GPL FAQ. If the closed binary is a standalone program that is called through a CLI by the add-on this would be acceptable according to the interpretation provided by the FSF. This is exactly the key point of when software is considered derivative work. I don’t know whether the FSF’s position on this has been tried in court, but I’m currently not aware of US or EU law that would invalidate this.
3 Likes
Thank you for contributing your perspective, Ton!
Let me repeat that I am also fully motivated by freedom, and the wish to foster a successful and open community around Blender and open source in general, as well as an interest in having a clear and unambiguous interpretation of the legal matters.
The founding principles of the Blender Foundation are not in question here at all. The interpretation of the law is a separate matter from statements of intention. Additionally, the law, as well as the software landscape are continually evolving, and seeing as Blender’s position on these matters has (understandably) somewhat shifted in the past, it is always good to reaffirm these things.
Even though a statement of intention from the BF is not legally binding, it is beneficial to the peace of mind of independent developers. I know that several such statements have been made, such as on Blender’s license page, however, there are still some inconsistencies and grey areas.
Would you mind clarifying Blender’s position on add-ons that ship a GPL licensed Python component, as well as a closed source binary (either separately or together), which is linked with Blender through the Python component? Some examples of such add-ons, which I’m sure you are aware of, are SpeedTree and KeenTools. It is my understanding that this would not be allowed according to the FSF’s interpretation of copyright law and the GPL.
If you do consider this to be fine, while considering that it’s not fine for the Python portion to be closed, could you elaborate on how this aligns with Blender’s principles, and contributes to software freedom?
Having a separately shipped closed source binary seems like an odd and trivial way to bypass the license with a couple of lines of glue code, which otherwise form a useless add-on without the binary. As I see it, either closed source add-ons are allowed, or not at all, even as a separately shipped binary (which I understand to be the FSF’s position). At least in my view, a middle ground doesn’t make much sense, legally, morally, or technically.
I thank you for any clarification on these matters, and hope you will see this discussion and clarity as beneficial for the community.
2 Likes
I have asked the FSF on a final word in this, already long ago. Recently I’ve reminded them about it.
For as now, the bottom line is:
- if you share Blender binaries, you also share the full code for it as GPL (compliant).
- therefore you can not bundle non-free libraries/modules with Blender. Not even in one archive (zip). Keep it entirely separated.
Anything is OK that will keep Blender open and free, for any purpose, forever. That’s what we stand for.
How to be creative in bypassing Blender’s user freedom is not of my concern. If a person or company insists on keeping their copyrights closed, and somehow combine that work with Blender, they will have to spend legal advice on how to do this well.
I will rely on advice from FSF and SFLC. If they see a severe GPL violation, they will act.
10 Likes
These points are all very similar, and are a common objection I’ve heard to my argument here, and elsewhere. So in this reply I’m trying to respond to all of you.
A plugin does not inherently target a specific implementation of an API. A plugin simply targets the API itself. A plugin is completely unaware of, and does not depend on any particular implementation of an API. A plugin only depends on having a host which provides the API it was developed for.
The functionality behind the API is not protected by copyright, rather, a specific implementation of this functionality is. The functionality is simply the idea of what something does, and ideas are not subject to copyright. The API is a way to interact with this idea of functionality. A plugin interacts with an API, no matter what implementation is behind it, it does not interact directly with any specific implementation of the functionality.
Note that I’m specifically talking about plugins here. A plugin provides some functionality on top of a certain API. Which implementation of that API the user chooses to combine the plugin with is not the developer’s concern.
I will accept this argument if you can point me to an add-on with a GPL portion and a closed source portion, where thy do not “establish intimate communication”. It’s also interesting to note that the FSF’s interpretation on whether or not something forms a single program is reliant on “intimate communication”, which could be argued to be the very definition of an API. At least in the EU, where we all agree that APIs are not subject to copyright, how can your definition of a single program rely on the very thing that is not covered by copyright being shared between the two components?
2 Likes
Thank you for the clarification. From this you seem to imply that you will not opine on licensing matters regarding things that are not shipped together with Blender binaries. That’s understandable, however, this is not what is stated on the website. Could this then be reflected on Blender’s aforementioned licensing page as well?
1 Like
Improvements for wording of parts of the license page will be checked on. It is meant to be simple and understandable for everyone.
2 Likes
An api is a way to interact with a specific and concrete implementation of an idea.
A plugin interacts with a specific api, case in point:
import bpy
And even if the code of a plugin might be able to work with multiple APIs, in practice your plugin will call specific functions from one api or another.
The point you make is valid when it is about something purely conceptual. Not when there is a concrete implementation.
Let’s say I describe, using Pseudo-code and the blender api, how to make a lens generator in blender. I can release this under any license I want because in this case I am really interacting with an idea.
However, if I implement my ideas, the code has to be gpl because it uses the actual api.
Earlier in this thread some people were curious about how a type of license could influence whether a developer contributes. My own feelings, which are of course different from every other human on the planet, goes like this:
“Do you accept money from businesses that will be profiting from your programming skills” - Yes I do!
“Would you consider spending spare time volunteering for free to help write a program used by artists, graphic designers, studios, and other professionals?” - No, I’ve got more enjoyable ways to spend my off hours.
“Wait, I forgot to mention that this will always be available to everyone for free, regardless of age, income, language, country, skill level, etc. We are democratizing 3D and giving it to the world!” - That sounds awesome, count me in!
“Oh, I should mention that some users would prefer that what you write can be taken by other corporations, made closed-source, and then sold by them” - Um, no thanks.
7 Likes
A plugin does not inherently target a specific implementation of an API. A plugin simply targets the API itself. A plugin is completely unaware of, and does not depend on any particular implementation of an API. A plugin only depends on having a host which provides the API it was developed for.
I would argue that this is not true in practice. How you use Blender’s API is very closely tied to the underlying implementation. There is a good reason why we have an entire page dedicated to the potential pitfalls of using the API without knowing a bit about Blender’s internal workings. Some caution is required by add-on developers not to cause undefined behavior.
The functionality behind the API is not protected by copyright, rather, a specific implementation of this functionality is. […]
That is precisely what I meant in my reply.
A plugin provides some functionality on top of a certain API. Which implementation of that API the user chooses to combine the plugin with is not the developer’s concern.
I believe this is does not accurately represent the situation both in theory and practice. The developer implements an add-on for a particular software which happens to provide an API. The add-on relies on the implementation of the host software, it is not able to function on its own. In my opinion this would fulfill the “single program” definition that the FSFs uses. If there is more than one software that implements the API and the developer want to release the add-on for all of them, it would have to be ensured that all respective licenses are honored. Possibly by publishing dedicated add-ons for each host software if their licenses are incompatible.
In the specific case of Blender, there is only one API implementation and developers intentionally develop the add-on for use with Blender. Their add-on code relies on the specific implementation of the API that Blender provides, with all its quirks, and cannot function without it. It seems that according to the FSF it would be subject to the GPL license.
In your opinion, where is the difference between an add-on using the API of a host application and a program using a library through its API?
I will accept this argument if you can point me to an add-on with a GPL portion and a closed source portion, where thy do not “establish intimate communication”.
In my opinion the Quad Remesher add-on would be an example that fits this category.
It’s also interesting to note that the FSF’s interpretation on whether or not something forms a single program is reliant on “intimate communication”, which could be argued to be the very definition of an API. At least in the EU, where we all agree that APIs are not subject to copyright, how can your definition of a single program rely on the very thing that is not covered by copyright being shared between the two components?
That is because there is a necessity to define what a program is, what the license applies to and what its limitations are. The copyright holder of the implementation is able to define the rights they grant to others through a license and under which conditions they do. Whether the conditions in the license rely on a concept that isn’t copyrightable on its own doesn’t matter. The copyright holder could also issue a license that requires potential licensees to give them a handshake in exchange for the rights to use the software. That concept is not copyrightable either. As long as the license doesn’t try to assert rights the copyright holder didn’t have to begin with, this shouldn’t be an issue.
If your interpretation would be correct that APIs not being protected by copyright would imply that code interacting with the API is not subject to the license of the API’s implementation, then you wouldn’t be able enforce licenses and copyright for software at all. Every code interacts with other code through some form of interface. Cases like Artifex Software Inc v Hancom Inc show that the GPLv3 is considered a valid and enforceable license in the United States. Welte vs D-Link was a case in Germany where the GPL license was upheld.
Edit: I would be very interested to know what EU court decision or law you’re basing your opinion on that add-ons/plug-in would (likely) not have to adhere to the license of the API’s implementation.
1 Like
I’m not going to get involved in the implications of this point, but wanted to highlight one thing:
import bpy is the very definition of an API. The host provides a thing that has a certain shape called bpy, I can call functions from it, and I trust that it will do what is described in the documentation of the API.
To drive this point home, one might write an addon for Blender, then write a ‘mock’ bpy module which is used for testing. It is entirely separate code which follows the same shape as the API, and by nature of it’s intended purpose, the application code is not aware of which bpy it is using. The only thing that is the same between ‘bpy’ offered by Blender and the one written for testing is the concepts in the API. If the developer released the mock bpy publicly, then suddenly Blender’s bpy isn’t the only ‘host’ in which addon code can run.
As Robert has eluded to, the difficulty comes into play when an API’s documentation allows for various interpretation, or it’s implementation doesn’t align with the documentation. I don’t know whether working around bugs or an undocumented API breaks ‘fair use’ or whether usage of an API falls under fair use at all.
I was about to write that. 
Quad Remesher seems like a fine example of how external proprietary code can work in Blender without breaching the GPL license:
Quad Remesher comes with a free Blender add-on that calls upon an external library from Blender once you start using it. The selected object is exported as an FBX, the closed-code auto-retopology algorithm is applied, and the result imported into Blender again via FBX.
2 Likes