Re: [License-discuss] GPL and proprietary WebAPIs
Quoting Clark C. Evans (c...@clarkevans.com): I think MySQL AB's licensing strategy is offered in this forum as an overreach. In particular, Larry Rosen argues that there is no derived work when an application simply uses MySQL as intended via its public interface, even if the application relys upon specific MySQL functionality. MySQL AB's sales staff is reputed to have made claims to customers that were insupportable. (Whether that thus constitutes a licensing strategy I would not know, but I'm generally not quite that cynical.) That is, the sales staff were reputed to have told customers that, if they used any proprietary software whatsoever in conjunction with MySQL in any way, then the fact that MySQL's client libraries were under GPLv2 with a meant that the customer was obliged to purchase a for-money licence to use MySQL Enterprise instead of using an instance under open source licensing. This was a doubtful argument in several ways at the same time: 1. MySQL wasn't pure GPLv2 anyway, but GPLv2 with a GPL linking exception clause of some sort (something like Classpath's; I don't care enough to look up particulars at the moment). 2. Even if the linking exception clause weren't present, the implied notion that _any_ ancillary software is inherently a derivative work of MySQL RDBMS and its access libraries is laughable. 3. If the problem is licensing of the access libraries, then there are also several other usable access libraries, some under liberal academic licences. (Reportedly, the sales staff carefully failed to mention that.) Which is mostly just a case in point about why a businessman who talks directly to salesman and believes what they say without investigation has a fool for a negotiator. -- Rick Moen 'Decimate' when referring to killing one r...@linuxmafia.comin ten. 'Octomate' when referring to the McQ! (4x80) cephalopod dating site. -- FakeAPStylebook ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
Rick Moen scripsit: MySQL AB's sales staff is reputed to have made claims to customers that were insupportable. (Whether that thus constitutes a licensing strategy I would not know, but I'm generally not quite that cynical.) Maybe not, but lying to your customers is definitely a *business* strategy. Whether or not MySQL AB employed it, my first employer certainly did. Their salesmen were told to say the software could do anything the customer asked for, and the programmers (including me) had the job of cashing out these promises, however extravagant. I eventually got sick of this and left, whereupon some enterprising person issued a post-final paycheck in my name and forged my signature to it. Shortly after, the company collapsed. Four equally bogus companies later, the principals finally found themselves under arrest. Which is mostly just a case in point about why a businessman who talks directly to salesman and believes what they say without investigation has a fool for a negotiator. *shrug* Unbiased advice is always hard to come by. -- John Cowan co...@ccil.org http://www.ccil.org/~cowan Raffiniert ist der Herrgott, aber boshaft ist er nicht. --Albert Einstein ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
Good answer, John! Same with me, deceniums agao, at GEISCO (General Electric Information Services). But you do *never know* what the future does bring ... ** unless you actively do try to INFLUENCE it (the future of human beeings) ** Watch me at Thomas.Schneider.Wien, at FaceBook, Skype, etc... Then you will know ;-) Thomas Schneider. PS: AND: I will definitely need help from many, many individual humans :-) = Am 27.12.2011 19:53, schrieb John Cowan: Rick Moen scripsit: MySQL AB's sales staff is reputed to have made claims to customers that were insupportable. (Whether that thus constitutes a licensing strategy I would not know, but I'm generally not quite that cynical.) Maybe not, but lying to your customers is definitely a *business* strategy. Whether or not MySQL AB employed it, my first employer certainly did. Their salesmen were told to say the software could do anything the customer asked for, and the programmers (including me) had the job of cashing out these promises, however extravagant. I eventually got sick of this and left, whereupon some enterprising person issued a post-final paycheck in my name and forged my signature to it. Shortly after, the company collapsed. Four equally bogus companies later, the principals finally found themselves under arrest. Which is mostly just a case in point about why a businessman who talks directly to salesman and believes what they say without investigation has a fool for a negotiator. *shrug* Unbiased advice is always hard to come by. -- Thomas Schneider (Founder of www.thsitc.com) Member of the Rexx Languge Asscociation (www.rexxla.org) Member of the NetRexx Developer's Team (www.netrexx.org) ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
John, Thank you for your reply. On Tue, Dec 27, 2011, at 11:18 AM, John Cowan wrote: Does the GPL prevent the distribution of M if the work it relies upon, P, isn't compatibly licensed? Web browsers rely on web servers to provide most of their function (take it from someone who was recently cut off from the Internet for three whole days), and also on the entire Internet infrastructure of routers and so on. Most of this infrastructure, and many web servers, runs proprietary software, but nobody argues that a GPLed web browser can legally interact only with GPLed servers using GPLed infrastructure. I'm not arguing for this interpretation, this would be a restriction on how software may be used (clearly non-free). You offered earlier a thoughtful remark: | Microsoft grants explicit permission to use its SDKs to | construct software that is intended to run on Windows. | If it happens to run on non-Windows systems such as | ReactOS or Wine, that is not the developer's fault. So, I look at it in a similar manner: if a derivative work in the form of a shim/adaptation can be used as advertised using only free software, then the requirement that the whole work be licensed in a compatible manner is met. That the shim or adapter might work with a proprietary implementation of that same free software is an acceptable outcome. It is the user's right to operate their copy of the software with a proprietary implementation. With this view, if a derivation (shim or adaption) requires proprietary software (with no open source substitutes) in order to function as expected, then the whole of the work, and all its parts, regardless of how they are packaged has not been compatibly licensed. In this case, while the author may wish to distribute their improvement under the GPL, they are barred from doing so under 5(c) since their improvement effectively requires that one obtain a proprietary license to enjoy the derived work. So, back to your question. Given my interpretation, the only issue with a GPL'd web browser might be the inclusion of features that only work in combination with a proprietary web server (and lack an open source implementation). In this case, there are three options: (a) make an exception in the license, this is what the System Libraries stuff is all about, (b) implement the quirks/features of the proprietary web server as a derived work from an open source web server, or (c) use a different license. I think that (b) is a very fair tradeoff. If a vendor would like to add support for proprietary webserver features to a GPL'd web browser, they should be willing to provide a reference implementation with the complete functionality they wish to incorporate. How else could one only using free software take advantage of the feature they have added to the web browser? How else could you maintain this addition to the commons and know it works? On Tue, Dec 27, 2011, at 02:49 AM, John Cowan wrote: My question involves 3 works, not 2. We have a original work O, a derived work D (O + a shim/adapter), and an independent proprietary work P; where D derived from O under copyright law, D relies upon P for its operation, and where P has no substitutes. I am assuming that by copyright law the author of O can restrict the distribution of D. Let's further assume that P has no substitutes, so that its functionality is not available under a license compatible with the GPLv3. So, my question is if the GPLv3 would restrict the distribution of D due to its dependence on this independent and proprietary work P. As a worst case, the behavior of P can be reverse engineered, since it is communicating openly with D in a way that can be analyzed. I think this misses the point entirely. If it's easy enough to embed proprietary functionality via shims without providing an open source implementation of the complementary functionality, then copyleft doesn't really serve much purpose, except for being a nuisance. The shim you'd get would be a minimal conversion from your data structures to something that could be then converted into theirs... how'd that be useful to reverse engineering? Why should the burden of reverse engineering be placed on the one contributing free software to the commons? If you don't know about the Affero GPL3, you should look into it. Yes, but the AGPLv3 addresses a completely different problem; it also faces the same challenge I'm outlining. I appreciate the the thoughtful engagement, I don't see why the proprietary Internet infrastructure has anything to do with what I'm discussing since I could create test just about anything using a set of networked virtual machines. Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Tue, Dec 27, 2011 at 5:07 PM, Tzeng, Nigel H. nigel.tz...@jhuapl.edu wrote: I'm trying to find an appropriate licensing strategy for our company, and I'm expressly trying to prevent and understand the sort of shims that seem to be standard industry practice. If our work can't be protected from these creative circumventions by the GPL, then we probably won't use this license. If it's not a derivative work then it's not a derivative work and you should have no heartache. If it is a derivative work then you have legal recourse to correct it. IMO, appropriate licensing strategy is far more a business decision than a legal one. If you wish to develop As others have suggested you can look at Affero if you think vanilla GPL v3 too lax. Note that Affero GPL does not in any way change the question of what is a derivative work and how you could insulate yourself from effects of (A)GPL by using a Web API or other shim approach. Since the FSF does not define what is a derivative work of something else, it obviously couldn't possibly do so. If A is a service and B is a program using this service over a HTTP Web API, and 1) A is licensed under the GPL, or 2) A is licensed under the AGPL In both cases #1 and #2 B could be licensed as whatever, the only difference is that in #2 the person who makes available A as a service has to make the source code of A available, as set forth by AGPL. The whole point of the derivative work debate is that the license of A does not have any effect on B. (Unless of course you are of the opinion it does have an effect, in which case that should be your opinion equally for both #1 and #2 anyway.) henrik -- henrik.i...@avoinelama.fi +358-40-8211286 skype: henrik.ingo irc: hingo www.openlife.cc My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
Re: [License-discuss] GPL and proprietary WebAPIs
On Tue, Dec 27, 2011 at 8:37 AM, Clark C. Evans c...@clarkevans.com wrote: First, thank everyone for their responses. I especially enjoy the reading material that Rick Moen has referenced. On Tue, Dec 27, 2011, at 10:07 AM, Tzeng, Nigel H. wrote: If it's not a derivative work then it's not a derivative work and you should have no heartache. If it is a derivative work then you have legal recourse to correct it. I'm concerned about the case where a shim/adapter could be ruled as derivative work and as such its distribution of such could be prohibited under copyright law --- but where the court does not consider the derivative work to include an independent proprietary component needed to actually use the derivative in a meaningful way. Two quick points: 1) Derivation is not contageous. SCO argued this in their lawsuit against AIX to absolutely no avail. Just because A is derivative of B and B is derivative of C, it doesn't follow that A is derivative of C. At least in the US, you have to show that the derived *expressions* from C made it from B into A. 2) Copyright has, IMHO, virtually nothing to do with dependencies at least in the US (IANAL). Copyright only protects expressive elements, and only to the extent they are separable from functional elements. This is why I don't think that #include readline.h is sufficient to create a derivative work, and even if it was, I could certainly create equivalent macros in my own code, and create a minimal .h file with only the exports I wanted ordered in a different order, and then there would be no derivative work at least in US law (don't know about Europe). Basically a .h file is ideally a set of facts (namely function prototypes). If there are additional expressive elements I don't see why those can't be stripped out. In the US, facts cannot be copyrighted, so I can copy all the whitepages directory listings in the country without violating anyone's copyrights (in Europe I know this is different however). In this case, does the GPLv3 create an additional contractual condition for the distribution of the covered work in 5(c) that would forbid the distribution of the shim if the required proprietary component is not also licensed compatibly? If copyright law doesn't require permission, then you don't need permission. And even the FSF draws a line between where things are in one process and where they communicate over pipes or sockets. Or, is 5(c) of the GPL essentially the same as the OSL and limited to only the scope of a derivative work. In this interpretation, you rely upon convincing the court that the entire derived work necessarily includes a component which is required for it's operation. That seems much harder case. Interesting thought experiment. Suppose I write a license functionally identical to the GPL (we'll call it the MGPL) but with the provision that all software written must be licensed under the same license if: 1) It is written by a person who is bound to the license by distributing MGPL'd software, and 2) Interacts with the MGPL'd software in any way. So if I write an MGPL'd web server than anyone who distributes this web server and also makes a web browser must license the web browser under the MGPL. I wonder if that would even meet the OSD, particularly the bit about not restricting other software? Might it be an edge case? IMO, appropriate licensing strategy is far more a business decision than a legal one. If you wish to develop an open source community around your product then GPL v3 + a proprietary license option like MySQL AB offered is safe enough for most practical purposes. I think MySQL AB's licensing strategy is offered in this forum as an overreach. In particular, Larry Rosen argues that there is no derived work when an application simply uses MySQL as intended via its public interface, even if the application relys upon specific MySQL functionality. It seems that Rick Moran and many others agree. Please note that my scenario is different, I'm talking about a competitor who would alter/transform/modify our work in order to add proprietary functionality -- not simply use it via its public interface. MySQL AB has argued many different things in the past in this area. They generally drew the line though between using a standardized interface like ODBC and directly linking to their libraries. ISTR a controversy on Slashdot regarding a statement that MySQL AB would treat exporting the API's of the client libs via a web service as an attempt to circumvent their licensing. Then your scenario of shims and creative circumventions isn't a negative but a positive as it enhances both your revenue stream and ecosystem. I can't disagree more. This technique, if the GPLv3 offers no defense against it, would permit our competitors to keep their exclusive proprietary licensing stream while actively integrating the benefit that our software would provide without
