[Bf-committers] extension clause
blend.factory at gmail.com
Sun Nov 14 21:34:14 CET 2010
I don't see any benefits for Blender if it would be "easier" for Silicon
Valey guys to link their proprietary code with Blenders code. After all we
all see how they are protective about their legal rights and some of them
make their living by suing people around for all kinds of infringements. But
I also don't see any problems for them to write and use some extension for
Blender as long as that extension doesn't have any GPL code inside it.
I think that this line of License is pretty much clear:
"IF IDENTIFIABLE SECTIONS of that work ARE NOT DERIVED FROM THE PROGRAM, and
can be reasonably considered independent and separate works in themselves,
THEN THIS LICENSE, and its terms, DO NOT APPLY TO THOSE SECTIONS WHEN YOU
DISTRIBUTE THEM AS SEPARATE WORKS."
After that one more sentence says this:
"Thus, it is not the intent of this section to claim rights or contest your
rights to work written entirely by you; rather, the intent is to exercise
the right to control the distribution of derivative or collective works
based on the Program."
On 14 November 2010 05:35, Matt Ebb <matt at mke3.net> wrote:
> On Sun, Nov 14, 2010 at 12:19 PM, David Jeske <davidj at gmail.com> wrote:
> > I think my post was mis-interpreted. I'm not trying to discuss the point
> > commercially distributed binary extensions.
> Another issue related to this is the ambiguity of connecting blender
> to non-GPL code, even if the plugin/extension code that connects it is
> This seems to preclude ever being able to a plugin based (i.e. DLL/so)
> renderer connection to any non-GPL render engine, like Vray or Arnold
> for example, even if the connection code/plugin is GPL. From what I
> understand the mere fact that somewhere along the line a header may be
> included from a non-GPL source, will cause the whole thing to break
> down in the eyes of licensing.
> It's also quite inconsistent in the 'spirit of the license' since in
> terms of licensing similar functionality is perfectly acceptable if
> for example you use python to export to a renderer via a scene
> description format (except of course it can be slower and not as
> powerful for other kinds of functionality).
> To me this is not even a matter of 'keeping blender free', since
> blender's code base itself wouldn't really be modified, and even if
> the connection code is GPL, it still wouldn't be allowed since it
> links with a non-free library.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers