[Bf-committers] extension clause

Doug Ollivier doug at flipdesign.co.nz
Wed Nov 17 21:19:46 CET 2010

I'd like to propose something that will remove the *other factor* in 
this equation, "the donated time factor"

It seems apparent that some coders feel it unfair if they donate time to 
Blender for the common good, and another coder comes along and creates a 
plugin that is commercial: Well fair enough, it does seem quite unfair!!

I propose that Blender.org tackles this issue early by taking on the 
role (based on existing business models like app stores) of being the 
distributors of commercial plug-ins.  I.e. the Blender.org website 
becomes the central repository and payment system to manage and purchase 
commercial plug-ins, and in doing so can create an opportunity to take a 
percentage (even a reasonable one like 30%) of the sales price and feed 
it back into the development of Blender.  Win-Win situation for everyone.

If tied closely with the Blender Plug-in/Extension manager, this would 
provide a very easy way for users to extend Blender for niche usage, 
pull in commercial developers, while maintaining the integrity of the 
community approach.



On 18/11/2010 2:11 a.m., Ton Roosendaal wrote:
> Hi all,
> I have good connections with other OS Foundations and FSF, practical
> experiences with how corporations manage (or not) to us GPL I can try
> to gather. Also best practices in what's accepted to be legal for
> companies is interesting to hear more of.
> In discussions at Siggraph with some people working in studios, they
> mentioned to have solved it by creating a fully separated "open
> domain" for software, vs their own "closed domain". The code in these
> domains are never allowed to be mixed up. The open domain is not
> allowed to use or link to anything from the closed domain, however the
> closed domain can link to modules in the open domain (but without
> copying any code).
> This practice was mentioned (by a marketing person) to allow a
> "community outreach" as well, the open domain can always be safely
> published and spread. Improvements or changes in code then can benefit
> the free/open projects, and vice versa. In panel discussions Disney,
> Sony, Dreamworks and ILM seem to be open for such models.
> It doesn't solve all issues, but it's a simple method for corporations
> to review as a way how to be legally safe with using a GPL program.
> -Ton-
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> On 15 Nov, 2010, at 21:39, David Jeske wrote:
>> I apologize in advance for the long post.
>> (1) @ Ton : this is not a perception issue, this is the current legal
>> interpretion of the GPL. It is not legally okay to write, use, or
>> distribute
>> binary code modules that links directly with, and is dependent on,
>> GPL code
>> without triggering a need to GPL that code. In addition, doing so
>> implicitly
>> licenses all applicable patents to the community. In short, it's not
>> legal
>> to write a closed-source extension for a GPLed package such as GIMP or
>> Blender. I believe this will hurt Blender's long-term prospects for
>> adoption. I don't know what solutions are possible (if any), but I
>> think
>> it's important to figure out. Carving out an LGPL extension API
>> (something
>> that would not require relicensing of existing code) might fix this.
>> This Blender "faq" is naively incorrect and should be fixed...
>> *Can my organization use Blender internally without giving up our
>> valuable
>> changes to our competitors? The GNU GPL does allow your organization
>> to use
>> a modified version of Blender internally without offering the source-
>> code as
>> long as you do not distribute it outside your company or
>> organization.*
>> *
>> *
>> There are many problems with this interpretation, both legally and
>> practically. I'd like to stay out of a huge legal debate about the
>> GPL, so
>> I'll just point out the practical problems. The practical realities of
>> "distribute" and "organization" are too constraining.  Companies
>> today work
>> with contractors, third parties, outsourcers, etc, which are
>> technically not
>> part of the "organization" but which help produce the work. People
>> are not
>> puppets, and companies do not have enough control to assure that
>> nothing is
>> ever "distributed", thus triggering the need to GPL and open-source.
>> Which
>> causes companies to refuse to accept any GPL code into their source-
>> control
>> or development pipeline.
>> These and many other factors mean this should read:
>> *Can my organization use Blender internally without giving up our
>> valuable
>> changes to our competitors? 3d models and data produced by blender
>> can be
>> output in a variety of formats and may be kept under any license the
>> author
>> chooses. Changes to blender source code are governed by the GPL and
>> must be
>> distributed as required by that license. *
>> This gets blender out of the situation of being wrong about
>> interpretion of
>> the GPL, as it simply defers to the GPL.
>> (2) As Lorenzo excellently explained. This is not a discussion about
>> allowing commercial companies to use blender code in their own
>> products.
>> This is a discussion about allowing commercial companies to use
>> Blender,
>> become part of the community, and contribute.  John Grant very
>> eloquently
>> explained the issue in the form of his specific example. I'd like to
>> quote
>> his words here to reinforce them..
>> *"Because there is no protection for companies that want to extend
>> Blender,
>> I can not recommend we use Blender in our work processes.  Since we
>> can not
>> develop tools that integrate with Blender, we have been forced to
>> integrate
>> with Autodesk tools.  Our clients are familiar with the Autodesk
>> tools and
>> are happy about our choice.  The Blender community has lost a chance
>> to
>> introduce itself to our clients."*
>> *
>> *
>> As an interesting datapoint. GIMP is under the GPL, and has these same
>> limiting issues (no commercial extensions), and yet companies are
>> "selling"
>> gimp for their own profit, because nothing about the GPL disallows
>> this.
>> They simply package and sell it, source included. Being under the
>> GPL does
>> not prevent this.
>> (4) Linux is not entirely built of GPL code as it would lock out
>> commercial
>> involvement. They smartly use LGPL and draw boundaries so the
>> community can
>> still build a healthy ecosystem of open-and-closed source tools around
>> it. In fact, using Blender on Linux is in part practical because
>> xfree86 is
>> not under the GPL, facilitating binary 3d drivers from NVidia to be
>> used on
>> Linux.
>> A 3d tool like blender is not like gcc. It is not an isolated tool
>> that
>> exists without in-address-space extensions. In order to make good
>> use of 3d
>> tools in a pipline, software is frequently built and intergrated
>> with it as
>> extensions.
>> (5) Several folks here have brought up the point that it may be
>> difficult
>> (or impossible) to do anything to alter Blender licensing, even if
>> there is
>> a good alteration that could be made. I understand this point, and
>> will
>> offer that it will only get harder as time goes on. I revived this
>> discussion because I'd really like to see Blender become a tool on-
>> par with
>> Maya, 3dsmax, and others. I don't believe this will happen unless
>> commercial
>> companies can use proprietary code in extensions without legal fear
>> of the
>> GPL -- because that positive feedback cycle will bring more
>> professional
>> users and developers to Blender.
>> (6) To followup on Lorenzo's excellent suggestion for specific
>> examples...
>> Pixar authors the Renderman rendering engine. They also have their own
>> modeling/animation tool called Marionette. They use Maya and Max as
>> well. It
>> would be very scary for them to link renderman into Blender, because
>> of
>> potential GPL issues. They might have animators that use Blender to
>> kick out
>> a model or edit verticies, but it would be legally scarry to
>> integrate it.
>> Electronic Arts primarily uses Maya for modeling and animation. They
>> use proprietary and 3rd party tools for handling components, such as
>> compressed-textures, compressed-animated-meshes, and physics. These
>> components are integrated into their 3d tools environment, and also
>> licensed
>> commercially for inclusion into their distributed games. It is legally
>> dangerous to integrate components like this into Blender for their
>> own use,
>> because of the strictness of the GPL. Again, this is the reason libc
>> is
>> under the LGPL instead. It assures the freedom of libc without
>> trying to
>> contaminate all other code that links with it.
>> In game companies in general, it is common to integrate game-engine
>> renderers into the 3d modeling environment, so artists can see assets
>> rendered as they will in the game engine. This is legally dangerous
>> if the
>> 3d tool is under the GPL and the game engine is closed source.
>> - studios:
>>> studios are (usually) only interested in spitting out frames at the
>>> highest
>>> quality and in the most efficient possible way. They develop an
>>> incredible
>>> amount of software internally, but are not interested in selling it
>>> outside
>>> because it would take too much hassle to polish it enough for
>>> selling...
>>> it's more profitable for them to work on the next movie! But
>>> sometimes they
>>> do distribute it outside, and when they do is almost always as open
>>> source:
>>> http://opensource.image-engine.com/
>>> http://opensource.imageworks.com/
>>> http://www.disneyanimation.com/technology/opensource.html
>> These examples reinforce my point. They are tools written around
>> commercial
>> packages. What they are doing is similar to writing photoshop
>> plugins (i.e.
>> plugins for existing commercial software). There is no concern that
>> the
>> licenses for these commercial packages can force them to release
>> their code
>> before they decide to open-source it. Of course when that time
>> comes, they
>> are free to do so. This is a demonstration of the positive cycle of
>> community contribution that can come when companies develop around a
>> tool
>> (such as Maya, Houdini, etc.)
>> This is similar to the GIMP plug-in issue. Many interpret the GPL to
>> mean
>> that GIMP plug-ins must be GPL as well. (i.e. they are not
>> independent and
>> seperate, because they depend on the GIMP plug-in API) GIMP tries to
>> support
>> commercial Photoshop plugins to get access to the functionality. It
>> doesn't
>> work well and will keep GIMP always in Photoshop's shadow. There are
>> many
>> reasons these companies don't provide plugins for GIMP, I believe
>> one of
>> them is GPL contamination licensing issues.
>> -------
>> Separate these key points and consider for yourself...
>> (a) will Blender benefit from having more users / developers, in
>> particular
>> those professionals at VFX and gaming companies?
>> (b) will Blender benefit from having VFX and gaming companies be
>> able to
>> standardize on and build around Blender?
>> If your answer to these these points is "no", while I can see your
>> perspective, it's not one I share. If your answer to these questions
>> is
>> "yes", then recognize that the current straight GPL license is a
>> roadblock
>> to these things happening. Can we come up with creative solutions?
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list