Re: Corba interfaces and GPL freedom
--- Iain Barker [EMAIL PROTECTED] wrote: I am concerned whether a Corba interface can be used by non-free software to circumvent the freedoms and requirements of the GPL license. This is a similar issue as with the introspector. I dont aggree with your assessment any more. I realise mere aggregation vs the definition of a copyright derived work is a complex scenario, so I will try to keep my posting generic. A proprietary vendor could create non-free software that functionally would amount to a derived work, without actually making a derived work within the meaning of copyright law. Would this break the spirit of the GPL while complying with its terms, hence not be enforcable under copyright law? I dont think it will. I have seen the Corba 'serverizing' analogy discussed on this list, and have looked around the FSF website for clarification but I don't see any position statement from FSF addressing this issue. The nearest entry in the FSF GPL-FAQ is the pipes and sockets definition, which suggests this form of abstract inter-process communication is an acceptable mechanism for GPL software to interwork with non-free modules. basically this is the issue of creating a new front end and linking it in. Same issue with xmlrpc, same issue with serialization. not covered by the gpl. I've also read the earlier icense-discuss postings of Mr Perens, Mr Stallman and others regarding the use of Corba in this manner. The absence of a position from the FSF appears to be potentially damaging the GPL community, which risks losing freedom to the proponents of non-free software. There is no position because it is a losing positiion. Here is an example of Corba 'serverizing': A GPL application is modified by a vendor of non-free software, who adds a Corba server API to the application. The vendor releases the source code to the GPL application and modifications per the GPL terms. like metawrap. like samba. like .. you name it. j2ee. The vendor then creates a non-free Corba client application which uses that API but incorporates none of the GPL code. The source code to the client application is not released by the vendor. Non-free applications could also be used as Corba servers to a GPL client application in the same manner. This is the openess of the network. MySql maintains that this is linking and requires clients licenses, I think this is bogus. Essentially the freedom of the GPL codebase is reduced either way around. I dont think the freedom of the codebase is reduced, i think that you are just pointing out that the freedom of the users is increased. This freedom of the users is a fair thing, and it has to be respected. The gpl is not appliciable to situations like this, because it is a EULA agreement that is needed to cover situations like that. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Corba interfaces and GPL freedom
--- Iain Barker [EMAIL PROTECTED] wrote: The GPL FAQ clarifications from FSF attempt to extend the definition of what constitutes a derived work: 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. These extended definitions may be beyond what might be supported by Copyright law as a derived work, in which case there is a very real risk that the GPL would not provide the intended protection for the free code. This clause is just FUD. It is designed to scare away people from doing so, and has no basis. I wonder when that was added, It must have came after some big discussion of the gcc mailing list. My view is that the freedom of the GPL code is reduced because at its most extreme, such an API could be added to the GPL code to export *all* of the functions for use by separate programs. The term Mr Perens used was server-ized That is somehing that I am working on, the introspector is doing something like that. See my advogato article for more details : http://www.advogato.org/article/701.html I think this this is a valid topic, and I have been through it all before. mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Corba interfaces and GPL freedom
--- David Johnson [EMAIL PROTECTED] wrote: On Sunday 14 September 2003 09:00 am, Iain Barker wrote: Free Software should not be afraid of competition. If someone comes along and serverizes the software, we should not be wringing our hands, but busy writing Free clients instead. You could also make a free mysql client and claim that it is not derived work! so it looks to me like there is nothing to prevent proprietary code from server-izing any GPL code and exploiting it for non-free purposes, without any obligation to give back the greater work to the community. You've hit the nail on the head. Sometimes you have to just step back, sigh, and accept that fact that there will always be proprietary software. You will always have someone who takes and not gives in an population. There is no protection by the GPL for very creative ways of doing that. But if we look at the extensions to copyright law in the case of consumables, then you will get into something interesting. When you have a workbook or example in a textbook, it is under a stronger version of the copyright, because copying it would do harm to the publisher. The software author whose software is exposed by the network interface could claim that his profits are affected by someone unfairly copying his work. The copyright law is intended on protecting the people who have the money to lobby, so you see such perversion in the law. That is why I have proposed a GFDL consumable database : http://fsedu.org/fsedu.pl?Consumables that could be put under the stronger term consumable clause and therefore none could copy it without permission... that might make an new and interesting license . mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Corba interfaces and GPL freedom
Iain Barker [EMAIL PROTECTED] writes: A proprietary vendor could create non-free software that functionally would amount to a derived work, without actually making a derived work within the meaning of copyright law. Would this break the spirit of the GPL while complying with its terms, hence not be enforcable under copyright law? On Sun, 14 Sep 2003, Ian Lance Taylor wrote: The Open Software License is intended to address this issue. http://opensource.org/licenses/osl-2.0.php See also the Affero license at http://www.affero.org/oagpl.html. This apparently has some FSF support. However, I firmly believe that all attempts to close this loophole are excessive restrictions on the USE of software, and go way beyond restrictions on distribution. Debian has rejected some licenses based on failure of the dissident test, and I hope will adopt a right to privacy as one of the important software freedoms. Forced distribution is a very nasty requirement, which I personally consider non-free, although not all do. Please note when considering this issue that I am a user of: My ATM software. Router software at every hop between me and anywhere. My cable company's billing software. AOL's SMTP software (I am not an AOL customer, but I send mail to them). Many other software that are used on my behalf, but never distributed to me. Whether it's invoked over RPC, SOAP, SMTP, snail-mail, or run as the result of a telephone conversation is irrelevant. People who modify open-source software should be allowed to keep those modifications private, even if they use them as part of a public service. If the software is distributed, then it's required to include source for the recipient. I have heard that the FSF has been considering whether and how to address this in GPLv3. However, this has been a rumor for a long time now. I hope it stays a rumor, like many very bad ideas. It's persistent enough that I strongly recommend people NOT add or any later version to their GPL work, and I'm glad the Linux kernel folk agree. -- Mark Rafn[EMAIL PROTECTED]http://www.dagon.net/ -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Corba interfaces and GPL freedom
On Sun Sep 14 01:54:35 EDT 2003, [EMAIL PROTECTED] wrote: Here is an example of Corba 'serverizing': A GPL application is modified by a vendor of non-free software, who adds a Corba server API to the application. The vendor releases the source code to the GPL application and modifications per the GPL terms. The vendor then creates a non-free Corba client application which uses that API but incorporates none of the GPL code. The source code to the client application is not released by the vendor. Non-free applications could also be used as Corba servers to a GPL client application in the same manner. Essentially the freedom of the GPL codebase is reduced either way around. So does that mean that any program interaction with GPL code is considered reducing the freedom of the codebase? Why single out CORBA? Why not any RPC mechanism like SOAP? How about CGI-BINs? Where does one draw the incredibly fuzzy line? -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Corba interfaces and GPL freedom
David Presotto [mailto:[EMAIL PROTECTED] wrote: So does that mean that any program interaction with GPL code is considered reducing the freedom of the codebase? Why single out CORBA? Why not any RPC mechanism like SOAP? How about CGI-BINs? Where does one draw the incredibly fuzzy line? Yes, Corba is just one example, any similar RPC mechanism can be substituted for the same purpose. Anything that essentially allows two otherwise distinct and separate programs to make use of each others functionality via some type of abstract interface. As Mr Johnson's earlier reply pointed out, the program interaction at runtime isn't really the issue here - GPL is really a distribution (copying) license rather the a user licenses more traditionally used for non-free software. My concern is with the potential for deliberate subversion of free GPL code for non-free purposes. The GPL relies upon Copyright to define the extent a derived work and that may be a weakness. From the GPL: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications The 'incredibly fuzzy line' therefore becomes the interpretation of what constitutes a work when the non-free application and the free application are distributed as a larger whole or collective work. The GPL itself contains wording for this scenario: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program ... 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 ... the intent is to exercise the right to control the distribution of derivative or collective works based on the Program... That seems clear enough, the larger whole including the non-free application must be distrubuted under GPL, which is what I have always assumed to be the case. But here we get to my concern: The term work based on the Program has already been defined in the GPL as the Program or any derivative work under copyright law. In the previous example, the non-free application is a separate program and contains none of the original GPL code, therefore on its own merits I do not see how it would be considered a derived work under Copyright law. (Note: I am not a lawyer, and the above is an interpretation which could well be the root of my misunderstanding, so please correct me if I am wrong.) The mere aggregation clause also helps to confuse the issue further: 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. The GPL FAQ clarifications from FSF attempt to extend the definition of what constitutes a derived work: 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. These extended definitions may be beyond what might be supported by Copyright law as a derived work, in which case there is a very real risk that the GPL would not provide the intended protection for the free code. My view is that the freedom of the GPL code is reduced because at its most extreme, such an API could be added to the GPL code to export *all* of the functions for use by separate programs. The term Mr Perens used was server-ized If the copyright definition of a derived work doesn't cover the RPC scenario, the GPL definition of work based on the Program is invalidated. The GPL explicitlly doesn't prevent aggregation on the same media, so it looks to me like there is nothing to prevent proprietary code from server-izing any GPL code and exploiting it for non-free purposes, without any obligation to give back the greater work to the community. In that case the server-ized GPL code becomes less free, more akin to LGPL status with less freedom than was intended by the author when they placed it under protection of the GPL. Anyway, that is the point I wanted to try and convey - it all just seems a little too unfair and arbitrary to me. I guess that's how lawyers make their money ;-) I don't know if this is a real problem or if I am just being alarmist or misunderstanding the situation. In either case, I don't know how it could be fixed other than to put a more explicit definition of collective work into the next version of the GPL. If anyone has any suggestions or clarifications, I welcome them either online or offline from this list, thanks. ps. Sorry to take up so much bandwidth on the list, and for the initial double posting. -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
Re: Corba interfaces and GPL freedom
On Sunday 14 September 2003 09:00 am, Iain Barker wrote: Yes, Corba is just one example, any similar RPC mechanism can be substituted for the same purpose. Anything that essentially allows two otherwise distinct and separate programs to make use of each others functionality via some type of abstract interface. You've just made the incredibly fuzzy line much fuzzier. There needs to be drawn a clear and distinct line, but making use of others functionality is way too vague. Everything in the UNIX/POSIX environment makes use of the functionality of other distinct and separate programs. All of my programming work would come to a complete standstill if I had to examine the license to each and every program whose functionality I might possibly use via some type of abstract interface. My view is that the freedom of the GPL code is reduced because at its most extreme, such an API could be added to the GPL code to export *all* of the functions for use by separate programs. The term Mr Perens used was server-ized If they are truly separate programs, then the freedom of the GPL code has not been diminished at all. Everyone who receives the code receives the full right to copy, distribute and modify it. That there is now a new interface or front end to the code makes no difference. Free Software should not be afraid of competition. If someone comes along and serverizes the software, we should not be wringing our hands, but busy writing Free clients instead. so it looks to me like there is nothing to prevent proprietary code from server-izing any GPL code and exploiting it for non-free purposes, without any obligation to give back the greater work to the community. You've hit the nail on the head. Sometimes you have to just step back, sigh, and accept that fact that there will always be proprietary software. -- David Johnson ___ http://www.usermode.org -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
