I'm choosing to see updates as no different than at the time.
Half the files I download already have multiple people's names in them
from people updating other people's work in the 80's. I would just keep
doing the same, at least for real edits. I probably would not clutter
things up and consume precious bytes of M100 ram with my name just
because I removed junk null bytes from the end of a file.
In a lot of cases, I would also probably just make a whole new file
rather than edit the old one. It depends how invasive and opinionated
the edit was. A simple bugfix, I just do right in there. This includes
docs not just code. For instance I discovered some legal BASIC code that
one of the renumberer apps fails to handle. I'd insert a note about that
right into the original doc for the app.
Also, this is why I modified the name instead of just using "M100SIG",
even though I would really have rathered the shorter name to make a
shorter url. Living_M100SIG hopefully leaves no doubt, right at first
glance and first introduction even to a brand new user, that it is a
different thing, and even the nature of the difference.
Let git and the original preserved zip file deal with preserving the
original bytes just in case they weren't an error, or in case they are
important for some other reason, like explaining why some other archive
of discussions has so many posts complaining that a file doesn't work,
when it seems to work fine.
Maybe I should actually place the original zip right in the top level
directory with the readme? I wanted it present but out of the way, so
that's why it's in the "releases" tab in github. But that is really a
github feature not a part of git itself. If you clone the repo with a
standard git cli command (not some fancy migrator tool like gitlab
probably has) the "assets" files in releases aren't part of it. But if I
put the zip in the root dir, or in a side dir, then it would be included
in every git clone.
This brings up another similar thing, issues. Issues are where repo
contents get discussed, and those are often worth saving since they
document obscure/infrequent things, sometimes quite technically. And
that is also a github add-on, not part of git itself. I think I'll
investigate possible ways to somehow export or scrape github issues, if
nothing else maybe collect the emails that github sends whenever an
issue is updated, and feed those right back in to the repo proper as
files in another directory? It's not too critical right now just an idea.
As for the mixed licenses, unless and until I or someone comes up with
something better, I just put this in the licenses file:
"
This work(1) is licensed under CC BY-SA 4.0. To view a copy of this
license, visit http://creativecommons.org/licenses/by-sa/4.0/
(1) Defined as everything outside of the M100SIG directory, and all
updates after the initial commit, including within the M100SIG directory.
The original contents of the M100SIG directory are licensed under the
licenses of the respective authors.
"
--
bkw
On 12/18/21 12:50 PM, John R. Hogerhuis wrote:
Well I think that's useful and hopefully it works out.
If you ask yourself why no one has done that before the answer is
propriety, intellectual property, moral rights since none of that stuff
is under an open source license. Particularly when you realize there are
two versions of the M100SIG zip file... one with Wilson Van Alst's
contributions and posts and one without.
Sometimes people get angry about their posts and files they contributed
on compuserve being shared freely. Not many but WvA was the existence
proof.
Now this goes a big step further in allowing anyone to modify the
archive... in a way, change history. I guess the counter argument is the
original is still there in the change history.
And who's allowed to change which files? Copyright, moral rights are
with the creators. But we don't know who is engaged, who cares, who is
dead. As with all orphaned works.
Not saying you shouldn't do it. Just things to think about.
-- John.
--
bkw
