@progval thanks a lot. I dropped the ball on the conflict resolving. You are a star!

I just added the reverse property isSourceCodeOf.

The name follows the schema.org conventions for reverse properties (eg. hasPart/isPartOf, hasVariant/isVariantOf)

We may be asked about the difference between isSourceCodeOf and targetProduct. Both link a ScoftwareSourceCode with the Software it aims to represent no? I support hasSourceCode (hence this issue). But I can't think of a great difference between isSourceCodeOf and targetProduct.

The current definition is Link that states where software application is built from a given source code. Note that not all software is built from code, as interpreted code like Python does not need to be built.

targetProduct is defined as Target Operating System / Product to which the code applies. If applies to several versions, just the product name can be used. The definitions are quite similar, no?

Should targetProduct be the inverse of hasSourceCode instead?

I feel targetProduct is closer to runtimePlatform. In software engineering, one would say their app targets Windows, Flash, or the Web, to mean what product they aim to support, in the same way one targets an audience or democraphic. The schema.org definition implies it by giving Operating System as an example.

I've never seen someone says their source code targets the very app produced from their code. Though I admit it's common for binaries to be referred to as targets of the code in the context of a build system.

Either way, if we do come to the conclusion that targetProduct is the reverse of hasSourceCode, then hasSourceCode should be renamed targetProductOf for consistency.

Hmmm, I saw targetProduct as the compiled binaries created by the source code (e.g., the JAR in Java), which would then be considered SoftwareApplications. Otherwise I am not sure what the difference with runningPlatform is.

I would keep hasSourceCode as it feels more natural than targetProductOf, to be honest (targetProduct is already a little bit confusing and per the documentation it may also be interpreted as the OS supporting the release).

If we want to keep isSourceCodeOf, then I feel like we need to justify why is it different to targetProductOf. Any takers to introduce a difference? Something like "this is not just for the binary, but to the abstract concept of software"?

A very interesting discussion.

targetProduct = Target Operating System / Product to which the code applies. If applies to several versions, just the product name can be used.
runtimePlatforme = Runtime platform or script interpreter dependencies (Example - Java v1, Python2.3, .Net Framework 3.0). Supersedes runtime.

If we take a simple example of the CodeMeta generator, you have the hosted instance: https://codemeta.github.io/codemeta-generator/

What would that be a targetProduct or isSourceCodeOf?
Another possibility is to use targetProduct= Python's HTTP server
And the runtimePatforme= Python3 (or be more specific)

If this example doesn't work, we can try finding other examples were this can apply.
The idea here is to provide expressiveness following the issue #198

At this stage we really want to release a V3.0 (after three years of intention).
Let's add both properties as suggested here and start a discussion for better examples in the discussion tab.
This might yield a larger discussion on relationships between objects, which is not clear how to express in CodeMeta.

Sounds fair. targetProduct is very unclear (as evidence by all the discussions around it), so if nothing else, isSourceCodeOf fixes the ambiguity.