I am not a lawyer and the opinions expressed herein are my own.
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.
The comment above is more of an explanation of how this currently works in Blender and how one can approach the aforementioned challenge.
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.
From my experience script examples usually indicate what version they were made for and add-ons have to declare the minimum supported Blender version in their `bl_info`, which tells what API version it was implemented for. I know that at least on Blender's Stack Exchange the community tries to provide updated answers if anything relevant has changed in a new version.
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.
That is specific to operators (Blender's implementation of buttons) since they are closely tied to their use in the UI. They may expect a specific context which is checked by the operator's `poll()` function. The namespace the operator is in should hint at what that context is, e.g. `bpy.ops.mesh` works with mesh data which is accessed in edit mode. Other operator namespaces directly reference area types, those need to be executed within that area. For instance operators `bpy.ops.view3d` will most likely require to be executed in an area of type `VIEW3D`. That is a requirement because the data that the operator needs is otherwise not accessible. I understand that the approach you are used to in Maya is more convenient.
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.
Unless the example is from 2.79 and earlier it shouldn't take any or only minimal adjustments. There have been some API changes between versions since 2.81, but they usually wouldn't affect a lot of add-ons or are very easy to change.
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?
Do you intend to use the GPU for rendering with Cycles? This isn't possible with current versions of Blender on macOS as Nvidia has stopped development of the CUDA toolkit for macOS and Apple has deprecated the OpenCL compiler. Since Cycles doesn't yet support Metal you cannot use GPU rendering on macOS. It is planned though and there are improvements being made with the Cycles X project. It is possible to use other render engines that support Metal though.
Sorry for the late reply. I assumed that your comment was about Blender given that you've commented on a post about it. I also assumed that the comment was directed at Blender because there have been plenty similar comments/questions w.r.t. CUDA support on Blender's Stack Exchange in the past. Since you were addressing CUDA in particular, that's what I did in my reply as well.
This isn't Blender's fault, Nvidia discontinued the development of the CUDA Toolkit for macOS. Version 10.2. was the last version released for macOS [0].
> 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.
I think there are quite a lot more developers contributing to the project than those employed by the Foundation or supported by developer grants [0]. However, the complex changes on the roadmap of Blender's development are planned and implemented by the core team.
The Blender Foundation is quite upfront about this though to prevent misunderstandings. It's directly addressed on the page that explains the license: https://www.blender.org/about/license/
I fully agree, it's both a fantastic software and community. I would also recommend it to everybody who is interested in contributing to open source software.
This year is a bit unusual and secretive to provide a bit of a surprise. The past conferences had a proper schedule, see e.g. the one from last year[0].
Thank you for reporting bugs and helping improve Blender! Every AMD graphics card that is GCN first generation or later can be used for running Blender [1]. GCN second generation or later is required for GPU rendering [2]. Unfortunately the AMD Radeon RX 5700 XT does seems to be affected by some technical issues, that are still under investigation. Might be a bug in Blender or an issue with particular OS, hardware and driver combinations. See ticket T75319 for updates on this problem.
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.
[0] https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins