[Bf-committers] extension clause

[Campbell Barton]

On Tue, Nov 16, 2010 at 1:41 AM, David Jeske <davidj at gmail.com> wrote:
> On Mon, Nov 15, 2010 at 1:58 PM, Dan Eicher <dan at trollwerks.org> wrote:
>
>> There's actually two issues being discussed here, the ability to use GPL'd
>> software *in house* and the ability to distribute non-GPL'd extensions.
>>
>> The first needs no license change at all, companies just need to be careful
>> not to release their (presumably extremely valuable) software into the
>> wild.
>>
>
> I've stated why my experience strongly disagrees with the above statement.
> Rather than state something as true which some here (myself included) feel
> to be patently false, perhaps you could provide some examples of companies
> that have gone down this path and how they arrived there?
>
> Perhaps this example will help you understand why the constraint to "be
> careful not to release" is not acceptable to companies.
>
> If an employee acts improperly and releases copyrighted code to a
> competitor, copyright law will prevent that competitor from using the code.
>
> If an employee acts improperly and releases a binary which contains both GPL
> and non-GPL code, the GPL says the source code must be released. There are
> no provisions for "withdrawing" the distribution. The moment it happens, the
> company is infringing the GPL and can face legal action. Further, if source
> code were improperly distributed, rather than be able to use their copyright
> of their own code to prevent it's use or distribution, the world can use the
> fact that it "is not independent and separate" from GPL code to argue that
> the entire code must be GPL and thus be free. This is too great a risk for a
> company to operate under.
>
> Again, in my experience, companies find it is not legally acceptable to link
> GPL code with closed-source code, for any reason. If you believe otherwise,
> I'm interested to hear examples of when you were in that decision making
> situation, and how you arrived at the decision to link GPL with propritary
> code "in secret". Anything else is just speculation.


@David Jeske, at least twice you point to The GIMP, as an example of
software that is limited by the GPL.
This in-fact is incorrect. The GIMP has already resolved this by
providing a LGPL libgimp which closed source plug-ins my link to.
Incidentally, does anyone know if this has helped the GIMP?, or know
of any commercial plug-ins on the market for the GIMP?.

* Companies are free to write their own closed source code that runs
in an external process, But this method also needs to have support
API's, docs and examples so companies are not doing their own R&D just
to write a small plug-in.
At some point I expect a company will fund BF or a developer to support this.

* As for a GPL exception, I'm not against this but expect its
difficult to do this. Id also be fine with a LGPL python api but this
uses internal blender libraries which I think will complicate things.

* Along similar lines to Matt, I'm more interested in blender linking
with closed modules, this would allow us to have a FBX importer (like
Wings3D can do because they are BSD), it would also allow integration
with commercial rendering plugins without having to mess with external
processes.

-- 
- Campbell