Acceptable licenses for C++ addins
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I'm considering writing an add in for Fusion 360 in C++. I'd like to understand which licences my add-in can have. The header files for the API all lead with the following statement:
////////////////////////////////////////////////////////////////////////////// // // Copyright 2016 Autodesk, Inc. All rights reserved. // // Use of this software is subject to the terms of the Autodesk license // agreement provided at the time of installation or download, or which // otherwise accompanies this software. // //////////////////////////////////////////////////////////////////////////////
I'm guessing that this refers to the Autodesk LICENSE AND SERVICES AGREEMENT, especially the following section:
1.11 APIs. Licensee acknowledges and agrees that any API Information and Development Materials (unless otherwise specified by Autodesk in additional or different terms associated with such API Information or Development Materials) (a) are confidential and proprietary to Autodesk, (b) may not be distributed, disclosed or otherwise provided to third parties, (c) may be used only internally and only in conjunction with and for Licensee’s own authorized internal use of the Licensed Materials to which the API Information or Development Materials relate, such as the development and support of applications, modules and components to operate on or with such Licensed Materials, and (d) may only be Installed on the same Computer(s) where such Licensed Materials are permitted to be Installed. Notwithstanding the foregoing or Section 3 (All Rights Reserved), if Licensee develops any such applications, modules and components in accordance with this Agreement, nothing in this Agreement will prohibit Licensee from using such applications, modules and components with (and porting such applications, modules and components to) other software and hardware (including the software and hardware of third parties), if such applications, modules and components (i) do not incorporate or embody any Development Materials or other Autodesk Materials (other than the API Information that was used in the development thereof in accordance with this Agreement) and (ii) do not disclose the API Information. For purposes of this Section 1.11 (APIs), (A) “API Information” means the standard applications programming interface (“API”) information generally provided by Autodesk to licensees of the Licensed Materials that specifies the requirements for interfacing to (e.g., invoking or directing the functions of) the software included in such Licensed Materials; and (B) “Development Materials” means SDKs and other toolkits, libraries, scripts, reference or sample code, and similar developer materials included in the Licensed Materials. API Information does not include any implementation of such interface information, any Development Materials, or any other software, module or component.
I'm not very good at reading this sort of texts, but from what I understand I am allowed to build an add-in with the API header files, but I can't redistribute them. Is this correct?
I'm considering using libraries that have a GPL license, but my guess is that this is probably not allowed, since they would not only be linked with code compiled from the API header files, but also statically linked with the binary libraries in the API\CPP\lib directory. GPL would require all of these to be licensed under GPL, which clearly is not something I can do. Correct?
Furthermore, my add-in will be compiled to a .dll which is dynamically linked with the Autodesk Fusion 360 when I execute it. Again, I can't do that because this would require Autodesk Fusion 360 to be released under GPL, correct?
In the case of LGPL code, I still can't compile time link it to the libraries in API\CPP\lib, but I am allowed to isolate this code in a dynamic library and load it at runtime. Do you agree?
More permissive license such as MIT should not pose a problem, I think.
Please let me know how you see this matter.
Best regards,
Martin