On Fri, Jan 25, 2013 at 6:08 PM, Mikko Ohtamaa <[email protected]> wrote: > >> >> 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. > > > This is not official stance of Plone foundation: There have been recent > court rulings in US (Oracle vs. Google about Android) and EU (SAS vs. World > Programming) which explicitly state that APIs are not copyrightable. You may > have heard at least about the former. Thus, Plone API may not be > copyrightable and using it (importing from GPL) may not make your work a GPL > derivate. Only if you distribute bits of Plone inside your add-on it makes > it GPL. The case is very clear when you distribute Plone and your add-on > together, but most of the folks do not.
I would hazard a guess that this is not settled law, in the US, let alone elsewhere. OTOH, I would not want to be the plaintiff litigating a GPL violation case alleging a derivative work in a late-binding language -- that is a tough sell, since there is no combination prior to exection, not to mention before any distribution. IANAL, but I suppose a legal argument could be constructed from the Oracle v Google case that re-implementing an API (e.g. plugin) is not derivative. I am not sure if that consequently extends to some code calling said API. I have not read the Oracle v Google ruling. Does the reimplementation need to exist in order for the calling code to be considered independent? > You could reimplement Plone API under license X and if your add-on works > against this reimplementation then it could not be "a Plone derivate". Thus > I found import argument very weak. I might draw the line at, say, a monkey-patch of a specific implementation detail -- this kind of thing seems to be derivative without the gray area that most importing and use of modules entails. For example, I have an add-on that monkey-patches an obscure detail in Products.CMFPlone, I cannot imagine it not being a derived work. What constitutes implementation versus interface is the hypothetical matter-of-fact to be determined in such a case. > We had this discussion already many years ago and "import from API to > derivate" argument is not a clear cut. Agreed, but again, that's my personal opinion. > Some recent thoughts: > > http://linux.slashdot.org/comments.pl?sid=3251843&cid=41986577 Interesting, but the thing in that discussion that really is tricky is the actual linked kernel binaries -- we Python developers have never had the luxury or burden of that for a legal "bright line" in the sand as to what is derivative (and what is not) when we ship things as independent distributions. Default judgment sides with the defendant in civil litigation -- I (personally, as an engineer, not an attorney) do not think there is any hypothetical case that could survive all the way to a trial when the alleged derivative work is in such a gray area. Personally, I think the GPL does more for ethos / culture of the community than it necessarily does for the legal protection of the core Plone "product" (arguably, there are other checks on private forking and on free-rider hoarding). I am neither for or against GPL, but sometimes it seems a curious fit for Python-based software when we have discussions like this (vs alternatives like LGPL). Sean _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
