[ILUG] IOL Broadband handing over information.

[Gareth Eason]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Conor Wynne wrote:
[munch...]
| Personally I restrict myself to ripping movies from DVD's I own -
| The reaon being my kids tend to scratch every single CD/DVD in the house,
| and the shops are far too mean to replace them when scratched. Does anyone
| know how I can get the big corporations to replace them? I seem to
| remember "The Sex Pistols" jumping on the CD's to demonstrate how
| indestructible they are, however my kids disproved that one.

	Bring them back to the shop you bought them at and demand that they be
replaced. Argue. Point out that you would be willing to pay a nominal
fee for the replacement of the medium so you may use the _LICENSE_ you
have paid for to utilise the material contained upon the medium. Force
the issue. Complain loudly enough so that other customers in the shop
can hear how you are having difficulties and the unreasonable shop
assistant is unwilling to help. Request a refund for the remaining
license period for utilising the data on the medium, since you may no
longer do this due to the medium being damaged. Point out that you would
have taken a backup copy (allowed by law) but that the RIAA / MPAA /
etc. suggested that this may be illegal and since you are not a lawyer
you did not wish to risk it. Rinse repeat. Write to the record label.
Write to your MP.

	Currently record companies are using two separate streams of law on CD
(and DVD I assume) material. One is the sale of a product - (you've
bought a product and you've damaged it, tough luck... but if you buy a
product you may do whatever you chose with it!) and one is a sale of a
license (you may only do certain things to the data on the CD/DVD - i.e.
listen to it, but not copy it, etc.)  This is hugely problematic, since
record companies, etc. are cherry picking the bits that suit them from
both streams of law... not exactly fair really...

	I've only had one CD that got a nasty scratch on it and the record shop
was kind enough to replace it for me, without me pushing the issue. I
did still have a receipt proving I had purchased it from there (in fact,
it probably had shop stickers on the case still) - but I would have been
prepared to argue :-)

	Same goes for software shipped on CDs with EULAs and license
agreements. Force the supplier / manufacturer to pick 1 (ONE) law to
cover their product, rather than cherry pick to suit...

	IANAL, YMMV, etc., etc. A proper lawyer can give you details of what
exact laws referred to and google will likely find you lots of
contradictory information regarding the whole thing.

	Aaaaaaaand back On Topic: Yes - it does depend on the bittorrent client
you use, regarding whether it will upload stuff other than what you're
currently downloading. It's considered polite to remain connected and
act as a seed after you've completed downloading something. This allows
torrents to remain live for longer and be available faster, etc., etc.
Most clients (AFAIK) have some kind of cache directory, and will serve
most anything out of that directory, allowing it to be downloaded
(assuming the tracker is live and advertising the file on your server.)
Any clients I've used have made it clear as to whether they are
uploading just the file I'm downloading, or others as well. Interfaces
to BT clients such as ABC allow you to turn on and off seeding of other
files at will, which is useful.

	BT nets use CRCs (MD5sums IIRC) to verify blocks, so even if you frig
your client so that it 'thinks' StarWars.avi is Ubuntu.iso, the other
clients will reject any blocks you send - and start marking you down as
a poor source with high error rate. (This is a simplification - the
BitTorrent algorithm and configuration is well documented on the net for
those who want the exact details.)

	As always, usual disclaimers apply - no doubt someone will pull out an
example of a BT client that does something completely different and
contrary now... but them's the breaks ;-)

	Best regards,
	-->Gar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCqHGAK36C50PvIR8RAvLwAJsHwEFLRyhu7r82k8af4dxPyiNSPwCfbId7
xrS8F/cu6DrmNK9zH/co1ZI=
=kwKg
-----END PGP SIGNATURE-----