rguetzkow
The argument is not that the API itself is protected by copyright. This wouldn't work anyway, as APIs aren't protected by copyright under EU law. From my understanding the argument is that the implementation of the API is protected by copyright. If the script/add-on for Blender depends on the `bpy` package (Blender's implementation of the API) and is not being able to function without out it, then it should be considered a "single program" based on the interpretation of the FSF provided in their FAQ [0]. Thus the script/add-on is derivative work and subject to the GPL license. This assumes that the interpretation the FSFs provides in their FAQ would hold up in court.
I do agree that the Python API is often just a thin wrapper around the C/C++ code [0] and that the documentation of the required context for operators is a bit lacking for people who are not familiar with Blender's implementation. This is also acknowledged in the API docs [1]. However, I do think the API is quite usable and not particularly complicated to understand.
[0] https://docs.blender.org/api/current/info_gotcha.html
[1] https://docs.blender.org/api/current/info_gotcha.html#why-do...
I can see that older scripts for 2.79 and earlier may cause the issue you're describing, but this doesn't seem like a Blender specific issue. How did Maya handle API changes between versions? I would assume that there were breaking changes at some point that caused similar issues.
When you have issues with calling an operator due to a wrong context, there are different ways to approach the problem:
1. Figure out what the necessary context is and switch modes, areas, etc. to match the requirements.
2. Figure out what the necessary context is and override the context.
3. Avoid using operators.
Approach 1.) could be accomplished by checking where the operator is originally used in Blender. For instance the `bpy.ops.mesh.remove_doubles()` is available in edit mode in the Mesh > Clean up menu. Thus edit mode is required to run the operator. This will work for many operators because they don't have very complicated requirements.
Approach 2.) is for when you must use an operator, it requires a complicated context and you know about Blender's internals. You can look at the operator's (poll) implementation and construct a specific context that is passed into the operator [0]. This should only be used if there is no better alternative.
Approach 3.) is preferable when you are working with mesh data. Instead of using regular operators you can use bmesh instead [1]. It doesn't require switching to edit mode or passing a context. It's usually the more efficient approach as well.
[0] https://docs.blender.org/api/current/bpy.ops.html#overriding...
All the API changes are also documented in the release notes [0] and the API docs allow to view the Python API for each version [1].
What change between versions caused you problems and what parts of the API docs were lacking?
[0] https://wiki.blender.org/wiki/Reference/Release_Notes [1] https://docs.blender.org/api/current/index.html
> I was always amazed at Maya's basic architecture: Every UI action maps to a command that is run by the interpreter.
That is pretty much how it works in Blender. All the buttons and properties in the UI are accessible through the Python API.
> CUDA 10.2 (Toolkit and NVIDIA driver) is the last release to support macOS for developing and running CUDA applications. Support for macOS will not be available starting with the next release of CUDA.
[0]: https://docs.nvidia.com/cuda/archive/10.2/cuda-toolkit-relea...
[1] https://www.blender.org/download/ [2] https://wiki.blender.org/wiki/Building_Blender/Linux/Arch
[1] https://www.blender.org/download/requirements/ [2] https://docs.blender.org/manual/en/latest/render/cycles/gpu_... [3] https://developer.blender.org/T75319
[1] https://www.blender.org/download/requirements/ [2] https://developer.blender.org/