Maybe it would help if I gave a simple example from go. A situation that AFAIK does not currently exist but could exist.

Pachi is open source. You can download the source and complie it (they don't provide run execs). But Pachi is just a go playing engine. You can't run it to play a game of go. You need a shell application for playing go that would call Pachi to make the moves.

OK, somebody could write such a shell, lets call that Goex. Goex could be a "commercial" product, could be sold, would not have to be open. However, because it is using an open source component it would have to provide the source code for that open component. Not the rest of Goex, just the Pachi part. If to make this work, a modified version of Pachi was needed (something attached to Pachi) those modifications would/should be open and source code provided.

Perhaps many of you think that for a program to run all of its parts must be closely connected (compiled together, at least link edited together). That is not the case. But let's not go into the how of dynamic calls, pseudo static calls (dynamic only the first time), etc.

Thanks, Mike! As a programmer, I was struggling to come up with a way to describe exactly what you just did. That examples agrees with my understanding of the GPL.

GPL/open source is not relevant to this Rybka case, though, right? My understanding of why Rybka was stripped of its titles was because it allegedly violated one of the rules of the competition, namely that the "game playing" code had to be "original".

That's a common misconception about how the GPL works. Technical implementation has nothing to do with the legal requirements of the GPL.

If you make a derivative work, you have to distribute it (and all of it) under GPL (or not distribute it at all). It's as simple as that.

It gets complicated when you ask "what's a derivative work?". What you describe is clearly a derivative work. It doesn't matter at all how you link the programs together, statically or dynamically linking a library, communicating via IPC or simply starting the program and communicating over stdin/stdout doesn't make a difference legally. Goex needs a custom version of Pachi, therefore Goex is a derivative work of Pachi, so it has to be put under GPL.

Consider another example: Let's say Goex doesn't need a custom version of Pachi. Let's say it doesn't need Pachi at all, just some GTP-speaking program. It just happens that Pachi speaks GTP. In that case, Goex would probably not be a derivative work, although that hasn't been tested in court.

A third example: Now let's assume Pachi does not speak GTP. Completely unrelated with Goex, you can of course release a GPL-licensed fork of Pachi that does speak GTP. This fork will run with Goex (among other GUIs). But, if you implement some extension to GTP that's specific to Goex, and Goex needs these extensions (i.e. doesn't work with other, unmodified, GTP-speaking engines), then you're on thin ice.

<disclaimer>I'm not a lawyer, just a software developer with some experience in dealing with OSS licenses.</disclaimer>

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

As RBerenguel's link indicates, it's pretty common to think that it definitely does matter how the program is linked, whether it uses IPC, etc, etc. That may be wrong, but you're not really addressing what seems to be the prevailing opinion--you're just dismissing it out of hand.

_________________
Occupy Babel!

Ok, perhaps my formulation was a bit misleading. I'm not saying the method of the communication is completely irrelevant. A statically linked program is definitely a derivative work, but linking via an IPC mechanism may still be a derivative work. Communication mechanism is one criterion, but not the only one.

I'm just trying to point out that merely the act of choosing a sufficiently loose linking method does not put you on the safe side.


From http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation:

The question is what is considered "intimate enough". If you invent a completely new communication protocol and modify the program to support it, that certainly qualifies as "exchanging complex internal data structures". If you use a standardized protocol (like in the GTP example), I'm pretty sure you're on the safe side, especially if the program already supports the protocol. Anything in between... who knows?


Quote from the GPLv2 (also quoted on the wikipedia article, emphasis mine):

So if you need to modify a program to work with your product, the situation is simpler: The whole is covered by GPL. That directly contradicts the example of Mike.

The relevant point here seems to be the distribution as a whole. If you distribute it separately, you're back to the question of whether the communication is intimate enough. Of course there is also the question what counts as "separate distribution". If you just produce two separate software packages, but any user must download both to get anything meaningful, then it probably depends on the judge whether that is considered separate distribution or merely an evasive action.

That's helpful, flOvermind.

_________________
Occupy Babel!

After reading through and correcting my misconceptions ... I find I have no use for GPL'd code, and I now have a better understanding of why it has the reputation it has among commercial outfits.

All this licensing stuff is a part of why I no longer code for a living, and have lost much of my interest even in personal projects.

But, all this is tangential to the original discussion. Sorry for the derailment.

Might I suggest you reread what I wrote (about what would or would not have to be made open)


Regardless of whether the open program (or part of a program like a function) used just these legal methods of communication a shell could be written that did. That shell would call (or in the case of a function be linked) and it (the shell) would have to be made open. I said that. Why are you expanding that to "whatever calls that shell has to be open"?

When you call (for execution) a program from the command line supplying a number of run time parameters "something happens" (the system does a number of things before turning control over to the invoked program). If you know what those things are you can write code that does excatly the same thing. The program eventually called "doesn't know" whether it was invoked from the command line or another program.

Technically, yes they stripped Rybka of the titles based on the now infamous rule #2. The game-playing code must be original. In Rybka, they determined that it wasn't, and that Rybka had some Fruit parts. Even before Rybka played in the world championship though (pre-Rybka 1.0 beta) they found that code from Crafty (another chess engine) was in Rybka. As far as I know, the FSF is looking into the legalities of Rybka, though.



Considering this discussion is entirely civil, this derailment is acceptable since it's all in someway related to the issue. In the computer chess world, i.e. Talkchess, Open-chess, Rybka Forum, and the others this discussion would be over 200 posts, 99% of which would just be hurling insults.

_________________
My plan to become an SDK is here.

Let's call those a, b, and c

a --- No, the custom version of pachi (the alterations you add to pachi so that goex could use it) must be open sourced. Not goex.

b --- Would definitely not be. Come on now, you are implying that there is even the slightest question about whether the existence of an open source program X means any other program Y would have to be open sources whetehr Y ever interacted with X in any way.

c --- If it was GTP that was modified those extensions must be open sourced. That my motivation for making those specific extensions was so that some non-open source program I planned to write would work easier would not "capture" my non-open program.

Look, you say you are a software developer. Can you not see that your arguement is akin to claiming that if a non-open source program is ever run under an open source operating system this would represent a violation? After all, when that program runs it will be making calls on the operating system for services, calling open source utilites, etc.

I was using the specific example of pachi not only because this is a go forum but also because pachi is just an "engine", not intended or able to run all by itself. It is intended to be called by some go playing program or other as the vehicle that will call pachi (or some other go engine) for its engine. That the site suggests a particular one is besides the point. Yes of course, the distribution of a non-open goex that was going to use pachi in this way would have to include the source code of pachi to be in compliance.

Wrong:

If you need to modify the program in order to make it compatible, then you're exchanging internal data structures. If you don't need to modify it, the data structures you're exchanging are not internal.

Ok, there is also the case where you just modify the program to make it more convenient to use, like implementing an IPC mechanism instead of stdin/out, but without changing the actually transmitted information. That would probably be ok.


I never said that needs to be GPLed, just that it hasn't been tested in court. I certainly hope it doesn't need to be


GTP is a just specification, so the modification to GTP is mostly irrelevant to the license of the programs using it.

What is relevant is whether the communication between the programs is "intimate enough". That's a good question, and I can't really answer it. Anyway, the relevant point is whether your commercial program is considered a derivative work of the GPL program. Static linking is a strong indication that it is. Needing to modify the GPL program so it works with your product is also an indication that it is. If your product also works without the GPL program, or with alternative programs, that's an indication that it isn't a derivative work.

Just linking it via pipes doesn't tell you anything. That's just a technicality. It's necessary for not being a derivative work, but not sufficient.


The glibc and many other standard system libraries are licensed LGPL exactly for that reason. Some libraries also have special licensing exceptions to allow using them in non-free tools.
Also, if you're programming only against a specification (e.g. the C language standard, the POSIX standard, the X11 protocol, ...), then you're clear. You don't need glibc specifically, just some library that implements the C standard.

Whether calling open source utilities is allowed is a good question. Of course, standard shell utilities are covered by various standards (POSIX, ...), so you don't specifically need the GNU utilities, just some utility that fulfills the specification. If you need a specific GPL utility, that's hairy...


Yes, and pachi uses the standard protocol GTP. So if your GUI is using that, you're fine.

The relevant point in your example is the *required* modification of pachi to make it compatible with your GUI. With that, you make your GUI a derivative work legally speaking. If the modification was not required, but only some sort of "improvement", and your GUI would also work with the original version, then you're ok.


All that is perhaps a bit easier to understand if you consider the intention of the GPL:
You get this program completely free, but if you build something on top of it, you have to give your users the same rights.
That could be considered the "cost" of the software. It doesn't cost money, but it costs a "promise" to give your users the same rights.

If the developer of the program wanted it to be usable in a commercial product, it would be licensed LGPL (you may use it commercially, but if you modify it, you have to give back the modifications) or even BSD (you may use it for whatever you want, i.e., free as in beer).

About "intentions" (of the free software movement)

In 2006 we had a house fire. Only the "office" (computer room) room actually burned but the entire second floor had to be gutted for smoke damage. In this fire I lost many things including my record of the free software debates going back to the beginning. I was a subscriber to the journals where the relevant papers/debates were published.

I simply disagree with your interpretation.

However, I agree who knows what courts might do. Lawyers are not the best people when it comes to software and data. ROFLOL once I spent a very hectic week trying to make sense of data obtained from a hostile source under court order. The lawyers knew some of the things that the order had to specify, but every speecification they left out those forced to supply the data took advantage of to make the task harder (if we couldn't extract the data by a certain date we would have had to renew a contract with that hostile source as we wouldn;t be able to turn this business over to somebody else to handle and were legally obligated that these customers be serviced properly).