On Fri, Jan 25, 2013 at 1:14 PM, Servilio Afre Puentes <[email protected]> wrote: > Sean Upton <[email protected]> writes: > >> On Fri, Jan 25, 2013 at 9:11 AM, Steve McMahon <[email protected]> wrote: >>> The FAQ is pretty good on these issues. To quote from it: >>> >>> """ >> ... >>> It is possible to create an add-on product that does not exhibit these >>> behaviors (many generic Zope products that are not specific to Plone, and >>> some Plone themes, do not). Such products need not belicensed under the GPL. >>> """ >> >> One option I have used is to split packages: "frameworky" stuff that >> can live "underneath" Plone and just depend on lower-levels of the >> stack (including the BSD-licensed framework components) go into an >> MIT-licensed package (my employer's legal folks prefer using this >> license when possible), while the application integration of it in >> Plone is GPLv2. This had the positive side-effect of making me create >> a CMFDefault fixture for plone.testing (since plone.app.testing is >> GPL) -- incidentally, the CMFDefault fixture runs integration tests >> for the framework-level package much faster. >> >> You could certainly package proprietary/non-free or non-GPL FOSS >> components this way, and build a GPL'd plone app/product/add-on on top >> of them. > > IANAL, but you can only do this when: > > - For a proprietary component: > - if it is covered by the system library exception; or > - doesn't link to the GPL'ed work[1]
What I am suggesting is something below the GPL'd work, that does not import from a GPL'd work. This neither depends on or links to the GPL'd work. GPL'd works can import from non-GPL independent packages without distribution encumbrance, but not the other way around. > - non-GPL: if the license is compatible[2][3] with the GPL I am not sure this is strictly necessary if the GPL works import from the non-GPL works, never the other way around. >> Also, AFAICT, mere aggregation is not subject to viral nature of GPL: > > The viral nature of the GPL is a myth: it *never* changes the license of > your work, that you have to do by yourself, and only you can do it. I do not mean "viral" in a pejorative sense. It is viral as a distribution encumbrance. If I distribute a GPL package containing some non-GPL components in its distribution (e.g. JavaScript resources licensed under some distinct license), the distributed components need not be GPL, not to mention that the FSF does not sufficiently attempt to clear up clear legal ambiguities in this area, AFAICT [1]. But excepting this mere-aggregation exception, if I distribute Python code importing from plone.app.* or other GPL Plone packages, I should expect that I am obligated to at least distribute those under GPL (possibly in addition to some other license of my choosing); that seems "viral" in that it affects how I license my own unique works (the share-alike sense). > What it *does* is restrict you regarding what *use* you can make of the > GPL-licensed work. IIRC, privately you can combine it in whichever way > you want[4], once you want to distribute, the restrictions kick in. It seems fair to describe this as "viral" if you assume that for purposes of this conversation, the motive is always about distributing the works [2]. Sean [1] http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation [2] Of course, sometimes the motive of distribution for some particular thing built with/adjacent to Plone can run counter to community interests, but I think there are much better cost/risk (dis)incentives to things like forking or hoarding than the GPL really has teeth to fix (arguably, IMHO, GPL limits, shapes the size and culture of our community for both better and worse). _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
