[Zope-dev] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> On Apr 21, 2008, at 12:58 PM, Tres Seaver wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Benji York wrote:
>>> On Mon, Apr 21, 2008 at 7:45 AM, Baiju M <mbaiju at zeomega.com> wrote:
>>>> It looks like today they changed their licence to GPL v3 !
>>> I don't know if that exclamation mark is of joy or woe.  I vote for  
>>> woe.
>> I don't know if woe is necessarily fight:  given that we are talking
>> about a component which is served separately from any of our Python
>> code, without even the (debatable) trigger of a Python import to cause
>> our code to be a "derived work", the "mere aggregation" clause is  
>> likell
>> to apply to distributing ExtJS with a ZPLed Python library /  
>> application.
> 
> We're not just talking about Python code.  We're also talking about  
> Javascript code.  We'll be providing JS code that runs in the browser  
> with and depends  on the Ext code. My library did and Paul's changes  
> did.
> 
> Reading the GPL3, The language is very broad.  It talks about works  
> "based on" GPL works being GPL.  In: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation 
> , the FAQ talks about programs communicating via interprocess  
> communication.  In particular: "But if the semantics of the  
> communication are intimate enough, exchanging complex internal data  
> structures, that too could be a basis to consider the two parts as  
> combined into a larger program."  It would be easy, IMO, and useful  
> for a Python framework to generate data structures that are meant to  
> be consumed by Ext.  For example, my from framework returns Ext field  
> definitions as JSON.

An application returning JSON data structures for consumption by the Ext
libraries would hardly be a "derived work" from Ext:  copyright doesn't
control that kind of integration, or else we would have to forbid use of
Python standard modules which provide interfaces to glibc.

The GPL can't control what copyright law does not provide for.  In
particular, copyright allows regulation of creation and distribution of
"derived works", but it does *not* allow the copyright holder to make up
arbitrary definitions about what makes a given work "derived" or not:
that would be up to the courts.

>> Having an unambiguous FOSS license on the code has to be good news for
>> those who would like to build and distribute such components.
> 
> I don't find anything about the GPL to be unambiguous unless I read it  
> with the broadest, most paranoid interpretation.

Compared with where the licensing was *before* they labeled it GPL3, the
clarity is vastly improved.

>>  ZMySQLDA,
>> for instance, is a ZPLed component which depends on the non-ZPL MySQL
>> client libraries, which doesn't seem to cause problems.
> 
> Good point.
> 
> I think we were sloppy here and it probably does cause problems.  I  
> think we probably should remove this from the repository.

I disagree.  The dependency is clearly on the presence / dynamic
linkability of the non-ZPL code, and does not appear to create a
"derived work" at all.

>> We *still* can't put the ExtJS code itself into svn.zope.org, but
>> perhaps we can now allow checking in ZPLed code which uses it.
> 
> 
> No, we can't.  I am willing to be overridden by the Foundation Board  
> on this.  Absent that, consider this an edict. :)

OK.  Nolo contendere.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIDSnJ+gerLs4ltQ4RAuzuAJ0X0b7DrNUN3/D5LFRbPqYQn9dbUgCZAcmb
WFuGNyc3deRq20PIc9zWceY=
=0sTf
-----END PGP SIGNATURE-----