Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Albert van der Horst]

Walter Landry schreef op 2017-07-03 20:59:

Albert van der Horst  wrote:

For those not versant with assembler. The binary that is generated is
supposed to be byte for byte the same with both assemblers. If not it
is a bug. The sources are equivalent, the binaries are the same, it
really is the same program.

Note, that I could not have told that I use an internal representation
and nobody could have guessed (nor benefited.)

So is the .s accepted as source conform Debian policies?


Unpopular or obscure source formats can still be the preferred source.
Presumably you use this internal representation for a good reason.  If
it helps you, it can help others.


As you may see in a separate post i've made an essentially larger upload
of lina, mainly to preempt legalistic reasons that would prevent 
acceptance.


It contains the "obscure source format".

The basic idea is that in the main directory building is from the
assembler file, but it is a target build from an extract directory.
So there is still a clear separation between meta building and
final building where the final build is very simple.

More about the basic idea in
https://github.com/albertvanderhorst/ciforth/wiki/Philosophy-behind-ciforth

Note that the extract directory (even containing a small fraction of the
files in the generic system) can generate 2 source files in 4 assembler
formats. 6 of those 8 I've tested. Tinkering with configuration files
multiplies the number of possible generated files by 512.
Most of those assembler source program's won't work.

I invite mentors interested in the "preferred source" matter to check
whether they can agree that the package now complies with debian guide 
lines.





Cheers,
Walter Landry


--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Albert van der Horst]

Paul Wise schreef op 2017-07-04 04:10:

On Mon, Jul 3, 2017 at 7:34 PM, Albert van der Horst wrote:


This is of course in the spirit of open source, and it is the
"preferred source of modification" for the *target* audience.


"Preferred" in "preferred form of the work for making modifications to
it" does not refer to downstream consumers of the code, but the form
that upstream prefers when making modifications.


Okay. That settles it. I always use the .s file to make modifications.
Then at great expense of effort I retrofit the modifications in a kind
of database. [With the benefit of possible having snippets of it 
available

for Windows versions which is outside of Debians skope.]

I give that same freedom to the users of lina by publishing the .s file.


In this case you have made it clear that the master file is the
"source code", not the generated assembly. IIRC you mentioned this
during earlier discussions too and I see on github that your Makefile
builds the .s files from the internal representation.


If you go too far with that reasoning, the only acceptable source are
git blobs. Let us keep the freedom of making modified versions in mind,
as a practical goal too, not only legalistic. 1]
I know that as far as almost all Debian packages is concerned this 
freedom

has strayed far.
Who modifies gcc to suit his needs? (I did, in 1999, but I wonder
whether I could now.)


For lina the freedom of modification is not moot. It is totally 
practical
to modify lina for the kind of people who want to use lina. It has been 
done too,

for example Jonesforth.




Some posts that you might like to read on this topic:

https://lwn.net/Articles/431566/
http://www.inventati.org/frx/essays/softfrdm/whatissource.html
https://b.mtjm.eu/source-code-data-fonts-free-distros.html
https://wiki.freedesktop.org/www/Games/Upstream/#source
http://compliance.guide/pristine


I could've written those myself. I'm totally committed to freedom
of source.

Anyway, I'll proceed in this direction and see what a prospective 
sponsor

thinks. If there is no sponsor, the whole matter goes away anyway.

I've made progress with generating a dsc file.

Groetjes Albert

1] I appreciate that Debian has to make rules to implement this.
There is always this tension between the law and justice.

--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst

Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Paul Wise]

On Mon, Jul 3, 2017 at 7:34 PM, Albert van der Horst wrote:

> This is of course in the spirit of open source, and it is the
> "preferred source of modification" for the *target* audience.

"Preferred" in "preferred form of the work for making modifications to
it" does not refer to downstream consumers of the code, but the form
that upstream prefers when making modifications.

> If I publish the program as open source in the context of Debian, I give out
> the .s file because I honestly believe that the "preferred source of
> modication" for a Debianist is the native gnu assembler format. I myself
> change the master file in order to be able to deliver a service to those who
> prefer nasm.
>
> Note, that I could not have told that I use an internal representation and
> nobody could have guessed (nor benefited.)
>
> So is the .s accepted as source conform Debian policies?

In this case you have made it clear that the master file is the
"source code", not the generated assembly. IIRC you mentioned this
during earlier discussions too and I see on github that your Makefile
builds the .s files from the internal representation.

Some posts that you might like to read on this topic:

https://lwn.net/Articles/431566/
http://www.inventati.org/frx/essays/softfrdm/whatissource.html
https://b.mtjm.eu/source-code-data-fonts-free-distros.html
https://wiki.freedesktop.org/www/Games/Upstream/#source
http://compliance.guide/pristine

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Walter Landry]

Albert van der Horst  wrote:
> For those not versant with assembler. The binary that is generated is
> supposed to be byte for byte the same with both assemblers. If not it
> is a bug. The sources are equivalent, the binaries are the same, it
> really is the same program.
> 
> Note, that I could not have told that I use an internal representation
> and nobody could have guessed (nor benefited.)
> 
> So is the .s accepted as source conform Debian policies?

Unpopular or obscure source formats can still be the preferred source.
Presumably you use this internal representation for a good reason.  If
it helps you, it can help others.

Cheers,
Walter Landry

Preferred source: a fundamental question was Re: - #859130 ITP: lina

[Albert van der Horst]

Gianfranco Costamagna schreef op 2017-06-29 20:32:



we want everything built from the "preferred source of modification".
So, if you develop your tool by changing assembly code this is 
completely

fine.


I do, but there is hitch.

Imagine a Russian scientist with an important FORTRAN package
meticulously documented in Russian because he really doesn't know
English. (If you think that unlikely make it a Chinese).
The preferred source of modification *for him* is this file.
He has made a tool to use "Google Translate" to make an English
version because without understanding the comment the value
is severely degraded.
This is of course in the spirit of open source, and it is the
"preferred source of modification" for the *target* audience.

This is  a far cry from a company that obfuscates its source by
replacing all identifiers by random names, a situation where this
rules is intended for.

Will Debian reject the English package?
Would Debian remove  it if only aftwerwards
it became clear that this is not the *prefered source*
for the *author*? After all he could have kept it a secret and
nobody would have known, and applauded his attempts at crappy english.

I ommited a small detail of my workflow.
I really program in assembler in the sense that a modification is a 
modification to an assembler instruction. Now, all assembler 
representations of a program are equivalent, but they differ greatly as 
a text, depending on the assembler tool used. E.g. a .s and an .nasm 
file are differing in virtually all lines, on account of the comment 
symbol alone. It is a pain in the ass to use an assembler you're not 
familiar with.
What I do is I have an internal representation, that can be rendered as 
.s and as .nasm. 1]
If I publish the program as open source in the context of Debian, I give 
out the .s file because I honestly believe that the "preferred source of 
modication" for a Debianist is the native gnu assembler format. I myself 
change the master file in order to be able to deliver a service to those 
who prefer nasm.


For those not versant with assembler. The binary that is generated is 
supposed to be byte for byte the same with both assemblers. If not it is 
a bug. The sources are equivalent, the binaries are the same, it really 
is the same program.


Note, that I could not have told that I use an internal representation 
and nobody could have guessed (nor benefited.)


So is the .s accepted as source conform Debian policies?



G.


groetjes Albert

1] And more. But that doesn't make it fundamentally different.
--
Suffering is the prerogative of the strong, the weak -- perish.
Albert van der Horst