Text 40838, 159 rader
Skriven 2006-10-06 04:51:41 av mark lewis (1:3634/12.0)
Kommentar till text 40829 av Matt Bedynek (1:106/1)
Ärende: DUD-file
================
ml> outside in the other world lies the law... this copyright stuff is law
ml> and it is the law that janis was looking to protect the IFDC systems
ml> from by following the IFDC policy... never forget, the law overrides
ml> everything...
MB> It has not been demonstrated that the law was broken or in treat of
MB> being broken.
that copyright statement (appears to) put specific limitations on the article
that attempt to prevent it from being made available via ftp, http download,
and http document viewing...
take a look at it straight up without consideration for where it was written
and see what you think it says... in other words, take it at face value...
(c) 2006, Michiel van der Vlist. All rights reserved.
Permission granted to distribute by means of the FidoNews
echomail conference and the FidoNews file echo only.
that specifically limits the distribution to two places and two places only...
there is no statement that it was written in any specific country and actually
only applies to systems in that country... nor is there any other indication
that it does not apply outside that country...
ml> the funny thing about that is that the same connections still remain
ml> in place as they did when those associations were in effect ;)
MB> With the exception of one so-called hub the days of musical links
MB> are long gone. With the unfortunate departure of juge there have
MB> been some changes to topology. Only time will tell if these changes
MB> will be stable but I believe they will be.
it is unfortunate that bobJ left...
ml> and to think... all this mess started because three "fat daddys with
ml> large pockets" decided to link together in a triangle and facilitate
ml> the distribution of fidonet echomail to help remove a lot of the delay
ml> time in propogation... others got jealous, advanced and grew, joined
ml> that triangle as others dropped out and then led the charge in
ml> creating private groups doing the same task... the whole problem
ml> is/was competition and "mine's bigger or better than yours"...
MB> I believe it was more an idea of ideaological differences. What
MB> prompted the creation of a Z1B was centered around the disagreement
MB> of how echoes were to be handled with respect to purging. Also,
MB> there was a lot of two personal differences between two people that
MB> account for the bulk.
true but that was also only part of it... the problem with purging of "dead
echos" started way back... the original three stars had a specific set of rules
that one had to follow to get their echo carried on the backbone... johnS tried
to maintain these rules for quite a while and actually did relax them to make
it easier for echos to "get 'boned"... i don't remember the original rules
exactly but they went something like this...
1. the echo must be in the echolist
2. there must be more then 10 systems getting the echo
3. there must be more than 10 messages a week
4. distribution must cover more than one region
this meant that the echo had to have been in existance long enough for other
systems to know about it and connect to it via private links (ie: they are
making the call for the haul)...
removal of an echo was equally easy... all one had to do was fail to maintain
one of the above 4 rules for longer than a few weeks or possibly even as long
as a couple of months... at that point, the echo was removed and if there was
still any traffic in it, it went back to private distribution...
this also lead to "echo bouncing" where'd they be on the 'bone, off the 'bone,
on the 'bone, off the 'bone... that, too, had to be handled but i don't know
what they did other than maybe giving them two or three chances before not
carrying the echo at all...
all this was long before johnS joined the backbone and became the southern star
system... heck, i used to pull from him at 2400bps and that was right after he
joined the 'bone and took over one of the three available slots... and there
were only three at that time... i don't remember how or who fed the other zones
nor do i know what backbone topology other zones had back then... i do remember
the name "tip top" as a group that humped the mail across both oceans,
though...
ml> the IFDC is the ultimate authority on the files it carries within the
ml> confins of the IFDC boundaries... those boundaries are denoted by the
ml> list of areas that the IFDC considers to be IFDC areas as well as the
ml> list of systems that the IFDC considers to be IFDC distribution
ml> points... if the IFDC wants to prevent tunneling as others are trying
ml> to say the snooze area is being done, then the IFDC must cut off
ml> automatic distribution access of those areas to other systems such
ml> that there are "hard" boundaries and such that for those files carried
ml> by the IFDC must be acquired by some other means than being TIC'd out
ml> to them...
MB> Not if any decisions it makes conflicts with policy.
so, if janis wasn't a *C of any kind, there'd not have been any conflict with
policy in your eyes??
MB> That is why I say policy is the ultimate governing authority
MB> here. If it is determined and agreed policy is not violated then
MB> the rest of the discussion is pointless since if policy is not
MB> violated the filegate can do whatever it wants.
within the law... you keep forgetting about that ;)
ml> i think you mean that if she had just held the file that we'd have a
ml> reversible delima (not irreversible) because she could then just put
ml> the file and the tic back in place... sadly, though, the file and tic
ml> had already been processed and thus the only recourse to protect the
ml> IFDC and the IFDC systems was to remove the file from those systems...
ml> there's only one way to do that which is what janis did... now that
ml> there was a stink made about that, configs all over fidonet have been
ml> changed to prevent it from happening again... guess what that's
ml> done... it has also stopped a re-hatch from the top from making it out
ml> to all systems...
ml> don'cha jus' lurve it! O8}
MB> You may not think so but I can understand where a concern might
MB> exist. Due to how I think, I can invent a half dozen other
MB> scenarios that would indeed be a real problem (legally). For
MB> example, what if a node were to post a message (a key generator to
MB> windows xp in uuencoded format). With the exception of squish most
MB> tossers do not allow someone to 'recall a message' and everyone
MB> passing or holding that message on their system would be in
MB> violation.
that has always been a problem in fidonet since the creation of echomail...
moderating in fidonet is *RE*active instead of *PRO*active... moderators in
fidonet have to react to violations whereas moderators in usenet and wwivnet
(just to name two that i know of) have to approve messages first and then put
them in the message area for further propogation... this puts a big load on a
moderator if they have heavilly trafficed areas... i likely would never have
become a moderator of the RemoteAccess BBS support areas if fidonet moderating
was proactive... back in those days, traffic ran 500+ messages/day each in the
two existing support echos... that was over 1000 messages to read, approve and
then forward into the echo for everyone else to read... yeah right! like the
moderator'd have any time to sleep or work, unhhunh...
then there's also the censorship thing where the moderator could be accused of
censoring someone's messages... and also the liability factor whereby a
moderator and/or sysop are liable as accessories in illegal activities if they
read about them and do nothing about them... they may still be held as
accessories if they do stop the communications but do not report it to the
law... this is one reason why i do not monitor things that travel thru my
system... i have always tried to follow "common carrier" standards specifically
to avoid being sucked into things like this... if you do monitor, then you must
monitor all... if you miss one thing, then you are still liable... this was one
reason for the "no coded messages" rules... but that never stopped messages
that one would likely never know contained an embedded message... i have a good
example of that around here somewhere and have posted it several times in the
past... in fact, i've had to recreate the wrapper message several times due to
not being able to locate the saved copy ;)
)\/(ark
* Origin: (1:3634/12)
|