Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
Paul Carduner wrote:
Log message for revision 85449: creating a branch to see what I can do about extjs integration.
I found Jim removing two of his extjs related libraries from svn due to license issues (r85246, r85248). Please make sure that there is no license issue for your work committed to svn. Since extjs is released under LGPL, I guess you can release the library in a similar license, but only ZPL licensed thing can be committed to our svn :( /me wonder what will become a library and application from the pont of view of LGPL and Javascript. Regards, Baiju M P.S: CCed to zope-dev to see if there is any other opinion.
Previously Baiju M wrote:
Since extjs is released under LGPL, I guess you can release the library in a similar license, but only ZPL licensed thing can be committed to our svn :(
There is still an ongoing debate about that even - the extjs authors basically only want to offer LGPL to you if you meet certain criteria but won't allow you to redistribute it with just standard LGPL licensing. That and the fact that extjs produces insane html (11 nested divs for a simple table...) was reason for me to not use it. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Friday 18 April 2008, Wichert Akkerman wrote:
There is still an ongoing debate about that even - the extjs authors basically only want to offer LGPL to you if you meet certain criteria but won't allow you to redistribute it with just standard LGPL licensing.
I just researched this a little bit and can see why there is controversy. However, I cannot see why I cannot check code in that does something with extjs, because I might have paid for a license, but still want to contribute my code under ZPL. Since I am not modifying the library in any way, I do not even have to make the code LGPL. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Apr 18, 2008, at 14:09 , Stephan Richter wrote:
On Friday 18 April 2008, Wichert Akkerman wrote:
There is still an ongoing debate about that even - the extjs authors basically only want to offer LGPL to you if you meet certain criteria but won't allow you to redistribute it with just standard LGPL licensing.
I just researched this a little bit and can see why there is controversy. However, I cannot see why I cannot check code in that does something with extjs, because I might have paid for a license, but still want to contribute my code under ZPL. Since I am not modifying the library in any way, I do not even have to make the code LGPL.
Are you a lawyer? No? Thought so ;-) jens
On Apr 18, 2008, at 4:28 AM, Baiju M wrote:
Paul Carduner wrote:
Log message for revision 85449: creating a branch to see what I can do about extjs integration.
I found Jim removing two of his extjs related libraries from svn due to license issues (r85246, r85248).
Please make sure that there is no license issue for your work committed to svn.
Since extjs is released under LGPL, I guess you can release the library in a similar license, but only ZPL licensed thing can be committed to our svn :(
Because of ExtJS licensing issues, we should not check anything into the repository that builds on or requires ExtJS in any way. Jim -- Jim Fulton Zope Corporation
On Friday 18 April 2008, Jim Fulton wrote:
Because of ExtJS licensing issues, we should not check anything into the repository that builds on or requires ExtJS in any way.
I assume you got lawyer advice; can you elaborate with a few more sentences why? (I did read their license stuff last night and also the relevant sections of the LGPL.) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Apr 18, 2008, at 12:47 PM, Stephan Richter wrote:
On Friday 18 April 2008, Jim Fulton wrote:
Because of ExtJS licensing issues, we should not check anything into the repository that builds on or requires ExtJS in any way.
I assume you got lawyer advice;
No.
can you elaborate with a few more sentences why?
I could, but I'd rather not. I suggest reading: http://mjg59.livejournal.com/84586.html if you haven't already. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote: [snip]
can you elaborate with a few more sentences why?
I could, but I'd rather not. I suggest reading:
http://mjg59.livejournal.com/84586.html
if you haven't already.
I concur with Jim - let's avoid ExtJS as their license is not clear. When I studied th details of the ExtJS license, I came away with the same conclusions as this blogger before I read that blog. I was interested in the discussions surrounding it because of this; I'd already decided not to use it. Don't think that since they mention it's LGPL it actually *is* LGPL - it's clear their intent is different. ExtJS is not *actually* licensed under the LGPL. The LGPL appears nowhere in their source code; it has its own license. They seem to think they can invoke the terms of the LGPL and then restrict them further to forbid use in a larger framework. See also my comment here: http://reddit.com/r/reddit.com/info/6enr7/comments/ Regards, Martijn
On Sat, Apr 19, 2008 at 8:11 AM, Martijn Faassen <faassen@startifact.com> wrote:
Jim Fulton wrote: [snip]
can you elaborate with a few more sentences
why?
I could, but I'd rather not. I suggest reading:
http://mjg59.livejournal.com/84586.html
if you haven't already.
I concur with Jim - let's avoid ExtJS as their license is not clear.
When I studied th details of the ExtJS license, I came away with the same conclusions as this blogger before I read that blog. I was interested in the discussions surrounding it because of this; I'd already decided not to use it. Don't think that since they mention it's LGPL it actually *is* LGPL - it's clear their intent is different.
ExtJS is not *actually* licensed under the LGPL. The LGPL appears nowhere in their source code; it has its own license. They seem to think they can invoke the terms of the LGPL and then restrict them further to forbid use in a larger framework.
See also my comment here:
i found this jack's (extjs author) comments on this thread illuminating (more so the original livejournal link).. nutshell is as you said, that extjs is not released under the LGPL. All appearances, claims, and links on their site not withstanding... http://extjs.com/forum/showthread.php?t=27592&highlight=license matt assay did a blog post which sums my opinion of their licensing.. http://www.cnet.com/8301-13505_1-9878693-16.html too bad, its a great toolkit. cheers, -kapil
Regarding Ext's licensing, I'm told that they are planning to switch to an OSI-approved license in the near future; we're still waiting for more details, but my source is here: http://www.openplans.org/projects/opencore/lists/opencore-dev/archive/2008/0... - PW -- Paul Winkler http://www.slinkp.com
Baiju M wrote:
Paul Carduner wrote:
Log message for revision 85449: creating a branch to see what I can do about extjs integration.
Is Paul Carduner paying attention to this thread? He's still continuing to check in code that uses ExtJS. Granted we don't *distribute* ExtJS, but we're still writing framework code that uses ExtJS, and this goes against the principle of being able to use things in svn.zope.org under the license constraints of the ZPL. I cc-ed Paul. Regards, Martijn
It looks like today they changed their licence to GPL v3 ! Regards, Baiju M
On Mon, Apr 21, 2008 at 7:45 AM, Baiju M <mbaiju@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. -- Benji York Senior Software Engineer Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benji York wrote:
On Mon, Apr 21, 2008 at 7:45 AM, Baiju M <mbaiju@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. Having an unambiguous FOSS license on the code has to be good news for those who would like to build and distribute such components. ZMySQLDA, for instance, is a ZPLed component which depends on the non-ZPL MySQL client libraries, which doesn't seem to cause problems. 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. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFIDMer+gerLs4ltQ4RAoitAKCInTMTm9UtiT3ozR/uNeHjgWk5NgCdH79p 7pKs77KEHSE6/6WCWWNzg6I= =aM4/ -----END PGP SIGNATURE-----
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@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.
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.
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.
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. :) Jim -- Jim Fulton Zope Corporation
-----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@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@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-----
Jim Fulton wrote: [snip]
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. :)
Actually we briefly discussed this in a board meeting today, unrelated to this topic. I think the general principle of the repository should be that if you check out something, you can use it under the terms of the ZPL, and it won't pull in something with more restrictive clauses that affect your larger application. I don't think we've codified this principle anywhere yet, so perhaps we should. This is why depending on GPL-ed code should be avoided. Depending on, say, something LGPL-ed or MIT licensed would be fine. Note that I'm not speaking from any particular biased against GPL - I accept that projects use it and it's an appropriate license. Regards, Martijn
participants (10)
-
Baiju M -
Benji York -
Jens Vagelpohl -
Jim Fulton -
Kapil Thangavelu -
Martijn Faassen -
Paul Winkler -
Stephan Richter -
Tres Seaver -
Wichert Akkerman