Re: [License-discuss] GPL and proprietary WebAPIs
On 12/27/11 11: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. Yes, this strikes me as likely. An independent web service as suggested in your scenario is unlikely to be a derivative work. 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. 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 contributing back. The shim being an actual anti-contribution since it may confuse users what is free software and what isn't. As I said, it's primarily a business decision. If you are primarily a consulting firm who's business model is based on billable staff hours then if you consider your software this important to your value added then I might not open source it at all. If you are a product company your decision may be different. They are never obligated to contribute their work back to you anyway. Only to their own customers which may or may not ever bother to give it to anyone else. So even if your competitor elected to provide their library as source neither you nor anyone else may ever see it. It may also be in a deeply forked form not readily reusable by you. My impression is no form of open source is likely to ever give you the level of protection you desire. If nothing else my understanding is that if they are contracted on a work for hire basis to write a shim from your code to any proprietary library (theirs or anyone else's) then no distribution occurs and no licensing clause is triggered. GPL v3 explicitly addresses work for hire as not being a distribution. Regarding MySQL and their licensing strategy...lets just say that they leveraged any ambiguity to their greatest advantage. Most companies will likely be very conservative in their approach if the pain of paying you is low enough to be not worth the bother to attempt to circumvent. At some point cost is very secondary to service. Given that Oracle was likely quite a bit more than any mySQL commercial license anyway... If your software has such a structure where adding a proprietary library is easily done via a shim then having a real plug-in architecture and charging for an Enterprise version of your code strikes me as a good balance between open and a viable revenue stream. Besides, all the mental and emotional effort spent defending your assets in court is effort not spent on actually improving your core product whether that's billable hours or product sales. That's potentially even more deadly than infringement. That's also ignoring any monetary aspect. If you don't have a sufficient legal war chest to assert your rights in court how much does it really matter against an aggressive and unscrupulous competitor? If your risk tolerance is this low then open source is not likely the right sleep comfortably at night answer for you. Your source will be out there and if actually useful then someone will likely be using it in a way you probably wouldn't like. ___ 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
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
Re: [License-discuss] GPL and proprietary WebAPIs
On Sun, Dec 25, 2011, at 01:01 PM, Rick Moen wrote: Quoting Clark C. Evans (c...@clarkevans.com): What confuses me and what I'm asking here is why licensing professionals focus on two items that I consider irrelevant: (a) what is the type of linking between D and P? ... (b) is D a derived work of P? What we know is that D ... is derived from O and that D requires P for its operation. Please name one such licensing professional (who is not an FSF spokesman). What was on my mind was this journal article: Software Interactions and the GNU General Public License By Malcolm Bain in IFOSS L. Rev. Vol 2, No 2 (2010) (http://www.ifosslr.org/ifosslr/article/view/44) What was also on my mind was an informal side chat with an attorney on the stack overflow question [1]. I was referred to the GNU FAQ, especially the answer for plug-ins [2] where the applicability of the copyleft depends on how the program invokes its plug-ins and aggregation [3] where it says sockets... are normally used between two separate programs. This attorney said the specific details of the case were necessary to give any advice, but after my insistence, commented that the community consensus is likely correct. Probably you consider both of these professionals to be associated with the free software foundation. For what it's worth, our own corporate attorney doesn't have a concern with regard to linking technologies, he advices that GPL is quite vague and if we were to use it, we should publicly exclaim our interpretation. To this regard, Larry Rosen's comment [4] is refreshing, matches my expectations, and is broadly helpful: If GPL advocates insist upon distinguishing among types of functional linking, then talented software engineers will avoid disputes by building shims, APIs, or use dynamic linking to accomplish their functional goals. Unfortunately, this doesn't give me enough guidance on the applicability of copyleft; specifically with my 3-work scenario where someone uses a shim/adapter to include proprietary functionality via a WebAPI. I keep asking this in this public forum since it matters quite a bit to the effectiveness of the GPL. If this sort of work around is acceptable by the community, then other than nuance value, there really is no point in copyleft, and one should use Apache or keep the work proprietary. Assuming a shim/adapter creates a derived work under copyright law so that its distribution could be limited based on conditions of the license agreement, does the GPLv3 actually prevent the distribution of a derived work when its operation requires an independent, proprietary component that has no free software substitute? In particular, does the relation vis-a-via copyright law between the adapter/shim to the independent proprietary work matter if it's clear enough that the adapter/shim cannot operate without the proprietary work? Best, Clark [1] http://stackoverflow.com/questions/4351119/if-i-use-gnu-gpl-code-with-my-own-server-side-code-do-i-need-to-open-my-server/ [2] http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins [3] http://www.gnu.org/licenses/gpl-faq.html#MereAggregation [4] http://projects.opensource.org/pipermail/license-discuss/2011-December/91.html ___ 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 Thu, Dec 22, 2011, at 01:34 PM, Rick Moen wrote: You know, Clark: Speaking for myself, I have no interest in advising querents about how closely they can lawfully skirt the requirements of copyleft licences, or how they can creatively circumvent those requirements entirely, in order to use copylefted properties in proprietary works. You keep asking basically the same question, but are seeing scant interest in helping you. Might be that my view is common. Your characterization is wholly inaccurate, although I could see how you might arrive at this conclusion. My objective by asking this question is to determine if the GPL is an appropriate license for our consulting organization to release suite of tools and programs that are currently bundled with our services. I have some doubts since there seems to be a general consensus that you can easily use WebAPIs to evade the GPLv2. Our general application would be similar to Chris Travers' accounting application, and the case I'm concerned about would be very similar to what I posted in my follow-up. That is, could a competitor submit a set of hooks/menus as a derived work and effectively shield proprietary functionality via a WebAPI? I later found Chris Kleisath's blog post that implies that Sybase uses a similar technique. I'm asking, openly, what people's public opinion on this matter is. I'm not asking for advice about how I could incorporate GPL licensed material into a proprietary work. 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
Rick, My question is rather straight-forward. Does the GPLv3 permit the distribution of derived works that require an independent and non-free work for its operation [1]. I was under the impression that the Corresponding Source (all the source code needed to... run the object code) and 5c (the whole of the work, and all its parts, regardless of how they are packaged) would effectively prevent this sort of distribution. However, this seems not to be the case. If so, and this seems to be the consensus I'm hearing, then I think the GPLv3 is ineffective; more of a nuance than effectively protecting the free commons. Since, if I wish to distribute an extension of GPL'd work, all I have to do is factor out the critical parts of the my work and make them available as an independent and proprietary web service. On Fri, Dec 23, 2011, at 03:52 AM, Rick Moen wrote: I doubt very much that the recent queries here qualify as that variety of public service. You are being unnecessarily argumentative. 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. It's my position that if you wish to create a derived work that incorporates proprietary functionality, you should also provide an equivalent implementation under a compatible license. The style of linking and the question if the combined work is also derived from the proprietary work are largely irrelevant in my estimation. Yet, these two considerations keep emerging as if they are limitations of the GPL. Part of this problem is legal, but the other part is what the community accepts as being acceptable and that depends upon the public opinion of legal and technical professionals on this list. Best, Clark [1] For purposes of this question, you can consider the dependency to be declared as part of the derived work, but resolved at runtime via sockets or WebAPI; also assume that the derived work is *not* a modification or transformation of the independent, non-free work. ___ 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 Thu, Dec 22, 2011 at 2:00 PM, Lawrence Rosen lro...@rosenlaw.com wrote: Rick Moen wrote: You know, Clark: Speaking for myself, I have no interest in advising querents about how closely they can lawfully skirt the requirements of copyleft licences, or how they can creatively circumvent those requirements entirely, in order to use copylefted properties in proprietary works. You keep asking basically the same question, but are seeing scant interest in helping you. Might be that my view is common. Might be, but it is not unanimous. Indeed, I'm glad to advise companies how to circumvent the *purported* and *frequently misunderstood* requirements of the GPL. Good for you (I mean that). As I say in the LedgerSMB project we hold API's (however invoked) to be freely usable with the minor exception that inheritance probably crosses the line into derivative works land (because once inheritance is much more expressively intimate than mere linking). My opinion of the GPL licenses is that they do not prohibit the use of so-called creative circumventions to avoid having to disclose non-derivative works, despite the desire of some to call it morally evil. Linking GPL software to proprietary software is legal as long as one doesn't create a derivative work. If GPL advocates insist upon distinguishing among types of functional linking, then talented software engineers will avoid disputes by building shims, APIs, or use dynamic linking to accomplish their functional goals. More power to them! The only caution I would give here is what I clearly stated in my first reply. The GPL is not only a legal document but also to some extent a social contract as well. In general what is legal under the license and what is beneficial in skirting that edge may be separate, and taking on the wrath of the community is not so good however a court might rule. The social costs of violating accepted norms may be significant even if the action is technically legal. Similarly even if technically infringing (i.e. some interpretations of the BSD licenses are incompatible with some interpretations of the GPL v3), staying within accepted norms will never give you trouble. Thus in general I think one is generally better off talking with upstream projects and trying to get them on board. Best Wishes, Chris Travers ___ 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
Quoting Chris Travers (ch...@metatrontech.com): Good for you (I mean that). As I say in the LedgerSMB project we hold API's (however invoked) to be freely usable with the minor exception that inheritance probably crosses the line into derivative works land (because once inheritance is much more expressively intimate than mere linking). I just wanted to add that I am a great admirer of Larry Rosen's work in advising about the _purported_ and _frequently misunderstood_ requirements of GNU GPL (and others), and have been known to assist with that myself, in various small ways (and not even as consulting opportunities). For example, in bygone days the sales staff at MySQL AB are reputed to have spread some quite doubtful information about licensing requirements for software used with MySQL, and I've tried to do my part to debunk those claims. I doubt very much that the recent queries here qualify as that variety of public service. -- Rick MoenSo, this SEO copywriter walks into a bar, grill, r...@linuxmafia.com pub, public house, Irish bar, bartender, drinks, McQ! (4x80) beer, wine, liquor. -- Michael Karlsson ___ 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 Fri, Dec 23, 2011 at 03:38:04AM -0800, Chris Travers wrote: Thus in general I think one is generally better off talking with upstream projects and trying to get them on board. Take the most restrictive reasonable interpretation of both if you want to play it safe. After all, a change in the upstream project's maintainership could get you in a lot of trouble if you rely entirely on the legally non-binding word of a project maintainer. -- Chad Perrin ___ 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
Chad Perrin wrote: Take the most restrictive reasonable interpretation of both if you want to play it safe. That's true as far as it goes but leaves out the fun part of the analysis. The evaluation of risk -- particularly legal risk -- involves the analysis of many factors. Sometimes the most restrictive reasonable interpretation is way beyond what actual risks exists: Who will have standing to sue? What are potential damages? Is an injunction likely? Can I easily design-around or re-implement? What is the timeframe of the risk? And with regard to this irrational fear of the reach of the GPL regarding functional linking that is but one minor factor in a complex derivative work analysis, what is the risk that some court will force me to disclose my *copyright-independent* crown jewel proprietary stuff or give away my patents? /Larry -Original Message- From: license-discuss-boun...@opensource.org [mailto:license-discuss- boun...@opensource.org] On Behalf Of Chad Perrin Sent: Friday, December 23, 2011 9:49 AM To: license-discuss@opensource.org Subject: Re: [License-discuss] GPL and proprietary WebAPIs On Fri, Dec 23, 2011 at 03:38:04AM -0800, Chris Travers wrote: Thus in general I think one is generally better off talking with upstream projects and trying to get them on board. Take the most restrictive reasonable interpretation of both if you want to play it safe. After all, a change in the upstream project's maintainership could get you in a lot of trouble if you rely entirely on the legally non-binding word of a project maintainer. -- Chad Perrin ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ 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
Lawrence Rosen scripsit:
And with regard to this irrational fear of the reach of the GPL
regarding functional linking that is but one minor factor in a complex
derivative work analysis, what is the risk that some court will force
me to disclose my *copyright-independent* crown jewel proprietary
stuff or give away my patents?
That, at least, seems like FUD to me. An injunction against further
distribution of the part-GPL proprietary product, sure. Disgorgement of
ill-gotten gains, possibly. Damages for copyright violation, conceivably.
But that kind of specific performance? I can't see any common-law
jurisdiction ordering it.
IANAL, TIN{LA,UPL}.
--
My corporate data's a mess! John Cowan
It's all semi-structured, no less. http://www.ccil.org/~cowan
But I'll be carefreeco...@ccil.org
Using XSLT
On an XML DBMS.
___
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 Wed, Dec 21, 2011 at 10:26 AM, John Cowan co...@mercury.ccil.org wrote: Chris Travers scripsit: Now, if linking implies derivation, then isn't the software (and by extension *all* Windows software) derivative of Windows? If that's the case then doesn't every developer of Windows software need Microsoft's permission to distribute such software? I don't think so. I do think so, but in fact such permission is forthcoming. 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. In this case of NDISwrapper, the Windows drivers that it wraps are licensed to run on the hardware they are being used on, since almost every PC is licensed to run Windows whether it actually does so or not. But wait.. We didn't say licensed to run Windows. We are talking about Microsoft's legal right to prevent distributions of derivative works. The fact that hte hardware may have Windows licenses is irrelevant as to whether a derivative work of Windows can be distributed in the first place, or am I missing something? In fact, if we go that route, why couldn't Microsoft have just revoked Netscape's license to distribute Windows software and killed the competition that way? Best Wishes, Chris Travers ___ 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 Wed, Dec 21, 2011, at 03:01 AM, Chris Travers wrote: | Let's suppose that I've working on a Ledger++ program | which is a proprietary version of your Ledger SMB that | adds awesome multi-state Payroll and Asset Depreciation | features. Only rather than including these features | in your code-base, I include only stubs that package | up the data each feature needs, calls a proprietary | web service, and returns the data. | | Ok. So far so good. | | So, about 5% of my code is a bunch of hooks, while 95% of | my Ledger+ code remains proprietary. I release the stubs | under the GPL license... but effectively, the features | I've added are completely useless and non-operational | unless you've paid for my web service subscription. | | Well, technically you'd probably release under the LGPL or BSD | license, sort of like nVidia does with their stubs for their Linux | video drivers. Again this isn't a new thing. You see a surprising | amount of it in Linux (ndiswrapper, the nVidia drivers that RMS hates, | etc). I don't understand why it'd matter how the stubs are licensed, if the GPL doesn't have any ability to jump over a network. | My reading of the GPLv3 is that it uses copyright law | to determine when you've made a modification, but, the | condition to distribute your modification goes far beyond | this limitation, including the whole of the work, and all | its parts, regardless of how they are packaged. | | That's not my reading. My reading is that the license tries to get | away from the derivative works definition (maybe it's not strict | enough for Stallman?) through refining definitions. Of course the GPL | is not a EULA and it only requires acceptance when you distribute the | work or derivative works, but that only covers some cases. The GPLv3 defines a modified work as strictly matching any adaptation that requires copyright permission. So, I don't think there is a re-definition there. What the GPLv3 does do is set very broad terms (far beyond the 'modifications') in exchange for the right to publicly distribute these modifications: In Section 1, it requires the Corresponding Source to include *all* the source code needed to generate, install, and (for an executable work) run the object code and to modify the work -- excepting system libraries or general purpose tools or generally available free programs. So, for my example, I believe the Corresponding Source would absolutely include the Multi-State Payroll and Asset Depreciation code that I'm trying to hide behind a web service. Since without this code, I'm not able to run the logic in the hooks (screen buttons let's say). In Section 5, the GPLv3 clarifies this intent even more, by requiring that I license the whole of the work, and all its parts, regardless how they are packaged. In my example, I'm attempting to circumvent the GPL via packaging. However, it's pretty clear that the whole work includes the Payroll and Depreciation logic since my hooks are pretty useless without this complementary logic. Hence, while the *modifications* to your code are simply hooks, the conditions for distributing those modifications would go far beyond what copyright law might consider. Deservedly, the GPLv3 uses my hooks (the part covered by copyright law) to require the release of the exact same source code I am attempting to shield pretend aren't part of the derived work. | Let's try a thought experiment. Let's say LedgerSMB depended on | Windows and was essentially using Windows-only API's (and thus linking | with Windows base libraries). Now, I recognize that the GPL | specifically exempts linking to system libraries, but I see no reason | why system libraries are different from a copyright perspective (i.e. | this distinction exists solely because RMS wrote it into the license). | Now, if linking implies derivation, then isn't the software (and by | extension *all* Windows software) derivative of Windows? If that's | the case then doesn't every developer of Windows software need | Microsoft's permission to distribute such software? I don't think so. That's not how the GPLv3 works. The GPLv3 isn't claiming your work is a derivation of the base works, it is adding additional conditions in exchange for the right to distribute your modifications. There is a difference. Let's pretend that Win32 calls aren't System Libraries. In this case, let's say I'm making a derived work that ports your software to work on Windows. So, while I cannot do this directly, I can do it indirectly by ensuring that Wine supports the Win32 calls I use and getting my program to work under Wine. In this case, I will have met the conditions in sections 1 and 5 of the GPL using the code found in Wine. There is nothing saying that my derived work (that is generated on Linux under Wine) couldn't be distributed and executed on the Windows platform. | Would you have a problem with the scenario above, perhaps | assuming I'm
Re: [License-discuss] GPL and proprietary WebAPIs
I found a tangible example of what I'm referring to, complete with wonderful visuals. Chris Kleisath at Sybase describes how they circumvent the GPL license by using intermediate APIs to link proprietary functionality with GPL licensed works. Is Chris correct? For GPLv2? For GPLv3? http://iablog.sybase.com/kleisath/index.php/2009/02/how-to-interface-proprietary-code-with-gpl-code/ ___ 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
Chris Travers scripsit: In fact, if we go that route, why couldn't Microsoft have just revoked Netscape's license to distribute Windows software and killed the competition that way? IANAL, but that strikes me as something that would set them up for a lawsuit by Netscape, being unambiguous evidence of discrimination. It's not against the law to be a monopolist, and it's not against the law to treat your customers in a non-uniform way: it's the combination that is poison. -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the co...@ccil.org Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. ___ 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
Quoting Clark C. Evans (c...@clarkevans.com): I found a tangible example of what I'm referring to, complete with wonderful visuals. Chris Kleisath at Sybase describes how they circumvent the GPL license by using intermediate APIs to link proprietary functionality with GPL licensed works. Is Chris correct? For GPLv2? For GPLv3? http://iablog.sybase.com/kleisath/index.php/2009/02/how-to-interface-proprietary-code-with-gpl-code/ You know, Clark: Speaking for myself, I have no interest in advising querents about how closely they can lawfully skirt the requirements of copyleft licences, or how they can creatively circumvent those requirements entirely, in order to use copylefted properties in proprietary works. You keep asking basically the same question, but are seeing scant interest in helping you. Might be that my view is common. ___ 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 wrote: You know, Clark: Speaking for myself, I have no interest in advising querents about how closely they can lawfully skirt the requirements of copyleft licences, or how they can creatively circumvent those requirements entirely, in order to use copylefted properties in proprietary works. You keep asking basically the same question, but are seeing scant interest in helping you. Might be that my view is common. Might be, but it is not unanimous. Indeed, I'm glad to advise companies how to circumvent the *purported* and *frequently misunderstood* requirements of the GPL. My opinion of the GPL licenses is that they do not prohibit the use of so-called creative circumventions to avoid having to disclose non-derivative works, despite the desire of some to call it morally evil. Linking GPL software to proprietary software is legal as long as one doesn't create a derivative work. If GPL advocates insist upon distinguishing among types of functional linking, then talented software engineers will avoid disputes by building shims, APIs, or use dynamic linking to accomplish their functional goals. More power to them! /Larry Lawrence Rosen Rosenlaw Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 Cell: 707-478-8932 Apache Software Foundation, board member (www.apache.org) Open Web Foundation, board member (www.openwebfoundation.org) Stanford University, Instructor in Law Author, Open Source Licensing: Software Freedom and Intellectual Property Law (Prentice Hall 2004) -Original Message- From: license-discuss-boun...@opensource.org [mailto:license-discuss- boun...@opensource.org] On Behalf Of Rick Moen Sent: Thursday, December 22, 2011 1:35 PM To: license-discuss@opensource.org Subject: Re: [License-discuss] GPL and proprietary WebAPIs Quoting Clark C. Evans (c...@clarkevans.com): I found a tangible example of what I'm referring to, complete with wonderful visuals. Chris Kleisath at Sybase describes how they circumvent the GPL license by using intermediate APIs to link proprietary functionality with GPL licensed works. Is Chris correct? For GPLv2? For GPLv3? http://iablog.sybase.com/kleisath/index.php/2009/02/how-to-interface- proprietary-code-with-gpl-code/ You know, Clark: Speaking for myself, I have no interest in advising querents about how closely they can lawfully skirt the requirements of copyleft licences, or how they can creatively circumvent those requirements entirely, in order to use copylefted properties in proprietary works. You keep asking basically the same question, but are seeing scant interest in helping you. Might be that my view is common. ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss ___ 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
Quoting Lawrence Rosen (lro...@rosenlaw.com): Might be, but it is not unanimous. Indeed, I'm glad to advise companies how to circumvent the *purported* and *frequently misunderstood* requirements of the GPL. Two-hour minimum at professional rates, I hope. I'm certainly not calling anything whatsoever 'evil'. I just have no unpaid time available to assist some categories of querents. Indeed, what some label 'evil', I might see as a valuable and billable consulting opportunity (being careful of UPL statutes). -- Cheers,I'd say it's latke-esque. Sort of like Rick Moen Kafka-esque, only less depressing. r...@linuxmafia.com -- Deirdre Saoirse Moen McQ! (4x80) ___ 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 20, 2011 at 6:35 PM, Clark C. Evans c...@clarkevans.com wrote: On Tue, Dec 20, 2011, at 03:30 PM, Chris Travers wrote: In general, good will from the projects at issue is a factor that should not be underestimated and being a good citizen means ideally making sure they are ok with it. Absolutely. If people consider you to be behaving fairly, they are more likely to support your cause. Also bad feelings can come back to hurt you later, legal actions or not. I can tell you how the LedgerSMB core team approaches this. We draw a hard line between using our code (requires adhering to the GPL) and using our API (does not). In practice this means if you use our code as a basis for your code whether through object inheritance, literal copying, or paraphrasing, we expect you to adhere to the GPL v2. Let's suppose that I've working on a Ledger++ program which is a proprietary version of your Ledger SMB that adds awesome multi-state Payroll and Asset Depreciation features. Only rather than including these features in your code-base, I include only stubs that package up the data each feature needs, calls a proprietary web service, and returns the data. Ok. So far so good. So, about 5% of my code is a bunch of hooks, while 95% of my Ledger+ code remains proprietary. I release the stubs under the GPL license... but effectively, the features I've added are completely useless and non-operational unless you've paid for my web service subscription. Well, technically you'd probably release under the LGPL or BSD license, sort of like nVidia does with their stubs for their Linux video drivers. Again this isn't a new thing. You see a surprising amount of it in Linux (ndiswrapper, the nVidia drivers that RMS hates, etc). This is intended on our part to keep the based on language in the GPL v2 to be close to the derivative works definition in copyright law and recognizing that nobody needs copyright licenses from Microsoft to write, say, Internet Explorer plugins. My reading of the GPLv3 is that it uses copyright law to determine when you've made a modification, but, the condition to distribute your modification goes far beyond this limitation, including the whole of the work, and all its parts, regardless of how they are packaged. That's not my reading. My reading is that the license tries to get away from the derivative works definition (maybe it's not strict enough for Stallman?) through refining definitions. Of course the GPL is not a EULA and it only requires acceptance when you distribute the work or derivative works, but that only covers some cases. Let's try a thought experiment. Let's say LedgerSMB depended on Windows and was essentially using Windows-only API's (and thus linking with Windows base libraries). Now, I recognize that the GPL specifically exempts linking to system libraries, but I see no reason why system libraries are different from a copyright perspective (i.e. this distinction exists solely because RMS wrote it into the license). Now, if linking implies derivation, then isn't the software (and by extension *all* Windows software) derivative of Windows? If that's the case then doesn't every developer of Windows software need Microsoft's permission to distribute such software? I don't think so. So if it isn't a derivative work and you aren't distributing LedgerSMB, I am hard pressed to see how legal action could be successful in court, but IANAL. OTOH, it could be very successful both in terms of expenses involved and bad press to get you to do what I want. Really, this is what the FSF did to Apple over the Objective C add-ons to the GCC. Sooner or later though someone will fight through and win and this will lose its effectiveness. In this view, there is no problem. There wouldn't even be a problem, in this view, if the libraries were linked provided that the code connections are not so intimate as to create a derivative work (for example, I would argue that class inheritance in fact does this). Would you have a problem with the scenario above, perhaps assuming I'm implementing a business feature that you consider to be core to the mission of Ledger SMB and you would have hoped would be contributed back to the project? Would I personally have a problem with that? Not as such, though I might think you were doing something unwise. You are obviously building a market for us and helping define how payroll should work and how we should enhance our asset depreciation features. However, as we develop these, you are faced with a problem in that refusal to contribute back would increase your own maintenance efforts for diminishing returns. You can't just take our code and close it all off because of the GPL, and then fork and go on your way as a proprietary product, so you are kinda trapped. So in other words this technique doesn't work around copyleft so much as it limits the applicability of copyleft to code as code.
Re: [License-discuss] GPL and proprietary WebAPIs
Chris Travers scripsit: Now, if linking implies derivation, then isn't the software (and by extension *all* Windows software) derivative of Windows? If that's the case then doesn't every developer of Windows software need Microsoft's permission to distribute such software? I don't think so. I do think so, but in fact such permission is forthcoming. 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. In this case of NDISwrapper, the Windows drivers that it wraps are licensed to run on the hardware they are being used on, since almost every PC is licensed to run Windows whether it actually does so or not. IANAL, TINLA. -- John Cowanhttp://www.ccil.org/~cowan co...@ccil.org if if = then then then = else else else = if; ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
[License-discuss] GPL and proprietary WebAPIs
I have a broad question about various interpretations of the GPL with regard to WebAPIs. Let me start with an example scenario. 1. Suppose that Super Visual is a clever GPL licensed data visualization program (released by Vendor A). 2. Now suppose that there is a closed-source, but free to redistribute, data processing library, called Correlate (by Vendor B), which takes a data set and a parameters and does a clever and very proprietary data transformation. 3. Now suppose that I modify Super Visual to incorporate the functionality of Correlate. It works wonderfully and I wish to share my Visual Correlate with my friend. Is this permitted by the GPL? a. Suppose my modifications involve static libraries, the resulting Visual Correlate is a single compiled executable. b. Suppose Super Visual has a plugin mechanism, and I use this internal API to load Correlate as a dynamic link library. Let's assume I also ensure that the program still works but lacks the correlate functionality if the dynamic library isn't there. I don't ship correlate.dll, but tell my friend about the easter egg. c. Suppose that Super Visual doesn't have a plugin system, but I release a GPL licensed Super Visual /w Plugins that does. Now can I release Visual Correlate using this plugin mechanism? d. Suppose that I make a SuperVisual+ (GPL licensed) with generic, if complex way, to invoke separate executables for external processing using standard input, output, and command line arguments. Suppose also I get permission from vendor B to create and freely distribute a closed source Correlate command line executable that takes the specially formatted inputs to return outputs that the SuperVisual+ needs. I'm all clear now? e. Suppose that I instead wrap Correlate in a WebAPI (let's say I get permission of Vendor B to do this). Then, my modification to SuperVisual creates a runtime dependency on the web service; it degrades nicely without Correlate functionality if you lack a network connection or haven't paid to access my web service. Can I release this Visual Correlate under the GPL? f. Suppose that SuperVisual is a web application, and I wrap it with a web service running on a different server (without modifying one line of code), parsing the output stream to add additional functionality provided by Correlate. The final result is that my users experience a single integrated application that mixes both Correlate and Super Visual functionality. My interpretation of the GPL is that in every case, I'd be producing a modified version. Even in the latter case, my wrapper would be using very specific (and hence intimate) information about how the application works and therefore would qualify as a new program based on the earlier work. Hence, since my Visual Correlate must comply with the GPL; and since I don't have the right to also release Correlate under the GPL, I can't share my work (as cool as it may be) with my friend -- even if he already has a copy of the Correlate program. I say this for a few reasons. First, in section #1 of the GPL, Corresponding Source it says that the corresponding source must include all source code needed to run the object code. Hence, I must also include Correlate under the GPL. Secondly, under section #5c, it requires that I license the whole of the work, and all its parts, regardless how they are packaged. Hence, my attempts to work around the intent of the license are foiled... packaging the Correlate function as a WebAPI doesn't make it any less of the whole work. Is this a correct assessment? If not, where has my logic gone astray? I've talked to a few attorneys lately about this situation, and I've gotten wildly different answers. While the specific example is completely hypothetical, the general situation isn't. I'd remark that it's widely held that wrapping up proprietary functionality in a Web API is a valid way to evade the GPL's copyleft. http://stackoverflow.com/questions/4351119/if-i-use-gnu-gpl-code-with-my-own-server-side-code-do-i-need-to-open-my-server/ Best, Clark ___ License-discuss mailing list License-discuss@opensource.org http://projects.opensource.org/cgi-bin/mailman/listinfo/license-discuss
