Theirs a java blender converter library that I was interested in.
But the license can only be decoupled to to the point of being Apache 2.0 license if you leave out the blender documentation. Not a problem there.
The reason for the different licensing is, that parts of the documentation are copied from Blender source code and Blender is published under GPLv2. Thus, the documentation is derived work and has to respect the terms of Blender’s license.
The different licenses mainly affect redistribution of work based on the documentation files. This means, if someone redistributes work which includes the original or modified documentation files or source code which contains parts of the documentation files (such as comments in generated facade classes), then this work has to respect the terms of the GPLv3.
Thus, if you consider redistributing derived work under a different license compatible with the Apache license of the SDK, than you just need to generate facade classes without Javadoc comments.
There is the “Derivative Works” comment that confuses me from Apache license which I interpret to mean anything that touches their license must be free to use include a copy of the license.
“Derivative Works” shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
How compatible is Apache 2.0 license with BSD 3.0?
The BSD license is another highly permissible license that allows you to modify and redistribute software licensed under the BSD license as you like. Earlier versions of the Apache License were identical to the original (and later the modified) BSD licenses, but Apache License 2.0 sets them apart. The key differences between the two licenses are:
Explicit grant of patent rights: Apache License 2.0 explicitly lays down the grant of patent rights while using, modifying or distributing Apache licensed software; it also lists the circumstances when such grant gets withdrawn.
Clear definitions of the used concepts: Apache License 2.0 explicitly defines all the terms and concepts that it uses. This leaves little scope for ambiguity.
Reusable without rewording: Apache License 2.0 can be easily used by other projects without any rewording in the license document itself.
In theory it should be fine. Both licenses would have to be included in the resources or whatever.
Easier still if we deprecate jme3-blender and move it to a separate project in jme-contrib… let those maintainers worry about licensing. Then we can stop confusing new users that converting from .blend is even a desirable thing.
Yep, I am not sure exactly how to implement it yet and will figure it out when I get there but I am thinking if this library is viable then it could just be a jme project listed in the jme store.
Does that sound like the right way to go?
Edit: I read your comment in the other thread and that makes sense to just go with GLTF and just remove blender altogether. Using your j3o converter will make things even easier so…
A lot of work went into the blender importer and I know it has its fans. I just don’t think it should be the tempting default choice for new users… and at some point we should scrub our wiki to make sure we don’t point new users in this direction.
I can do that and just keep the blender examples that are just demonstrations of using blender to create things for jme since those seem to have value. I can make them exporter agnostic with links to exporting.
“When” is up to you. I’m fine with “now”… given that like 90% of forum traffic in the last couple weeks seems to have been “I’m having trouble importing assets” issues… and always ends up being a .blend issue.