ZPL and GPL licensing issues
Hi there, we @ thingamy are considering changing our license to a ZPL-ish one [1] to better serve our clients' needs. However, some of the (Zope) products we've developed may need to rely on GPL'ed code, or needs to be incorporated within it, and the 'obnoxious advertising clause' seemingly puts a stop to it.. The ZPL is listed as a license incompatible with the GPL, but it doesn't really say clearly what the reason is, as far as we can figure, it's because of the advertising clause. Anyways, I'm wondering if any of you have encountered the same issue developing Zope products and any solutions towards it. Some interesting articles, food for thought: http://www.zdnet.com/enterprise/stories/main/0,10228,2777053,00.html http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses http://www.gnu.org/philosophy/bsd.html [1] http://www.thingamy.com/tpl Regards, Morten
On Wed, Jun 20, 2001 at 04:50:33PM +0200, Morten W. Petersen wrote:
we @ thingamy are considering changing our license to a ZPL-ish one [1] to better serve our clients' needs. However, some of the (Zope) products we've developed may need to rely on GPL'ed code, or needs to be incorporated within it, and the 'obnoxious advertising clause' seemingly puts a stop to it..
The ZPL is listed as a license incompatible with the GPL, but it doesn't really say clearly what the reason is, as far as we can figure, it's because of the advertising clause.
Anyways, I'm wondering if any of you have encountered the same issue developing Zope products and any solutions towards it.
I recently asked RMS about this exact question. He studied the license and said that another problem field is that the license is not clear whether modified versions can be distributed in binary form (paragraph 7 of the ZPL). I hope he doesn't mind me quoting the second part of his exact words: "... If the Zope developers are willing to make just one change, I hope they will clarify section 7 to clearly say that modified binaries may be distributed if labeled as unofficial. If they would like to make the license GPL-compatible as well, that would require a few more changes: * Section 4 would have to go. * The license would have to allow distribution of modified sources, not just source patches. * Instead of saying that modified versions have to be "labeled as unofficial", it would have to say they must be labeled as modified and by whom. (That is what the GPL requires.) If they don't want to make that much change, well, being incompatible with the GPL is unfortunate but not disastrous. But I hope they will clarify the issue of modified binaries, because that issue could be disastrous. Please invite them to contact me directly to talk about this. I forwarded that mail to zope-license@zope.org, but I have no idea if consultations are going on between them. Gregor
Hi, On Wed, Jun 20, 2001 at 04:50:33PM +0200, Morten W. Petersen wrote:
Anyways, I'm wondering if any of you have encountered the same issue developing Zope products and any solutions towards it.
we (Intevation) would very much welcome if Zope would be licensed with a GPL compatible license. Since Intevation never develops software with licenses incompatible with GPL we may sooner or later need to look for alternatives to Zope. So, yes we see this as a serious issue and I hope the solution will be to exchange the ZPL by a GPL-compatible one. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/
Here comes the liscence wars again. Still haven't figured out how GPL became the holy grail.
On 20 Jun 2001 10:38:03 -0500, Steve Drees wrote:
Here comes the liscence wars again.
Still haven't figured out how GPL became the holy grail.
the terms on the gpl are (by choice) the strictiest (does that word even exists?) ever seen in a free software license. but a lot of people 'believe' in free software and have elected the gpl as their license of choice. because of their true faith :) they are also pickier at license compatibility. i am sure that the QPL and the ZPL are completely incompatible but nobody cares because nobody really thinks that one is better than the other... anyway, don't see it as a war. it is more like natural selection... federico (a real believer :) ) -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra
On 20 Jun 2001, Federico Di Gregorio wrote:
i am sure that the QPL and the ZPL are completely incompatible but nobody cares because nobody really thinks that one is better than the other...
I might be misunderstanding here, if that's the case I appologies. Just to clarify, for us at Thingamy (and I'm quite sure this is the real case behind the license issues) it comes down to business-issues. I do very much care whether or not I can use a GPL Zope Python Product with my ZPL/TPL Zope Python Product. If I can't, and someone tells me I need to relicense my product as GPL it would be very bad. An example could be if I had application G, Z, P. G is a GPL'ed Zope Python Product, Z is a ZPL/TPL Zope Python Product and P is some proprietory stuff I developed for my client. Now, if the proprietory application P interacts with my Z application and Z needs to become GPL, then that would/could require the proprietary stuff I did for the client to become GPL as well. Then, I get hell. If the client has to disclose their business trade-secrets, the stuff that really makes them them, I'd be sued so hard I'd see stars for another three decades :) Or am I wrong (I'd absolutely love to be!)?
On Wed, Jun 20, 2001 at 06:27:08PM +0200, Erik Enge wrote:
On 20 Jun 2001, Federico Di Gregorio wrote:
i am sure that the QPL and the ZPL are completely incompatible but nobody cares because nobody really thinks that one is better than the other...
I might be misunderstanding here, if that's the case I appologies.
Just to clarify, for us at Thingamy (and I'm quite sure this is the real case behind the license issues) it comes down to business-issues. I do very much care whether or not I can use a GPL Zope Python Product with my ZPL/TPL Zope Python Product. If I can't, and someone tells me I need to relicense my product as GPL it would be very bad.
An example could be if I had application G, Z, P. G is a GPL'ed Zope Python Product, Z is a ZPL/TPL Zope Python Product and P is some proprietory stuff I developed for my client. Now, if the proprietory application P interacts with my Z application and Z needs to become GPL, then that would/could require the proprietary stuff I did for the client to become GPL as well.
You're not allowed to distribute a derived work of GPL code with proprietary code incorporated. I. e. if you want to use that GPL code in your work, you'll have to make the proprietary code available under a GPL-compatible license as well (not necessarily the GPL itself). The Zope license doesn't even get into the play here. It's all between the GPL and your proprietary license. The crucial point is whether a work is a derived work of GPL code. The FSF says that mixing pieces of proprietary and GPL scripts in an application is a derived work indeed. Other people deny this. Gregor
On Wed, 20 Jun 2001, Gregor Hoffleit wrote:
You're not allowed to distribute a derived work of GPL code with proprietary code incorporated.
Ok, this is the situation. We in Thingamy usually create all our products under the GPL. Then we give the whole shebang to the client we have been working for and they have all the lovely rights that they should have. If they want to redistribute, they can. Then, we have the other clients, that's the clients that are scared shitless from the GPL because if someone gets ahold of the code, that is their business-processes, it could be devastating for their business. It is a semi-legitimate fear, but only if they have the intention of actually redistributing the code (eg. becomming software-vendors, which some actually want to do...). If I have the proprietory program P (that is the clients business-process workflow application *phew*) as a Zope Python Product and then we have Morten's GUM under the GPL, which also is a Zope Python Product, can P application utilise GUM without having to be relicensed as GPL? (And I realise that the word "utilise" is ambigous, that was intentional.) To ask again, if it was unclear: can I use GPL Zope Python Products with non-copylefted Zope Python Products without relicensing? It is imperative for me as a professional Zope-developer (ie, I charge for my services) to know the answer to that question, and I should think it is vital to other developers as well. Surely someone from DC already as the answer? Another question which I feel is very related, and to which I cannot get any real clarification: Can Zope run GPL Zope Python Products without being relicensed as GPL? All the GPL Zope Python Products I've writted as subclassed from Persistent, for example.
I. e. if you want to use that GPL code in your work, you'll have to make the proprietary code available under a GPL-compatible license as well (not necessarily the GPL itself).
"use [...] in your work", what does that mean? Subclassing? Interaction between the products in a management-interface?
The Zope license doesn't even get into the play here. It's all between the GPL and your proprietary license.
Hm. What about a ZPL Zope Python Product and a GPL Zope Python Product? Isn't the problem exactly the same?
i'll try to answer as clearly as possible but remeber that what follows are *my* oppinions, not mixad live's nor debian's. On 21 Jun 2001 10:52:28 +0200, Erik Enge wrote:
On Wed, 20 Jun 2001, Gregor Hoffleit wrote: [snip] If I have the proprietory program P (that is the clients business-process workflow application *phew*) as a Zope Python Product and then we have Morten's GUM under the GPL, which also is a Zope Python Product, can P application utilise GUM without having to be relicensed as GPL? (And I realise that the word "utilise" is ambigous, that was intentional.)
if your product derives from GUM or uses internal interfaces, no, you can't. if your product uses only well the defined external api or access gum through zope, then, imho, yes.
Another question which I feel is very related, and to which I cannot get any real clarification: Can Zope run GPL Zope Python Products without being relicensed as GPL?
good question. imho, licensing a zope product under gpl is a non-sense because you won't be able to use it (usually products inherit on zope classes) and respect the gpl at the same time. that's why i always release under a double license. i really hope dc will release zope under a gpl compatible license soon or later.
"use [...] in your work", what does that mean? Subclassing? Interaction between the products in a management-interface?
i personally consider subclassing as linking.
Hm. What about a ZPL Zope Python Product and a GPL Zope Python Product? Isn't the problem exactly the same?
yes. terrible, terrible problem. but, please don't see that as a "license war". different people like different licenses for different reasons and that's Right (TM). this "war" is just all of us trying to cooperate to put free software to a better use. federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The number of the beast: vi vi vi. -- Delexa Jones
On 21 Jun 2001, Federico Di Gregorio wrote:
if your product derives from GUM or uses internal interfaces, no, you can't. if your product uses only well the defined external api or access gum through zope, then, imho, yes.
Ok, that's good. Then it means we can potentially use GPL Zope Python Products with non-copyleft ones.
good question. imho, licensing a zope product under gpl is a non-sense because you won't be able to use it (usually products inherit on zope classes) and respect the gpl at the same time. that's why i always release under a double license. i really hope dc will release zope under a gpl compatible license soon or later.
Because if you have a gpl-compatible license you dont have to relicense to redistribute, right?
yes. terrible, terrible problem. but, please don't see that as a "license war". different people like different licenses for different reasons and that's Right (TM). this "war" is just all of us trying to cooperate to put free software to a better use.
Amen to that :-)
Erik Enge writes:
Another question which I feel is very related, and to which I cannot get any real clarification: Can Zope run GPL Zope Python Products without being relicensed as GPL? I think, we can answer this with a clear yes:
As an analogy: You can use a Windows (TM) command line interpreter to start and interact with a GPL programm that in turn call the Windows (TM) operating system services without the need to relicense the Windows (TM) operating system under the GPL. I would expect that you can use any freely available (freely available does not mean non-commercial) product and combine it with GPL components as long as you license *your* integration code under GPL and you do not distribute the non-GPL components in the same package as the GPL components. Another example: You build a complex system consisting of GPL components and a commercial database (say Oracle). I do not expect RMS to require Oracle to become GPL in order for GPL components to interact with it. Not yet, at least. Dieter
On 20 Jun 2001 18:27:08 +0200, Erik Enge wrote:
On 20 Jun 2001, Federico Di Gregorio wrote:
i am sure that the QPL and the ZPL are completely incompatible but nobody cares because nobody really thinks that one is better than the other...
I might be misunderstanding here, if that's the case I appologies.
no, you're quite right. but we have two different problems here: 1/ your problem 2/ wheter a gpl zope product can exists first some notes on 2. i don't know if python code loading other python code counts as "linking" but if that is the case, no gpl zope product can exists (same problem with python, but there is at least one gpl-compatible release of python around.) for example, that's why psycopg, for example, is released under a double license. you can use the gpl if your product is gpl'ed or the zpl when using zpsycopgda in zope (and only then: you can include psycopg in your code without respecting the gpl *only* when using zope and zpsycopgda.) to your problem now...
Just to clarify, for us at Thingamy (and I'm quite sure this is the real case behind the license issues) it comes down to business-issues. I do very much care whether or not I can use a GPL Zope Python Product with my ZPL/TPL Zope Python Product. If I can't, and someone tells me I need to relicense my product as GPL it would be very bad.
An example could be if I had application G, Z, P. G is a GPL'ed Zope Python Product, Z is a ZPL/TPL Zope Python Product and P is some proprietory stuff I developed for my client. Now, if the proprietory application P interacts with my Z application and Z needs to become GPL, then that would/could require the proprietary stuff I did for the client to become GPL as well.
you are quite right. but here, again, we have a lexical problem. are zope products really linked? gpl forbids liking but there is no problem, for example, in piping the data froma gpl'ed program to a proprietary one. i can only say that **if** zope products count as linked, you can't in any way use gpl code without releasing *all* the code under a gpl compatible license (P included.) anyway, is much better for you to ask the author of the gpl'ed program for an alternate license. a lot of people will be happy to allow you to use the program in a proprietary software for a little (or not so little) fee... and if you have those problems is because you think you'll make some money out of it, right? other people won't and your only option is to rewrite the product or (much better!) ask the customer to release under the gpl.
Then, I get hell. If the client has to disclose their business trade-secrets, the stuff that really makes them them, I'd be sued so hard I'd see stars for another three decades :)
i'll finish with some bad words, sorry: if the client is so worried about intellectual property and secrets why is he even thinking about free software? free software is good in a lot (in a different context i would say 'all') of cases but imposes some constraints ont your work and (unfortunately) *even* on your clients. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra
On Wed, Jun 20, 2001 at 06:27:08PM +0200, Erik Enge wrote:
On 20 Jun 2001, Federico Di Gregorio wrote:
i am sure that the QPL and the ZPL are completely incompatible but nobody cares because nobody really thinks that one is better than the other...
I might be misunderstanding here, if that's the case I appologies.
Just to clarify, for us at Thingamy (and I'm quite sure this is the real case behind the license issues) it comes down to business-issues. I do very much care whether or not I can use a GPL Zope Python Product with my ZPL/TPL Zope Python Product. If I can't, and someone tells me I need to relicense my product as GPL it would be very bad.
An example could be if I had application G, Z, P. G is a GPL'ed Zope Python Product, Z is a ZPL/TPL Zope Python Product and P is some proprietory stuff I developed for my client. Now, if the proprietory application P interacts with my Z application and Z needs to become GPL, then that would/could require the proprietary stuff I did for the client to become GPL as well.
Then, I get hell. If the client has to disclose their business trade-secrets, the stuff that really makes them them, I'd be sued so hard I'd see stars for another three decades :)
Or am I wrong (I'd absolutely love to be!)?
As far as I can tell you are wrong, but there are certainly gray areas. The last time this came up I wrote such a scenario up and tried to get FSF clarification. Nothing ever came back. The questions arise from the sections around the "mere aggregation" paragraph. Quoting: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. ... In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. It appears to me, that, if you want to play it safe, you would not distribute the code under license G and license T on the same medium. It is certainly acceptable to call code released under license G from code released under license T; but it is not clear that you can do subclassing and such. But, I think that if you clearly make sure that your programs are identifiable stand-alone objects that invoke a GPL'ed program via an API that could be (in principle) be reimplemented in by a non-GPL program, you are fine. However, if you must modify the GPL program for your license T program to work, make sure that you keep these modifications cleanly separate. (And feed them back upstream if at all possible). But, http://www.fsf.org/copyleft/gpl-faq.html has a lot of information. Especially note the sections titled Can I use the GPL for a plug-in for a non-free program? What is the difference between "mere aggregation" and "combining two modules into one program"? and I'd like to incorporate GPL-covered software in my proprietary system. Can I do this? Something like Zope is a nightmare for GPL legalists. Zope pre-exists and is not GPL. GPL plug-ins exist, but aren't at "arms-length" to the extent of fork-and-exec. Nevertheless, I find it difficult to conceive that any author of a GPL plug-in is going to object to your _using_ it. The question is going to arise when you _extend_ it. But be careful to read licensing of each package. For example, Jerome Alet, author of ZShell has a somewhat stronger position concerning his code. See http://cortex.unice.fr/~jerome/zshell/LICENSE Also, as an aside, if this really concerns you, you might wish to consider contacting the author of the GPL product. There is nothing to prevent him from giving you different licensing terms. For most GPL authors, this comes down to a simple question: "Are you trying to be excellent unto them", or are you trying to "use slash and burn agriculture". If you are using, improving, giving feedback, writing documentation, helping publicise, or otherwise aiding them, they are likely to cut you a bit of slack. If you see the author as someone you can simply take advantage of, he is not so likely to cooperate with you. Jim Penny
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Hmm, I think this discussion doesn't belong to zope-dev. Still, for those interested in that topic: I raised a similar question on the debian-legal mailing list just yesterday ("Q: Combining proprietary code and GPL for in-house use"). The discussion is still ongoing, and it certainly gives you some insight in the topic: http://www.geocrawler.com/lists/3/Debian-Linux/208/25/5997636/ Just a few points: It looks that from the viewpoint of the FSF, when you're using the header files of a GPL library, you already have to accept the license. On Wed, Jun 20, 2001 at 01:12:20PM -0400, Jim Penny wrote:
It appears to me, that, if you want to play it safe, you would not distribute the code under license G and license T on the same medium. It is certainly acceptable to call code released under license G from code released under license T; but it is not clear that you can do subclassing and such.
I think this is wrong. Providing things on the same media is "mere aggregation" and therefore not a problem on its own. It's not acceptable, though, to distribute a proprietary program that has to be linked with a GPL component by the customer--even if you distribute this on separate medias! If you're interested in this, feel free to come over to debian-legal and read the ongoing discussion. Gregor
On Wed, Jun 20, 2001 at 08:05:43PM +0200, Gregor Hoffleit wrote:
On Wed, Jun 20, 2001 at 01:12:20PM -0400, Jim Penny wrote:
It appears to me, that, if you want to play it safe, you would not distribute the code under license G and license T on the same medium. It is certainly acceptable to call code released under license G from code released under license T; but it is not clear that you can do subclassing and such.
I think this is wrong. Providing things on the same media is "mere aggregation" and therefore not a problem on its own.
BTW, I was responding to a question implicit in the original message, but not explicitly asked. The question is "How do I minimize risk of inadvertant 'GPL Contamination'?". In this view, if you never distribute GPL and non-GPL code on the same medium, you have made a small step in making sure that they are considered as separate entities. After all, one of the more ambiguous part of the GPL is what is "mere aggregation" and what is a "combined work". It is somewhat easier to consider something a combined work if it is always distributed with GPL code. Jim
It's not acceptable, though, to distribute a proprietary program that has to be linked with a GPL component by the customer--even if you distribute this on separate medias!
If you're interested in this, feel free to come over to debian-legal and read the ongoing discussion.
Gregor
On 20 Jun 2001 13:12:20 -0400, Jim Penny wrote:
Also, as an aside, if this really concerns you, you might wish to consider contacting the author of the GPL product. There is nothing to prevent him from giving you different licensing terms. For most GPL authors, this comes down to a simple question: "Are you trying to be excellent unto them", or are you trying to "use slash and burn agriculture". If you are using, improving, giving feedback, writing documentation, helping publicise, or otherwise aiding them, they are likely to cut you a bit of slack. If you see the author as someone you can simply take advantage of, he is not so likely to cooperate with you.
i think this express extremely what i (we?) feel. as long as you give back *something* you're wellcome. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The reverse side also has a reverse side. -- Japanese proverb
* Jim Penny <jpenny@universal-fasteners.com> [2001-06-20 19:12]:
As far as I can tell you are wrong, but there are certainly gray areas. The last time this came up I wrote such a scenario up and tried to get FSF clarification. Nothing ever came back.
I got a clarification from the FSF. It's in the mailing list archives at http://lists.zope.org/pipermail/zope/2000-September/118024.html Some topics never die :-) Cheers, Nils
On Thu, 21 Jun 2001, Nils Kassube wrote:
* Jim Penny <jpenny@universal-fasteners.com> [2001-06-20 19:12]:
As far as I can tell you are wrong, but there are certainly gray areas. The last time this came up I wrote such a scenario up and tried to get FSF clarification. Nothing ever came back.
I got a clarification from the FSF. It's in the mailing list archives at [...]
So, the outcome is that one cannot use GPL Zope Python Products and distribute the system. That sounds logical, since ZPL is not GPL compatible. What then, is to "distribute the system"? If I install GUM (GPL) on a clients Zope instance, have I distributed anything? Is it putting it on the same website, same tarball, under the same invoice of consultant services or what? Help. Can I raise I question without getting flamed (since the question isn't rethorical but a sincear one): was the "advertisement"-clauses in the ZPL meant to secure Zope's progress to become a big and respected piece of software? Has it not secured that now? My real question is: what good will the advertisement-clauses do us now? What harm would it do to remove them? (No, that last one isn't rethorical :-)
On Thu, Jun 21, 2001 at 12:28:01PM +0200, Nils Kassube wrote:
* Jim Penny <jpenny@universal-fasteners.com> [2001-06-20 19:12]:
As far as I can tell you are wrong, but there are certainly gray areas. The last time this came up I wrote such a scenario up and tried to get FSF clarification. Nothing ever came back.
I got a clarification from the FSF. It's in the mailing list archives at
http://lists.zope.org/pipermail/zope/2000-September/118024.html
Some topics never die :-)
I went and reread the "clarification". OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software? My understanding is that the answer to every one of these is yes. May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no. Now, s/operating system/zope/g Do the answers to the questions change? And, if so, why?
From my perspective, and I think from fog's the answer is that it should not change the answers.
Maybe the easy way out of this is to simply declare zope an "operating system" rather than an "application". Snippy thoughts cut here.
Cheers, Nils
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote: [snip]
OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software?
My understanding is that the answer to every one of these is yes.
yes. only if it is free. only if it is free. yes, but only because gpl allows for gpl code linking with the major components of the os even if they are proprietary.
May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no.
Now, s/operating system/zope/g
Do the answers to the questions change? And, if so, why?
From my perspective, and I think from fog's the answer is that it should not change the answers.
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply.
Maybe the easy way out of this is to simply declare zope an "operating system" rather than an "application". Snippy thoughts cut here.
eheh. nice try... :) -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further
On Thu, Jun 21, 2001 at 05:18:40PM +0200, Federico Di Gregorio wrote:
On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote: [snip]
OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software?
My understanding is that the answer to every one of these is yes.
yes. only if it is free. only if it is free. yes, but only because gpl allows for gpl code linking with the major components of the os even if they are proprietary.
Uh, you might want to reconsider the "only if it is free" parts. After all Interix had a business of selling GPL software for a non-free OS. Now Microsoft has that business (NT Services for Unix Pack). IBM distributes gcc and perl. Cygwin sells GPL software for non-free OS's.
May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no.
Now, s/operating system/zope/g
Do the answers to the questions change? And, if so, why?
From my perspective, and I think from fog's the answer is that it should not change the answers.
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply.
GPL limitations apply to whom: To you, the developer? To a downstream user invoking the product via dtml-call or dtml-var or their pythonish equivalents? To a downstream developer who modifies your product and redistibutes the modified product? To a downstream developer who writes a component that invokes the GPL component? In my mind the only sensible answers are developer - no, user - no (but see Jerome Alet's codacil), downstream modifier - yes, downstream developer who uses - no. The only other sensible option is that, indeed, no one may distribute GPL components for Zope, including the original developer.
Maybe the easy way out of this is to simply declare zope an "operating system" rather than an "application". Snippy thoughts cut here.
eheh. nice try... :)
-- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Don't dream it. Be it. -- Dr. Frank'n'further
On 21 Jun 2001 11:39:37 -0400, Jim Penny wrote:
On Thu, Jun 21, 2001 at 05:18:40PM +0200, Federico Di Gregorio wrote:
On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote: [snip]
OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software?
My understanding is that the answer to every one of these is yes.
yes. only if it is free. only if it is free. yes, but only because gpl allows for gpl code linking with the major components of the os even if they are proprietary.
Uh, you might want to reconsider the "only if it is free" parts. After all Interix had a business of selling GPL software for a non-free OS. Now Microsoft has that business (NT Services for Unix Pack). IBM distributes gcc and perl. Cygwin sells GPL software for non-free OS's.
ops. ok, poorly worded. third parties can distribute only if the os is free, vendor can do as he please, obviously... [snip]
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply.
GPL limitations apply to whom: To you, the developer? To a downstream user invoking the product via dtml-call or dtml-var or their pythonish equivalents? To a downstream developer who modifies your product and redistibutes the modified product? To a downstream developer who writes a component that invokes the GPL component?
In my mind the only sensible answers are developer - no, user - no (but see Jerome Alet's codacil), downstream modifier - yes, downstream developer who uses - no.
The only other sensible option is that, indeed, no one may distribute GPL components for Zope, including the original developer.
as i said before, writing gpl code subclassing zope is a non-sense. even the author cannot, imho, redistribute its work with a plain gpl attached to it. the gpl says that if you link with gpl code *all* the code should be gpl or gpl-compatible (major os components like clibs, compilers, etc are an exception). so even the author cannot do that without licensing under gpl plus some exception ("as a special exception you're allowed to link this code with zope or any other zope product distributed under the zpl".) see the (in)famous gpl vs. qt thread in the debian mailing lists for an in-depth analisys of this problem. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The number of the beast: vi vi vi. -- Delexa Jones
Federico Di Gregorio wrote:
On 21 Jun 2001 11:39:37 -0400, Jim Penny wrote:
On Thu, Jun 21, 2001 at 05:18:40PM +0200, Federico Di Gregorio wrote:
On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote: [snip]
OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software?
My understanding is that the answer to every one of these is yes.
yes. only if it is free. only if it is free. yes, but only because gpl allows for gpl code linking with the major components of the os even if they are proprietary.
Uh, you might want to reconsider the "only if it is free" parts. After all Interix had a business of selling GPL software for a non-free OS. Now Microsoft has that business (NT Services for Unix Pack). IBM distributes gcc and perl. Cygwin sells GPL software for non-free OS's.
ops. ok, poorly worded. third parties can distribute only if the os is free, vendor can do as he please, obviously...
[snip]
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply.
GPL limitations apply to whom: To you, the developer? To a downstream user invoking the product via dtml-call or dtml-var or their pythonish equivalents? To a downstream developer who modifies your product and redistibutes the modified product? To a downstream developer who writes a component that invokes the GPL component?
In my mind the only sensible answers are developer - no, user - no (but see Jerome Alet's codacil), downstream modifier - yes, downstream developer who uses - no.
The only other sensible option is that, indeed, no one may distribute GPL components for Zope, including the original developer.
as i said before, writing gpl code subclassing zope is a non-sense. even the author cannot, imho, redistribute its work with a plain gpl attached to it. the gpl says that if you link with gpl code *all* the code should be gpl or gpl-compatible (major os components like clibs, compilers, etc are an exception). so even the author cannot do that without licensing under gpl plus some exception ("as a special exception you're allowed to link this code with zope or any other zope product distributed under the zpl".) see the (in)famous gpl vs. qt thread in the debian mailing lists for an in-depth analisys of this problem.
To me this is the key point. If you GPL license a product (or other software) for Zope, you cannot subclass ZPL coded classes in your product without violating the GPL. This makes a strict GPL license nearly useless for Zope development and incompatible (license-wise) with Zope itself. What bugs me is when people point to the ZPL being the "problem", it is the GPL that is the limiting factor IMEHO. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
On Thu, Jun 21, 2001 at 10:02:34AM -0600, Casey Duncan wrote:
To me this is the key point. If you GPL license a product (or other software) for Zope, you cannot subclass ZPL coded classes in your product without violating the GPL. This makes a strict GPL license nearly useless for Zope development and incompatible (license-wise) with Zope itself. What bugs me is when people point to the ZPL being the "problem", it is the GPL that is the limiting factor IMEHO.
But that's a little bit like standing in front of a mountain and saying "Go away", isn't it ?
From the viewpoint of the GPL, the ZPL is the limiting factor, since it employs restrictions (does it really ???) regarding the distribution of binaries, and since it has a advertisement clause that restricts your right to distribute Zope.
On the other side, from the viewpoint of the ZPL, these requirements of the GPL are the limiting factor. But I'm afraid the discussion on who's guilty won't solve the problem, which indeed is perceived by all of us (is it ?). Gregor
Gregor Hoffleit wrote:
On Thu, Jun 21, 2001 at 10:02:34AM -0600, Casey Duncan wrote:
To me this is the key point. If you GPL license a product (or other software) for Zope, you cannot subclass ZPL coded classes in your product without violating the GPL. This makes a strict GPL license nearly useless for Zope development and incompatible (license-wise) with Zope itself. What bugs me is when people point to the ZPL being the "problem", it is the GPL that is the limiting factor IMEHO.
But that's a little bit like standing in front of a mountain and saying "Go away", isn't it ?
From the viewpoint of the GPL, the ZPL is the limiting factor, since it employs restrictions (does it really ???) regarding the distribution of binaries, and since it has a advertisement clause that restricts your right to distribute Zope.
On the other side, from the viewpoint of the ZPL, these requirements of the GPL are the limiting factor.
But I'm afraid the discussion on who's guilty won't solve the problem, which indeed is perceived by all of us (is it ?).
Gregor
You are correct my friend. And both sides (DC and FSF) are unwilling to change their licenses for compatibility with the other. So, the incompatibility stands and there is little we can do about it; except understand that it exists and make informed choices that are acceptable to ourselves as developers. That may mean if you are a staunch GPL advocate, adding a "Zope" clause to you license. -- | Casey Duncan | Kaivo, Inc. | cduncan@kaivo.com `------------------>
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your external code from zope. if you write a product suclassing dc code, you're effectively 'linking' and gpl limitations apply.
GPL limitations apply to whom: To you, the developer? To a downstream user invoking the product via dtml-call or dtml-var or their pythonish equivalents? To a downstream developer who modifies your product and redistibutes the modified product? To a downstream developer who writes a component that invokes the GPL component?
In my mind the only sensible answers are developer - no, user - no (but see Jerome Alet's codacil), downstream modifier - yes, downstream developer who uses - no.
The only other sensible option is that, indeed, no one may distribute GPL components for Zope, including the original developer.
as i said before, writing gpl code subclassing zope is a non-sense. even the author cannot, imho, redistribute its work with a plain gpl attached to it. the gpl says that if you link with gpl code *all* the code should be gpl or gpl-compatible (major os components like clibs, compilers, etc are an exception). so even the author cannot do that without licensing under gpl plus some exception ("as a special exception you're allowed to link this code with zope or any other zope product distributed under the zpl".) see the (in)famous gpl vs. qt thread in the debian mailing lists for an in-depth analisys of this problem.
ciao, federico
OK, this is essentially what I wanted. Now the problem is completely distilled. DC and FSF somehow have to come to some understandings of the following questions. Can a GPL (unmodified) component be distributed for Zope (at all)? Can a GPL (modified per fog) component be distributed for Zope? If yes to either, may the component be invoked (dtml-var, dtml-call, or equivalent) from a non-GPL component? If yes to either, may the component be subclassed by a non-GPL component? Jim
-- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org The number of the beast: vi vi vi. -- Delexa Jones
Jim Penny wrote:
DC and FSF somehow have to come to some understandings of the following questions.
Here is my own view (not DC's offical word!)
Can a GPL (unmodified) component be distributed for Zope (at all)?
I think the message by Bradley Kuhn is a little misleading. If you are the original developer, you can distribute your product. The GPL does not try to limit the rights of the original developer. As the original developer you have the rights granted by copyright law, which is a "higher" law than the GPL. The GPL primarily affects redistribution. If, for example, Apple decides they like your product, even though you tried to GPL it they'll have to ask you to re-release your product under a different license before they can redistribute your product since it depends on Zope and the ZPL is not compatible.
Can a GPL (modified per fog) component be distributed for Zope?
Yes, but only by the original developer or with permission from the original developer. You can post your product on zope.org, but since the GPL and ZPL aren't compatible, another site cannot mirror your product unless you specifically grant permission. The intent of the GPL is to grant specific redistribution rights to those who receive your product, but since a condition of the GPL cannot be met, the license is effectively meaningless. So what does a voided license mean? It means that the recipient of your product effectively has no rights to redistribute your product in any way, except according to your terms expressed through other means. Now let's say some company decides to take your product and distribute a derivative without source code. Let's say you don't like what they've done and the case goes to court. I'm no lawyer, but as I see it the GPL won't be in effect, yet the fact that you tried to use the GPL clearly demonstrates your intent. The intent was clearly stated from the start. It's hard to say how much legal weight intent really has (especially outside the U.S.), but regardless of the GPL your work would still be covered by copyright law. The only time copyright law no longer applies is when you declare your work to be in the "public domain".
If yes to either, may the component be invoked (dtml-var, dtml-call, or equivalent) from a non-GPL component? If yes to either, may the component be subclassed by a non-GPL component?
These are really the same question in the eyes of the GPL. The answer is yes, but the non-GPL component can't be distributed except under terms not contained in the GPL. Let's take a real-life example: Simon Michael created the ZWiki product and released it under the GPL. Digital Creations modified it to fit better in the CMF. Digital Creations cannot redistribute the derivative unless Simon (assuming he is the copyright holder) specifically says we can. He holds copyright privileges and can release the work under multiple licenses or under special terms. Now, if the ZPL were GPL compatible, the GPL would be in full effect for products. Digital Creations would automatically have the rights to redistribute derivatives of ZWiki. I believe DC would even be able to distribute ZWiki with Zope as long as any dependent products (such as CMFWiki) are also GPL'ed. Zope itself would not have to be GPL'ed since it does not depend in any way on ZWiki. By the way, the "operating system" clause of the GPL does not apply. The clause is there because it's clear that although an operating system is required to run most GPL'ed software, a *specific* operating system is not required. If there were multiple distinct implementation of the Zope APIs, there would be grounds for a different interpretation of the GPL. So let me summarize: - GPL applied to Zope products is currently meaningless. If, however, the ZPL is made GPL compatible at some time, the GPL will automatically take effect for products that currently attempt to apply the GPL. - As the original developer you can distribute to whomever you please, but trying to use the GPL to grant rights to redistributors is ineffective right now. (Technically, those who receive the product don't have the right to use the product at all, except for the fact that posting it on zope.org and attempting to apply the GPL is a somewhat weak means of expressing permission.) - Unless you're making something substantial, you shouldn't be concerned that your code will be stolen by code sharks. You might consider a dual-licensing scheme where users are allowed to apply either the GPL, when it becomes possible, or some other license. - The GPL is designed to build a pool of software from which anyone can draw as long as they play by the rules. As long as the ZPL is not compatible with the GPL, no one can truly add Zope products to this pool. If your philosophy agrees with the GPL, I urge you to lobby DC to get the ZPL changed. - DC has not changed the ZPL because there hasn't been any strong push to make it happen. I certainly can't make it happen; some of my arguments are a bit weak and I personally have no reason to release a product under the GPL. Make your voice heard. Keep in mind that many on the management team don't have time to read the zope-dev and zope lists. Shane
On Fri, 22 Jun 2001, Shane Hathaway wrote:
Now, if the ZPL were GPL compatible, the GPL would be in full effect for products. Digital Creations would automatically have the rights to redistribute derivatives of ZWiki. I believe DC would even be able to distribute ZWiki with Zope as long as any dependent products (such as CMFWiki) are also GPL'ed. Zope itself would not have to be GPL'ed since it does not depend in any way on ZWiki.
Now I think I have two different answers to one of my fundamental questions in this discussion: if I have a GPL-compatible licensed product and I distribute it with a GPL product, do I need to relicense the former one to GPL? Because that is what I understand you to say. Others have said the opposite. This is very important. Because if you can't be compatible without escaping to have to relicense to GPL, the GPL is worthless to me.
If your philosophy agrees with the GPL, I urge you to lobby DC to get the ZPL changed. : - DC has not changed the ZPL because there hasn't been any strong push to make it happen. [...] Make your voice heard. Keep in mind that many on the management team don't have time to read the zope-dev and zope lists.
I hope that you guys at DC reading the list make them aware of the fact that many people as frustrated with this. And it is not a small issue, either, as I'm sure we are all too aware of. I'd love to lobby DC to start thinking about this, how do I get in touch with the management team? It would be great if we could discuss this on zope-licenses@zope.org (or similar) and have them read/comment on that list. To start off with, it would be great if we could see the rationale for the ZPL, and how they think it applies to the current situation.
On Fri, 22 Jun 2001, Erik Enge wrote:
Now I think I have two different answers to one of my fundamental questions in this discussion: if I have a GPL-compatible licensed product and I distribute it with a GPL product, do I need to relicense the former one to GPL? Because that is what I understand you to say. Others have said the opposite.
Yes, you can distribute a GPL-compatible licensed code with GPL licensed code without licencing the former under GPL. Take a look in the Linux-kernel source tree for example. And yes, it would be very interesting to see the underlying reason(s) for the ZPL.. Regards, Morten
On Fri, 22 Jun 2001, Morten W. Petersen wrote:
Yes, you can distribute a GPL-compatible licensed code with GPL licensed code without licencing the former under GPL. Take a look in the Linux-kernel source tree for example.
Ok, good. Then Thingamy's intermediate solution will be to create a TPL which is basically the ZPL with the incompatible-clauses ripped out (number 4 and 7, I think). That way we are compatible with both the ZPL and the GPL. It's still a mess, though.
On Fri, 22 Jun 2001, Erik Enge wrote:
Ok, good. Then Thingamy's intermediate solution will be to create a TPL which is basically the ZPL with the incompatible-clauses ripped out (number 4 and 7, I think). That way we are compatible with both the ZPL and the GPL.
Something like that. Verifying the license with the GNU people now. -Morten
On Friday 22 June 2001 04:24, Erik Enge wrote:
On Fri, 22 Jun 2001, Shane Hathaway wrote:
Now, if the ZPL were GPL compatible, the GPL would be in full effect for products. Digital Creations would automatically have the rights to redistribute derivatives of ZWiki. I believe DC would even be able to distribute ZWiki with Zope as long as any dependent products (such as CMFWiki) are also GPL'ed. Zope itself would not have to be GPL'ed since it does not depend in any way on ZWiki.
Now I think I have two different answers to one of my fundamental questions in this discussion: if I have a GPL-compatible licensed product and I distribute it with a GPL product, do I need to relicense the former one to GPL? Because that is what I understand you to say. Others have said the opposite.
I agree with Morten--yes, you can distribute GPL compatible code and GPL code together. ZWiki is just in a strange position because the GPL is not actually in effect.
- DC has not changed the ZPL because there hasn't been any strong push to make it happen. [...] Make your voice heard. Keep in mind that many on the management team don't have time to read the zope-dev and zope lists.
I hope that you guys at DC reading the list make them aware of the fact that many people as frustrated with this. And it is not a small issue, either, as I'm sure we are all too aware of.
I'd love to lobby DC to start thinking about this, how do I get in touch with the management team? It would be great if we could discuss this on zope-licenses@zope.org (or similar) and have them read/comment on that list. To start off with, it would be great if we could see the rationale for the ZPL, and how they think it applies to the current situation.
Explain why it's important to you and why you can't get by on the current situation. You can send them directly or I can forward emails to the management. Shane
On 22 Jun 2001 10:29:19 -0400, Shane Hathaway wrote:
On Friday 22 June 2001 04:24, Erik Enge wrote:
I'd love to lobby DC to start thinking about this, how do I get in touch with the management team? It would be great if we could discuss this on zope-licenses@zope.org (or similar) and have them read/comment on that list. To start off with, it would be great if we could see the rationale for the ZPL, and how they think it applies to the current situation.
Explain why it's important to you and why you can't get by on the current situation. You can send them directly or I can forward emails to the management.
a lot of people use Zope. a lot of people release under the GPL, mainly because they don't want others (companies?) to "use" their code wothout giving back something (their code) or release modified code without giving back the modifications. a lot of people belongs _both_ groups and experience a lot of difficulties releasing code for zope. i think that releasing zope under a gpl-compatible license or under a double license (zpl+gpl, the distributor can choose) will do a lot of good to the people using the gpl and *no harm* to dc, because being dc holder of the copyright can always distribute under alternate licenses, usefull to its business plans, etc. also, the gpl-compatible license seems better to me than double license, because everybody (not only the users on one of the two licenses) will be able to include and distribute *any* code written for zope. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org Quis custodiet ipsos custodes? -- Juvenal, Satires, VI, 347
Thanks for a most illuminating thread. Slight clarification to a comment of yours Shane - Shane Hathaway <shane@digicool.com> writes:
GPL code together. ZWiki is just in a strange position because the GPL is not actually in effect.
I'm not sure I'd use those words - the license is certainly fully "in effect", I'd say, if not exactly "enforced by a battalion of lawyers". One of the consequences being that someone re-distributing zope & zwiki together, under their default licenses, is technically in violation right now, I think we are all agreeing. I'm not aware of anyone doing this right now, though there was a zwiki package for Debian GNU/linux at one point. Would Debian be in violation shipping both zope & zwiki packages on a cd ? If they thought so, sooner or later one or the other would get dropped from the distribution. Unfortunate and detrimental to both zwiki and zope. In principle this would apply to all linux distributions. Does this serve as an example of a problem with the current situation for DC management ? Another would be the fact that DC's own options are limited if it (DC) ever had the desire to distribute or sell something leveraging zwiki. Sure, it could convince me that LGPL makes better sense, or offer me a large sum of money to draw up a special alternate license (hey, on the double :-). But this would have to be repeated with each developer where the situation arose. Probably better to update the ZPL to solve this problem in one sweep, ensure that zope is participating fully within the preeminent sphere of software creativity, and earn a whole bunch of new support from the world developer community. And python did it. And there's no downside to making yourself GPL-compatible that I can think of.
Explain why it's important to you and why you can't get by on the current situation. You can send them directly or I can forward emails to the management.
Thanks Shane, please forward. DC management, please consider yourself lobbied - I'd like to encourage you to review the situation and consider making some adjustments to zope's license, or join our discussion here. Best regards -Simon
On 22 Jun 2001 09:33:22 -0700, Simon Michael wrote:
Thanks for a most illuminating thread. Slight clarification to a comment of yours Shane -
Shane Hathaway <shane@digicool.com> writes:
GPL code together. ZWiki is just in a strange position because the GPL is not actually in effect.
I'm not sure I'd use those words - the license is certainly fully "in effect", I'd say, if not exactly "enforced by a battalion of lawyers".
One of the consequences being that someone re-distributing zope & zwiki together, under their default licenses, is technically in violation right now, I think we are all agreeing.
right.
I'm not aware of anyone doing this right now, though there was a zwiki package for Debian GNU/linux at one point. Would Debian be in violation shipping both zope & zwiki packages on a cd ? If they thought so, sooner or later one or the other would get dropped from the distribution. Unfortunate and detrimental to both zwiki and zope. In principle this would apply to all linux distributions.
not only. i can assure you that somebody in debian find even a single line of gpl code in the zope main packge zope will be removed from the distribution until license compatibility is (re)estabilished. same story for zope products currently available in debian. i don't have all that time, so i wont be the guy doing that, but, first or later, someone will surely try to track down all the licens incompatibilities in zope debian packages. just look at the kde/qt problem (now fortunately resolved...)
Does this serve as an example of a problem with the current situation for DC management ?
Another would be the fact that DC's own options are limited if it (DC) ever had the desire to distribute or sell something leveraging zwiki. Sure, it could convince me that LGPL makes better sense, or offer me a large sum of money to draw up a special alternate license (hey, on the double :-). But this would have to be repeated with each developer where the situation arose.
right. maybe dc has some to gain froma gpl-compatible zope and not only the no-harm i detailed before.
Probably better to update the ZPL to solve this problem in one sweep, ensure that zope is participating fully within the preeminent sphere of software creativity, and earn a whole bunch of new support from the world developer community.
And python did it.
And there's no downside to making yourself GPL-compatible that I can think of.
absolutely. ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org 99.99999999999999999999% still isn't 100% but sometimes suffice. -- Me
On Friday 22 June 2001 12:33, Simon Michael wrote:
Thanks for a most illuminating thread. Slight clarification to a comment of yours Shane -
Shane Hathaway <shane@digicool.com> writes:
GPL code together. ZWiki is just in a strange position because the GPL is not actually in effect.
I'm not sure I'd use those words - the license is certainly fully "in effect", I'd say, if not exactly "enforced by a battalion of lawyers".
Agreed. The GPL tends to make it difficult to nail down precise words. I think that's one reason people get into GPL shouting matches.
One of the consequences being that someone re-distributing zope & zwiki together, under their default licenses, is technically in violation right now, I think we are all agreeing.
Technically yes, although I like to think that the product developers implicitly grant redistribution permission by attempting to apply the GPL.
Does this serve as an example of a problem with the current situation for DC management ?
I've forwarded your message and Federico's. Thanks!
Probably better to update the ZPL to solve this problem in one sweep, ensure that zope is participating fully within the preeminent sphere of software creativity, and earn a whole bunch of new support from the world developer community.
I think you're right. The reaction to the Python license becoming GPL compatible wasn't as enthusiastic as I expected, though.
Thanks Shane, please forward. DC management, please consider yourself lobbied - I'd like to encourage you to review the situation and consider making some adjustments to zope's license, or join our discussion here.
I'll let you know when they reply. Or maybe they will. Shane
Shane Hathaway <shane@digicool.com> writes:
One of the consequences being that someone re-distributing zope & zwiki together, under their default licenses, is technically in violation right now, I think we are all agreeing.
Technically yes, although I like to think that the product developers implicitly grant redistribution permission by attempting to apply the GPL.
I'm not sure that would be a valid assumption. Speaking for myself, it wasn't my particular intention to unconditionally grant that permission given the licenses as they stand. I mean, I didn't intend that zwiki's GPL be some kind of watered-down GPL. :)
I think you're right. The reaction to the Python license becoming GPL compatible wasn't as enthusiastic as I expected, though.
Well, I'm guessing there was a shout of joy around the world - it made my day. I think many of us then said "well thank god for some sanity" and got on with the productive work that needed doing. Unfortunately the positive reactions are less apparent than the kind we have when disaster is looming. Cheers -Simon
Simon Michael <simon@joyful.com> writes:
Well, I'm guessing there was a shout of joy around the world - it made my day. I think many of us then said "well thank god for some sanity"
PS, and in case that wasn't clear - I want to say a BIG THANK YOU to all who put so much hard work into solving the Python licensing problems. -Simon
On 22 Jun 2001, Simon Michael wrote:
Shane Hathaway <shane@digicool.com> writes:
One of the consequences being that someone re-distributing zope & zwiki together, under their default licenses, is technically in violation right now, I think we are all agreeing.
Technically yes, although I like to think that the product developers implicitly grant redistribution permission by attempting to apply the GPL.
I'm not sure that would be a valid assumption. Speaking for myself, it wasn't my particular intention to unconditionally grant that permission given the licenses as they stand. I mean, I didn't intend that zwiki's GPL be some kind of watered-down GPL. :)
May Stallman forgive me (fun intended :-): """ Date: Thu, 21 Jun 2001 16:43:05 -0600 (MDT) From: Richard Stallman <rms@gnu.org> To: morten@thingamy.net Subject: Re: Mixing different licences Another question is whether or not it's legal to use GPL-ed Zope products with Zope. That is a hard question. I don't know whether Zope is just an interpreter or contains facilities that, in effect, the user program links with. It makes a difference. If the former, you can run programs on Zope regardless of their licenses. If the latter, then in general, you can't take someone's GPL-covered code and combine it with Zope, because the Zope license is GPL-incompatible. If someone wrote a GPL-covered program specifically for Zope, you are pretty safe taking that as implicit permission to combine it with Zope. But it would be better for them to give explicit permission. """ Implicitly yours, Morten
"Morten W. Petersen" <morten@thingamy.net> writes:
""" Date: Thu, 21 Jun 2001 16:43:05 -0600 (MDT) From: Richard Stallman <snip> If the latter, then in general, you can't take someone's GPL-covered code and combine it with Zope, because the Zope license is GPL-incompatible.
If someone wrote a GPL-covered program specifically for Zope, you are pretty safe taking that as implicit permission to combine it with Zope. But it would be better for them to give explicit permission.
Now here, I have to assume RMS is using "combine" above to mean "combine and redistribute". I hope I'm right ? If "combine" included "install zwiki on your zope installation and use it" then everything I know is wrong.. I did intend for that to be fairly danger-free. -Simon
On 22 Jun 2001, Simon Michael wrote:
Now here, I have to assume RMS is using "combine" above to mean "combine and redistribute".
I hope I'm right ? If "combine" included "install zwiki on your zope installation and use it" then everything I know is wrong.. I did intend for that to be fairly danger-free.
I'm not sure, I've fired off another email to get a clarification. While we're one the topic, I just read an article [1] over at Kuro5hin that could enlighten the management over at Digicool and us as well; it discusses the impacts of Free Software and relates it to Free Trade, talks about barriers and other interesting things.
From the practical point of view, being able to use GPL-ed software with Zope is a Good Thing (TM) for most developers.
Another thing is that some people / companies may be reluctant to add signifcant modules that could be included in the Zope core, as they will not get the same level of recognition for their work as Digital Creations would. For me personally, a Zope license without the advertising clause would motivate me, as the 'protection barrier' / 'restriction' / 'attribution issue' wouldn't be there; I have a ton of things I'd like to change in Zope and add to Zope, and as time goes by, the who-gets-credit-issue will undoubtedly be raised again, if we're so lucky that Digicool decides to open up Zope for read/write CVS access. [1] http://www.kuro5hin.org/?op=displaystory;sid=2001/6/23/3451/16661 -Morten
On Fri, Jun 22, 2001 at 01:16:04PM -0400, Shane Hathaway wrote:
I think you're right. The reaction to the Python license becoming GPL compatible wasn't as enthusiastic as I expected, though.
Are you talking about the reactions on Slashdot.org? The reactions there were exactly as to be expected; uninformed and unintelligent. And those are the posts that get score 3 and up, I never read Slashdot posts below that. -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------
On 21 Jun 2001 17:18:40 +0200, Federico Di Gregorio wrote:
On 21 Jun 2001 11:08:30 -0400, Jim Penny wrote: [snip]
OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software?
My understanding is that the answer to every one of these is yes.
yes. only if it is free. only if it is free. yes, but only because gpl allows for gpl code linking with the major components of the os even if they are proprietary.
May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no.
Now, s/operating system/zope/g
Do the answers to the questions change? And, if so, why?
From my perspective, and I think from fog's the answer is that it should not change the answers.
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your
No, No, no, NO! The License of PYTHON only applies to modifications, derivations, etc. of _PYTHON_, NOT anything _written_ in it. (BTW, according to the gnu site, Python 2.0.1 and 2.1.1 (and later) ARE GPL-compatible :) Bill
On 21 Jun 2001 12:07:36 -0600, Bill Anderson wrote: [snip]
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your
No, No, no, NO!
The License of PYTHON only applies to modifications, derivations, etc. of _PYTHON_, NOT anything _written_ in it.
you stand right here. i was thinking about psycopg that actually is C code that gets linked to python. but the border is not that clear. the question, as always, is: what if i subclass python core classes (released under the python license)? but that's a purely academical question, i think... federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog@mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog@debian.org All programmers are optimists. -- Frederick P. Brooks, Jr.
On 21 Jun 2001 21:18:16 +0200, Federico Di Gregorio wrote:
On 21 Jun 2001 12:07:36 -0600, Bill Anderson wrote: [snip]
err, no. if you write an external module using only python code, as long as you use a gpl-compatible python to run zope, you can call your
No, No, no, NO!
The License of PYTHON only applies to modifications, derivations, etc. of _PYTHON_, NOT anything _written_ in it.
you stand right here. i was thinking about psycopg that actually is C code that gets linked to python. but the border is not that clear. the question, as always, is: what if i subclass python core classes (released under the python license)? but that's a purely academical question, i think...
At that point, it is rather academic. To carry it to the full, we would then need to look at the license on C, and determine if that had an effect, and I am sure we could carry it down even further, but as you said, it is academic. Almost philosophical.
On Thu, Jun 21, 2001 at 11:08:30AM -0400, Jim Penny wrote:
OK, consider this from another point of view. If I have an operating system may I install a piece of GPL software on the operating system? May I redistribute the operating system? With the GPL software? May I invoke/run the GPL software?
My understanding is that the answer to every one of these is yes.
May I modify the GPL software and distribute it without giving downstream the same opportunity. Clearly no.
Now, s/operating system/zope/g
Do the answers to the questions change? And, if so, why?
From my perspective, and I think from fog's the answer is that it should not change the answers.
Maybe the easy way out of this is to simply declare zope an "operating system" rather than an "application". Snippy thoughts cut here.
The specific exception in the GPL reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. I.e. if you declared Zope an operating system on its own (which is certainly arguable), then you could link GPL components with Zope (be it scripts, Zope products, or C libraries) without worrying about the license of Zope. Still, this would not include add-ons to Zope that are not distributed with the main Zope distribution. I.e. you would not be allowed to use ZPL add-on products alongside with GPL components (the add-ons didn't come with the OS, therefore the exception doesn't cover them). Strange, isn't it ? Gregor
On Wed, Jun 20, 2001 at 10:38:03AM -0500, Steve Drees wrote:
Here comes the liscence wars again.
Still haven't figured out how GPL became the holy grail.
The license dicussion takes place elsewhere as all of you surely know. License wars tend to come up at various places but are usually not competent discussions. Thus I recommend not to start a thread on licensing basics here at this place. Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/
Jan-Oliver Wagner <jan@intevation.de> writes:
The license dicussion takes place elsewhere as all of you surely know. License wars tend to come up at various places but are usually not competent discussions.
With respect - loose talk of "license wars" should be avoided. What you say is true but not relevant to this thread. These issues are not basic, and they matter most to zope developers. I think this is a very good place for those who are interested to have a discussion about them. -Simon
reviewing the thread just now, I couldn't figure out how Jan-Oliver first participated and then argued against it. Now I think he was responding to Steve Drees and not saying what I thought he said. Sorry Jan! :) so-far-so-good-ly'rs, -Simon
On Wed, Jun 20, 2001 at 06:39:00PM -0700, Simon Michael wrote:
reviewing the thread just now, I couldn't figure out how Jan-Oliver first participated and then argued against it. Now I think he was responding to Steve Drees and not saying what I thought he said. Sorry Jan! :)
I am not sure what you want to express with your statement. I think it is important to raise the license issue as such on this list (statements of concerned users - very important for any free software product) and so I added my concerns about the license. But the deeper pro/contra argumentation often tends to be of less accuracte style (especially the words used) and as I saw the beginning of this style I sent a second posting to stop this. Well, it helped perhaps - at least there was no flame war this time :-) Jan -- Jan-Oliver Wagner http://intevation.de/~jan/ Intevation GmbH http://intevation.de/ FreeGIS http://freegis.org/
On Wed, 20 Jun 2001 16:50:33 +0200 (CEST), "Morten W. Petersen" <morten@thingamy.net> wrote:
and the 'obnoxious advertising clause' seemingly puts a stop to it..
I understand that 'obnoxious advertising clause' is the phrase used by the FSF to describe this type of license clause, however I wonder whether you (personally, or as an organisation) really find it to be 'obnoxious'? Personally, I am *happy* to respect clause 4. Toby Dickenson tdickenson@geminidataloggers.com
On Thu, Jun 21, 2001 at 11:47:49AM +0100, Toby Dickenson wrote:
On Wed, 20 Jun 2001 16:50:33 +0200 (CEST), "Morten W. Petersen" <morten@thingamy.net> wrote:
and the 'obnoxious advertising clause' seemingly puts a stop to it..
I understand that 'obnoxious advertising clause' is the phrase used by the FSF to describe this type of license clause, however I wonder whether you (personally, or as an organisation) really find it to be 'obnoxious'?
Personally, I am *happy* to respect clause 4.
Please, don't try to critize the FSF just for the fun of it. Have you read the FSF's comment about the original 'obnoxious advertising clause' ? The problem is a practical one, and a real one: The old BSD license said that, if you incorporated their code in your product, every advertisement for your product had to carry this line: This product includes software developed by the University of California, Berkeley and its contributors. As long as there was only this UCB license, this was no real problem. But imagine you're preparing a *BSD distribution, and you're using material from a dozen different sources. Would you like to include something like this in every advertisement for a *BSD CD-ROM ? This product includes software developed by the University of Clifornia, Berkeley and its contributors. This product includes software developed by the University of Dalifornia, Derkeley and its contributors. This product includes software developed by the University of Edinburgh, UK and its contributors. This product includes software developed by the University of Frankfurt, Germany, and its contributors. This product includes software developed by Gimian Inc., MA, and its contributors. This product includes software developed by Himian Inc., MA, and its contributors. This product includes software developed by Kimian Inc., MA, and its contributors. This product includes software developed by Limian Inc., MA, and its contributors. This product includes software developed by Nimian Inc., MA, and its contributors. This product includes software developed by Ximian Inc., MA, and its contributors. This product includes software developed by Ximian Inc., MA, and its contributors. This product includes software developed by Timian Inc., MA, and its contributors. This product includes software developed by Mark Red, NY, and other contributors. This product includes software developed by Mark Brown, OH, and other contributors. This product includes software developed by Mark Green, IL, and other contributors. This product includes software developed by Mark Blue, IL, and other contributors. This product includes software developed by the University of Taipeh, Taiwan and its contributors. This product includes software developed by the University of Greenland and its contributors. This is why the FSF calls this clause obnoxious (http://www.gnu.org/philosophy/bsd.html). I don't know about you, but IMHO they're right at this point. Gregor PS: Please also note that the University of California, where this clause originated, has removed it from their licenses. I don't think they did it without a reason.
participants (17)
-
Bill Anderson -
Casey Duncan -
Dieter Maurer -
Erik Enge -
Federico Di Gregorio -
Gregor Hoffleit -
Gregor Hoffleit -
Jan-Oliver Wagner -
Jim Penny -
Martijn Pieters -
Michel Pelletier -
Morten W. Petersen -
Nils Kassube -
Shane Hathaway -
Simon Michael -
Steve Drees -
Toby Dickenson