I propose that...
- the source code is a specification (inheritance)
- the source code consists of designs (aggregation)
- the source code has implementations (association)
A specification specifies what a system should do; so does the source code (which may not be what the customer wanted, but that's besides the point). But there are specifications which are not source code, as they don't have designs (i.e. specify the system as a whole without dividing it into parts), so the two are not identical.
The source code can be looked at under different aspects, that is, in different scopes and at different levels. For each of these aspects, the source code represents one possible design. The source code is the sum of these designs.
For different compilers or the same compiler on different platforms, the source code produces different implementations. The same implementation could be arrived at by different source codes.
Thus, when we write code, we are...
- writing a specification (and hope that it matches the customers' true requirements)
- working on several designs at once: low level, high level, static, dynamic, class, database, algorithm, ...
- aiming at a set of implementations
Now, let the games begin... :-) --FalkBruegmann
...or, more precisely: creating SourceCode is part of the design process.
...or, more precisely: the SourceCode is the (most detailed) specification of the ObjectCode.
Let me be the first to admit that the "inheritance, aggregation, association" thing is a little bit forced. I thought it might be interesting nonetheless, especially the implication ("Thus..."). --FalkBruegmann
source code if it's generated by some automated process from some other document/file.
ASCII text files containing "C code" are source, if edited by programmers.
But if the files are generated by lex or yacc, then the lex or yacc input file is the real "source document."
The ".c" file is just an intermediate file, used as a step in the compilation process.
If a file is generated by a tool, but subsequently edited and maintained directly, then it becomes a "source file."
(And, in spite of being a very common practice, it's also generally a bad idea.)
A lesson learned from writing readable functional tests: Any sufficiently executable document is indistinguishable from source code.
Has the above been tested in a court? It is very relevant regarding GPL software.
Why would the above definition ever be tested in court ? The only relevant definition of "source code", as applied to GnuGeneralPublicLicense
software, is the legal definition embedded inside the GnuGeneralPublicLicense
I would be surprised if the legal definition of any word were the same as the JargonFile
Can I release software based on GPL with obfuscated source code?
No. (To be pedantic, yes, you can release whatever software you want, but if it's based on GPL, and the people you release it to ask for the source code, you must give non-obfuscated source code or be in violation of the license).
The GPL defines source code as follows: "The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable." This would preclude distribution of obfuscated code. The GPL also requires that distributed source code be machine-readable, presumably to prevent people from offering source code only in hardcopy form or in some other hard-to-use format (stone tablets, for example).
Consistent with that definition, however, would be the view that manually obfuscated SourceCode is the SourceCode, whereas perhaps automatically obfuscated SourceCode would not be! A legal minefield if you ask me...
I see no difference between manual obfuscation and automatic obfuscation in the GPL definition (or the definition on this page). However, IANAL.
One could declare their source code to be open source sculpture and therefore stone tablets are the preferred form for making modifications to it.
The SourceCode is
that from which the ObjectCode
produced. (If no ObjectCode
has been produced, the "SourceCode
" is merely proto-SourceCode
!) If a file is generated by a tool but is subsequently edited and maintained directly, and ObjectCode
is produced from this "source file", the "source file" thereby becomes the SourceCode
. So long as the "source file" has the appropriate edits applied manually each time it is re-generated by the tool, it retains its status as the SourceCode
. However, if the necessary edits are performed automatically (by a script, for example) then the script becomes part of
, along with whatever the tool operates on to produce the "source file". The "source file" is then no longer the SourceCode
, either before or after the automated edit.
Source code, when created by a programmer, is the procedure manual for the computer (compiler?)
. It lays out the steps required to achieve a task.
Different computer languages require different source code. The source code a programmer writes presents the application system in encapsulations which are appropriate to the language used. See EncapsulationDefinition
. -- PeterLynch
is what infects pure data and makes it dependent on other things.