Life In 19x19

Suji wrote:

Mike Novack wrote:It is not an infringement for a commercial product to use something that comes from open source provided a number of conditions are met.

I agree with the preceding statement, however, Fruit had the GPL license applied to it. The issue then becomes, did Rybka copy code? If so, then as per the GPL, Rybka would then have to be open source regardless of being commercial or not.

No, that's a misconception --- Simply the use of some open source routine by an application does not make all of that application open source (the rest of it). Try reading the GPL more closely to see what the developer of Rybka would be obligated to do. I'll repeat, this is not a suitable forum for discussing the technicalities of either the license or how to code so as not to violate it, etc. except to point out that once can code so as not to "enclose" a routine.

Indeed, the GPL does not force something to be open sourced, but forces the distribution of the source code:

The fourth section for version 2 of the license and the seventh section of version 3 require that programs distributed as pre-compiled binaries are accompanied by a copy of the source code, a written offer to distribute the source code via the same mechanism as the pre-compiled binary, or the written offer to obtain the source code that you got when you received the pre-compiled binary under the GPL.

RBerenguel: perhaps I'm slow today, but what distinction are you trying to make?

I was just sourcing the comment by Mike: the GPL does not require software to be open sourced, just to make the sources available. Open source is a broad term, which usually means that you can mess as much as you want with the code and derivatives. The GPL does not force you to do this, just to provide the source of your program. With your own licenses, except for the part covered by the GPL (since any derivative work of a GPL work is also GPL, but something USING code from GPL does not need to be).

Mike Novack wrote:

Suji wrote:

Mike Novack wrote:It is not an infringement for a commercial product to use something that comes from open source provided a number of conditions are met.

I agree with the preceding statement, however, Fruit had the GPL license applied to it. The issue then becomes, did Rybka copy code? If so, then as per the GPL, Rybka would then have to be open source regardless of being commercial or not.

No, that's a misconception --- Simply the use of some open source routine by an application does not make all of that application open source (the rest of it). Try reading the GPL more closely to see what the developer of Rybka would be obligated to do. I'll repeat, this is not a suitable forum for discussing the technicalities of either the license or how to code so as not to violate it, etc. except to point out that once can code so as not to "enclose" a routine.

RBerenguel wrote:Indeed, the GPL does not force something to be open sourced, but forces the distribution of the source code:

The fourth section for version 2 of the license and the seventh section of version 3 require that programs distributed as pre-compiled binaries are accompanied by a copy of the source code, a written offer to distribute the source code via the same mechanism as the pre-compiled binary, or the written offer to obtain the source code that you got when you received the pre-compiled binary under the GPL.

Okay, so *I* am wrong. Clearly, I'm not an expert in this issue at all (In all reality, I'm going to be wrong more than I'm going to be right, thus non-expert).

So, as I understand it, if I take Fruit which was open source with the GPL. Let's say that I manipulate the Fruit sources and improve the engine to #1 in the world right now. I'd be required to give back to the community in some fashion due to the GPL, correct? In what fashion, how I improved the program? If I built a GUI for Fruit to run in while still improving it to number one, could I get away with not releasing the source code to the GUI if it's completely separate from the source of Fruit while releasing the source code to Fruit?

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".

Mike Novack wrote: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.

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>

flOvermind wrote: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.

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.

hyperpape wrote: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.

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:

Mere aggregation of two programs means putting them side by side on the same CD-ROM or hard disk. We use this term in the case where they are separate programs, not parts of a single program. In this case, if one of the programs is covered by the GPL, it has no effect on the other program.

Combining two modules means connecting them together so that they form a single larger program. If either part is covered by the GPL, the whole combination must also be released under the GPL—if you can't, or won't, do that, you may not combine them.

What constitutes combining two parts into one program? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. 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.

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):

You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

...

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

...

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

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.

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.

flOvermind wrote:
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs.

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.