File hosting, distribution and storage

[Viktor]

Write your suggestions in this thread, I'll update this first post accordingly.

We need file hosting on two levels: for downloads of final works and for temporary files only needed during the creation of a work.

Downloads of finished works can happen through normal HTTP or through BitTorrent. For HTTP downloads, we can rely on several sources: Reasonable Freehosters, privately donated or sponsored webspace, or a big "partner site" helping us like archive.org does for LibriVox. It's even desirable to have one reading on at least two channels, to make sure that at least one is always working. "Privately donated webspace" means we don't need an entire server, just an individual who lets us store up to X megabytes for a traffic of up to (approximately) Y gigabytes.

Criteria for a "reasonable" freehoster:

• All the servers must be located in +70 countries or "better" (Canada).
• Most of them show ads; those should not be too obnoxious, and one should not have to wait a long time before the download. (A popular way to drive people to buy "premium" accounts without waiting. We don't want that.)
• The files must stay available for a certain period without download (say, a month).
• No registration must be necessary in order to download files.
• There should be no or only a very high limit for the number of downloads.
• As the listener has to see ads to download a file, it's better to upload one big file (a ZIP archive) instead of many small ones. At least 100 MB must be uploadable, better is 1 GB. For smaller files (individual collection items), we might find a hoster that directly supports a bunch of audio files or even direct HTTP links.
• They must present a clear way to download the file, particularly when it's a non-English service.
• Ideally, there is a facility for audio files to be played directly in the web browser.

Freehosters fulfilling these conditions are:

• http://ge.tt - Files expire after 30 days without download (90 days with an acccount). Immediate downloads, few ads, direct listening to MP3 files. The servers are currently hosted in Ireland.
• http://dl.free.fr - best suited to French content, accessible but slower for non-customers of the French Internet provider "free.fr". Permits organisation of downloads in "communities". Quite anonymous. Tutorial
• http://storemyfile.org - might be an alternative if needed. Looks very minimalistic, seems to be in France.
• http://www.fileshare.pro - another possibility. This one looks Romanian.

Donators of private webspace should keep in mind:

• Your webspace is hugely appreciated!
• While we can count the number of people clicking on a download link, we cannot estimate the real traffic that will be created. We try not to expose the direct HTTP links, but at some point the listener must be able to see it; and when that listener decides to put that direct link to your server up to Facebook, well... In other words: If you have a hard traffic limit for your server, you must do something to avoid a nasty situation: configure lower softlimits, survey automatically your web server's log files... This situation is not different from any other classic "mirror"!
• If you are already running a public HTTP server, there is no change to your security policy, you're just more public. No need to run any other software!

Update about BitTorrent: While technically a nice idea, we might want to avoid it for now. People from countries where our works are not PD might still participate in BitTorrent sharing and might get into trouble.

Using BitTorrent, downloaders can help by providing their bandwidth. It is particularly fast when many users are downloading the same work (which might happen for the first days after a recording's publication), and it is also well suited for downloads of particular formats (Ogg Vorbis, FLAC) that might not have priority for HTTP webspace. The downside is that it is likely, but not technically guaranteed that all the parts of the recording will show up and the download will finish. If everybody is missing the same part, or if just no seeder is there, the leecher waits, possibly forever.

A whole file is always split up in parts; you must collect all parts for the complete file. For BitTorrent you need a "tracker", that's a public server who connects those who have parts (the "seeders") and those who want them (the "leechers"). There are several public servers that should fill our need. The most famous is The Pirate Bay, which we might want to avoid just because of its "controversial" history As with web servers, we want at least three trackers that are each located in a +70 country. Candidats that we might want to ask include Public BT, OpenBitTorrent and the Canadian Pirate tracker (they only take Creative Commons content). We can also run our own tracker, if the hosting provider does not forbid it (some impose strange conditions).

So much for public downloads. For temporary downloads during the creation of a work, we might use the above freehosters, but "private webspace" where we could run the LV uploader might be better suited here. The conditions are a bit different: we don't need huge amounts of traffic, but a longer availability without downloads, as some time may pass between the first and the last bits of a recording.

Storage policies:

• Finished recordings must be available on at least one HTTP server. The format should be a MP3 of at least 64 kbps.
• A "storage admin" keeps a private copy of the original files (which may be in higher quality - 128 kbps MP3 or maybe even FLAC). The MC is welcome to do this as well.
• Until we have a stable upload server running, the BC and the readers are encouraged to keep all temporary files during the production of a recording.

The private copies of the MC and of the storage admin can be on their local harddisks or on "personal storage" cloud services, which may be located at any place. Examples of such services are Dropbox (2 GB), Wuala (1 GB) or Microsoft Windows Live SkyDrive (25 GB in total, 50 MB per file).

The role of the storage admin is to help the MC, so that it's not necessarily the MC who has to do re-uploads when there is a problem. I think a small number of dedicated persons are enough for a large number of files. They just need a large harddisk (two terabytes are cheap these days), a fast Internet connection, and feel comfortable with such housekeeping. I will be one of them.

Of course, no matter what webserver or what BitTorrent tracker is serving the final recording, we want stable links for public downloads. Within the next two weeks, I'll write a tiny web application for that. We can then have links like
http://legamus.eu/link/Roth-Radetzkymarsch-german for the HTTP download, or http://legamus.eu/link/Roth-Radetzkymarsch-german/bt for the BitTorrent link.
Update: this link resolver exists by now

[Hokuspokus]

re: Hoster
Free.fr - well, er - it's all French. I couldn't even find were to create an account
Another possibility might be ge.tt http://ge.tt/#4fzWf2l
This is something I use for LV.
They keep files 30 days from last download, when you have no account. Files associated with an account live longer, but they don't say how long. They are in Copenhagen.
It is not allowed to pass on log in details, so 1 account can only be maintained be 1 person. Storage must be shifted when the MC retires. Not ideal. But it might be something we could use as uploader for works in progress. (BC needs to download the files, readers need to keep them until the project is cataloged.)

Even though I don't really get the concept completely, I think Torrents would be a good second way. That's something I need to explore myself (there are no questions I can ask at the moment). So if someone tells me: go to this and that tracker and use this and that software, I'm willing to explore it.

For an online backup with no public access, I think we don't need to pay attention to where the server is located.
If we have one public http host, one torrent, private backup on MCs harddrive and one online backup for each completed work, I thing we are on the save side.

[neckertb]

HP, you don't need to create an account for free.fr
You just click on "choose file", fill up the email addresses if you want notification, then click "envoyer" at the bottom and wait. it takes a while for big files though.
Dropbox? Would that work?

[Viktor]

Dropbox would be a good candidate, except that they are based in the US.

As Hokuspokus said, they might be OK for private backups, but not for public downloads, be it temporary forum links or permanent catalogue links.

[Viktor]

Free.fr - well, er - it's all French. I couldn't even find were to create an account

Tutorial will follow!

Another possibility might be ge.tt http://ge.tt/#4fzWf2l
This is something I use for LV.
They keep files 30 days from last download, when you have no account. Files associated with an account live longer, but they don't say how long. They are in Copenhagen.
It is not allowed to pass on log in details, so 1 account can only be maintained be 1 person. Storage must be shifted when the MC retires. Not ideal. But it might be something we could use as uploader for works in progress. (BC needs to download the files, readers need to keep them until the project is cataloged.)

Sounds good. Not sure the servers will always be in the right countries, as they use the Amazon cloud. I didn't think much of the MCs before How many of those are there (in relation to BCs), and how likely would their "retirement" be? Are they supposed to handle all the uploading?

Even though I don't really get the concept completely, I think Torrents would be a good second way. That's something I need to explore myself (there are no questions I can ask at the moment). So if someone tells me: go to this and that tracker and use this and that software, I'm willing to explore it.

No worry, when it's ready a tutorial will follow. Direct interaction with the trackers is not really needed; from the uploaded file a ".torrent" file must be created. This file contains the trackers. The ".torrent" file is what the listener clicks on, and his BitTorrent software handles it. The ".torrent" file is very very small and will fit easily on my existing servers. The generation of the ".torrent" file will happen through a web interface.

For an online backup with no public access, I think we don't need to pay attention to where the server is located.

Agreed!

If we have one public http host, one torrent, private backup on MCs harddrive and one online backup for each completed work, I thing we are on the save side.

With time, we'll see how stable those freehosters are. I suggest we let the MC do just one, and a "backup admin" might take care of a second one.

For the private backups of the best possible quality (maybe FLAC), you're right that one local and one online backup (Dropbox et al.) is fine. If both are done by the same person however, that person is not allowed to disappear I suggest that the MC takes care of one private backup, be it online or offline, and another person, a "backup admin" (can be always me for the beginning) takes care of another private backup.

That also solves the problem for a single HTTP host that disappears; if that happens, it can be the "backup admin" who uploads his backup copy (or the MP3 resulting from that). The MC must not necessarily be bothered.

My idea is that the MC does not get much more work than on LV, and that the backup admin can deal with the hassle of re-uploading files and make the whole storage mess transparent to the MC and the listeners

[Hokuspokus]

OK. I managed to upload something to free.fr.
When you know that you don't need an account, it's very easy. Thank you, Nadine.
I was a bit worried if we can delete an uploaded file. They give you a link at the end of the upload process. We need to keep that when there are mistakes in a recording. We can of course upload a fixed version but other people will (hopefully) copy the link to their catalog or blog and the mistake would be out there for ever.

I don't think it's possible to keep a recording with better quality than what we offer for download. Well, would be possible, but someone has to process them (all files) when a project is completed. There is software that does that automatically, but still it has to run on someone's computer.
I'd say, we ask the readers for 1 certain format, that will be the download and storage format. This format can be 128 kbps mp3 to make it the same as LV, or 64 kbps mp3 to have smaller files.

At LV one MC takes care of 2-20 projects. They do the last checks, upload and make the catalog page. (When I said the other day, that the BCs could do the uploading, I got carried away a bit. Technically they could, but that would omit the last check by an experienced person. No good idea.)
MCs need all keys to the catalog and the database (if we have one). There are powerful tools in the background of LV. Most of it runs automatically. The MC doesn't even need to download the files on their own computer in most cases. As we don't have the tools and no server space to run them, cataloging will be much much more work than it is at LV. I don't think that we can expect one MC to do more that 2-3 projects a the time. Maybe 4-6 if they MC only here and not at LV.
Retirement is very likely after 2-3 years being MC. I'm at 2,5 years now and I feel a bit stretched.
That's why I'm not that happy, that you (Viktor) want to do all the backups. There should be at least one other person who knows the ropes and passwords, etc.
It's very important that we can always cry for help if we can't deal with something for what ever reason. It's no fun, when you must do something.

Torrent tutorial will be very welcome!

[Viktor]

If you upload something on dl.free.fr with an account, I think it's easier to get or recover a deletion link. Tutorial follows shortly

I'm sorry that I haven't been more active within LV itself; I've maybe a lot of naive or wrong ideas of the final steps between BC and MC. Correct me when I'm wrong. The whole idea about "best possible quality in the private backups" was this: When the BC assembles the final version, I imagine that the downscaling to 64 kbps would happen at the very last step. Before, the "originals" that the readers sent him have been maybe 128 kbps or even FLAC (if all readers are fine with that). Metadata is stored separately in the database (and must somehow find its way into the final files). So I thought that there might exist a "final high-quality version" better than MP3 64kbps. If that's the case, couldn't it be this version that gets into the "private backup"? If the public version needs to be regenerated, such a process could be "relatively easily" automated.

I'd even suggest the following: the BC produces a "high-quality version" of MP3 128kbps or greater or FLAC - whatever is possible given the readers' input - to the MC, and the MC uploads that to one of our servers. There, the HQ version gets converted into MP3 64kbps and tagged with metadata from the database.

For the final upload, ideally the server could upload the 64kbps version directly to free.fr. That would be most convenient for the MC.

The main problem with servers is storage space, not so much traffic. A script that takes a large input, converts it and uploads it somewhere else (or back to the MC) is totally feasible.

As we don't have the tools and no server space to run them, cataloging will be much much more work than it is at LV. I don't think that we can expect one MC to do more that 2-3 projects a the time. Maybe 4-6 if they MC only here and not at LV.
Retirement is very likely after 2-3 years being MC. I'm at 2,5 years now and I feel a bit stretched.
That's why I'm not that happy, that you (Viktor) want to do all the backups. There should be at least one other person who knows the ropes and passwords, etc.
It's very important that we can always cry for help if we can't deal with something for what ever reason. It's no fun, when you must do something.

I totally agree with you, and probably I didn't make myself very clear. I absolutely do want to be replaceable and hand over all access that's needed to at least one other person. I rather wanted to improve on your suggestion that the MC keeps one private offline and one private online copy by suggesting that the MC keeps one private (offline or online) copy and that a storage admin keeps another (offline or online) copy. When the private backup is needed, it can be either the MC or the storage admin who provides it. And I don't want to be the only storage admin! The goal of this "storage admin" is just to help the MC by not putting all the backup borden on him.

[kattekliek]

As for the size of the MP3's: I think that if we stick to mono-speech like on LV, it is not necessary to go any higher than 128 kbps. Someone over there did a little check: re-encoding MP3's several times, and found that at least 5 or 6x at 128 kbps was necessary to get a noticable decrease in quality. BC's or MC's might have to re-encode 1x or 2x, e.g. to do an edit when a reader is gone, or to fix the overall volume of a group project. It would be no problem whatsoever with 128 kbps. We should check if it would be when using 64 kbps. If also with 64 kbps, 3 or 4x re-encoding doesn't lead to audible quality loss, I'ld say: let's go for that! If it does, my proposal would be: 128 kbps 'working bitrate' and 64 kbps final product (also for backup storage offline). The probability that anything will have to be changed in an already catalogued MP3-file is very small.

[Hokuspokus]

I agree that it would be nice to have flac files first, while we are working on it and only encode to mp3 for the final release. But: Many PLers use their mp3 player for listening and many of them can't play flac.
Many useful software (mp3gain, mp3tag, ... )works with mp3 only.

And I'm not happy with the BC producing files.
At LV the BC initiates a projects, splits up a book into sections, notes the claims (in the Magic Window, but in the old days by writing it down in the first post), adds the link to the recording into the MW or first post, nags readers to full-fill their claimes or orphans the section and checks the tech specs and ID3tags. That's it.
But even that is a big thing when you do it the first time.

I suggest, the reader produces 128 kbps files. If you, Viktor, can invent something, that creates 64 kbps automatically, wonderful! If not, I'd rather release bigger 128 kbps files than adding another step in the procedure.
And 128 for back up. We can always make them smaller, but what's lost is lost.

A tool that uploads to free.fr would be excellent! That's one big part of the LV cataloging tool.
The other parts could be done with mp3gain and mp3tag, at least with Windows. Unfortunately there are no such tools for Mac or linux as far as I know.

The metadata ideally is stored in the ID3tags, done by the reader. LV has a tool that can suck the tags from the database in the final cataloging, but I fear we are far away from that. With mp3tag, one can check the tags, mass-set tags or change them individually.
http://www.mp3tag.de/

[Viktor]

I agree that it would be nice to have flac files first, while we are working on it and only encode to mp3 for the final release. But: Many PLers use their mp3 player for listening and many of them can't play flac.
Many useful software (mp3gain, mp3tag, ... )works with mp3 only.

I don't want to change their habits. I think of FLAC private backup only for such cases where everybody (or the soloist) did already use FLAC.

And I'm not happy with the BC producing files.
At LV the BC initiates a projects, splits up a book into sections, notes the claims (in the Magic Window, but in the old days by writing it down in the first post), adds the link to the recording into the MW or first post, nags readers to full-fill their claimes or orphans the section and checks the tech specs and ID3tags. That's it.
But even that is a big thing when you do it the first time.

OK, thanks for explaining that! So there's no editing step involved after the reader, just checks.

I suggest, the reader produces 128 kbps files. If you, Viktor, can invent something, that creates 64 kbps automatically, wonderful!

A piece of cake! For years I have been doing all of my converting of audio files on the command-line. When my Linux at home can do it, any Linux server can do it.

And 128 for back up. We can always make them smaller, but what's lost is lost.

Exactly!

A tool that uploads to free.fr would be excellent! That's one big part of the LV cataloging tool.
The other parts could be done with mp3gain and mp3tag, at least with Windows. Unfortunately there are no such tools for Mac or linux as far as I know.

Everything is possible with Linux
As long as free.fr doesn't get unhappy with massive uploads from the same server, it should be possible. Uploads are possible through FTP - that can easily be automatised.

The metadata ideally is stored in the ID3tags, done by the reader. LV has a tool that can suck the tags from the database in the final cataloging, but I fear we are far away from that. With mp3tag, one can check the tags, mass-set tags or change them individually.
http://www.mp3tag.de/

That's a bit I don't understand. If there is a MC who enters metadata in the database, and if there is a server who produces or at least receives the final MP3 versions, it is most obvious to me that it should be the server who puts the metadata from the database into the files. Maybe the initial input of metadata and the upload of files even happens in the same step, then the link between them is easy.

Is that the goal, to free the reader from dealing with metadata? Is it just that we don't have such server scripts at the moment? That should be possible within a timeframe of, say, two to three months. Server-side processing like converting MP3s, filling out metadata and uploading files is actually the easiest part! Time is needed for everything else: a comfortable interface, user authentication, and efficient uploads.

[Hokuspokus]

The metadata ideally is stored in the ID3tags, done by the reader. LV has a tool that can suck the tags from the database in the final cataloging, but I fear we are far away from that. With mp3tag, one can check the tags, mass-set tags or change them individually.
http://www.mp3tag.de/

That's a bit I don't understand. If there is a MC who enters metadata in the database, and if there is a server who produces or at least receives the final MP3 versions, it is most obvious to me that it should be the server who puts the metadata from the database into the files. Maybe the initial input of metadata and the upload of files even happens in the same step, then the link between them is easy.

Is that the goal, to free the reader from dealing with metadata? Is it just that we don't have such server scripts at the moment? That should be possible within a timeframe of, say, two to three months. Server-side processing like converting MP3s, filling out metadata and uploading files is actually the easiest part! Time is needed for everything else: a comfortable interface, user authentication, and efficient uploads.

That would be so great!
I only didn't realize that it's easy for you to do that.
All the past time when I tried to imagine such a project I thought about the things I could do and a way I could make it work.
Now may I add one more point to the wish list? Could you build something that collects all the data from a database and puts it together into a HTML catalog page? Something we could copy and past where ever we decide to have the catalog.

[Viktor]

Now may I add one more point to the wish list? Could you build something that collects all the data from a database and puts it together into a HTML catalog page? Something we could copy and past where ever we decide to have the catalog.

Sure, that's very much what I had in mind. Instead of all-dynamic web sites or big CMS systems that are sometimes hard to adapt, I prefer to write a script that generates static HTML pages out of the database. Changes in the database trigger a re-generation of those static pages, which could, as you say, be hosted anywhere.

By the way, I modified the "storage policies" of the first post. Now there's a tutorial for free.fr; and indeed, after some testing, it's best used for French content. For other languages, we might find something better, where people don't have to hunt for a little link "Téléchargez ce fichier".

[Carl Manchester]

Hi all,

I'm not a lawyer. But, on the internet, anyone can be a lawyer if they want, and it occurs to me that maybe the project would need to pick a single legal jurisdiction and stick to it. LV goes by the notion that its files are hosted in California, so that's whose law applies. I would guess there are various grey areas involved, but if your files are all over the place, what happens then? Does it mean you are obliged to follow the lowest common denominator taking into account all the different applicable statutes? Which one do you point to if you get a complaint?

One reason for raising this is that it seems like there is less consistency than you might expect even within the EU. Over in this thread I suggested 10 books for recording.

As far as I can tell, copyright doesn't seem to be consistent within the EU in 5 of those cases (or at least, the rules are extremely complicated). Given that I wasn't deliberately trying to find tough cases, 50% of our sample seems quite high.

To summarise (please feel free to skim-read): Lady Chatterly's Lover first appeared in Italy in the 1920s. But it seems this was a private printing, so it is not clear whether it counts as a publication for copyright purposes (it is undoubtedly possible that different views might be taken about this in different countries). For some countries, this doesn't matter. DH Lawrence has been dead more than 70 years and that's all there is to it. However, if we were to take the view that the first publication that counts was in 1960, then the book might still be under copyright in (for example) Spain, where posthumous works are protected for 70 years from publication. Wittgenstein's Philosophische Untersuchungen I had taken to be in the public domain following rules that apply in the UK regarding posthumous publication. However, it seems that in various European countries posthumous publication is irrelevant to copyright status. This seems to include Germany, Austria and Switzerland, which would make it quite hard to find readers (as if it wasn't already going to be hard enough). Paul Nizan's La Conspiration seems to be public domain everywhere in Europe with the exception of France, because France gives a 30-year extension for author's who died on active service. Lampedusa's Il Gattopardo seems to be PD in several EU countries but, crucially, not in Italy. Orwell's Such, Such Were the Joys is another case of posthumous publication. It is PD in the UK, but probably not in most of Europe. Another factor, which didn't come up, is where public domain status relies on the Rule of the Shorter Term. All EU countries are supposed to have implemented this but it is not clear that all have. Even where they have (for example in Germany) court rulings would seem to invalidate it in many cases.

Apologies for the ramble. It's very complicated, so I may have some particulars wrong. But that would just prove my point. It's very complicated. I would guess that, if you're focussing particularly on works that are still copyright in the US, then these types of cases are going to constantly come up.

So...the opinion I'm putting forward it that Legamus should throw a dart at a map of Europe, settle on a country that it is going to call home and ensure that its files are all hosted there.

[Viktor]

Dear Carl,

are you based in the UK? Why are you at all surprised that anything that spans several European countries is necessarily going to be a chaos? Maybe a beautiful, enriching, mind-expanding chaos, but still a mess! (Wasn't it along these lines that L'Auberge Espagnole ended...?) And then you add cloud computing, and - booom!

Your example with France and its 30-year extension for authors who died on active service is hilarious. Fits well within the picture - in French public transport it's always written that pregnant ladies and war invalids (among others) get priority seats, but the war invalids have higher priority than the pregnant ladies.

Frankly, I don't see this (yet) as a huge problem. Legamus was always intended as life+70, not necessarily all of the EU and certainly not only the EU. For posthumous publications, I don't understand why that rule should be shortened in any way. If the UK does it, good for them but it does not change the understanding of "life+70".

Of course, your France example is good as it shows the real problem: when life+70 is not enough because of national restrictions. Such unfortunate cases can only be avoided by not storing them on a French server. We won't be crazy and say: "You can download this from wherever you are in Europe, and we are ready to get sued if you get any problems", but "please verify the copyright status of these works in your own country before downloading, otherwise you may be violating copyright laws" as an excellent free audiobook web site says.

As for Lampedusa, is that yet another posthumous one? I don't see how Giuseppe Tomasi di Lampedusa (1896-1957) could possibly be PD according to "life+70".

It is definitely a good idea to store all "unfortunate exceptions" like the French one somewhere, for avoiding at least the part of the European chaos that we know already, and to list for each hoster the countries where he is active (hopefully just one per hoster). Unfortunately we don't have a huge choice for "a single base", as not every country has an abundance of freehosters and affordable servers.

All the best,
Viktor.

[Hokuspokus]

It wouldn't help us much to host all files in one country. We still need to advice our readers what they can read and give a clue to the listeners, what they can download. Therefore we shouldn't do any shorter than life+70.
Wikipedia writes:

Die nationalen Gesetzgeber sind grundsätzlich frei in der Entscheidung, ob sie erloschene Urheberrechte wiederaufleben lassen. Mit der EG-Schutzdauerrichtlinie von 1993 (in Deutschland 1995 umgesetzt) wurde die Schutzdauer des Urheberrechts für die EU auf 70 Jahre p. m. a. einheitlich festgesetzt und zugleich bestimmt, dass der längste Schutz in einem der Vertragsländer maßgeblich sein sollte.

The longest term should be applied.

We should keep a list with all rules that make copyright longer. It wouldn't make much sense to record a Spanish book with longer copyright, when most potential listeners (and readers) can't work with the text.

But we need to talk about licensing our work. In EU or most parts of EU it's not so easy to make something pd just by saying so. Starlite pointed out CC0 the other day:
http://creativecommons.org/about/cc0
http://wiki.creativecommons.org/CC0_FAQ

This is as close to pd as we can get.

[neckertb]

For French authors dead for the country, as far as I know, it only applies in France. I could record them for instance (at least, that's what I've been told on LV, and Jc based in Canada, has recorded some Apollinaire for instance).

[Carl Manchester]

IThe longest term should be applied.

My point, really, is that this would be too complicated (not to mention unnecessarily complicated) to operate. Someone would need to decide what countries matter, make a complete survey of their copyright laws then keep on top of it on an ongoing basis.

Of course, it would be sensible to advise Spanish (for example) users to ensure that they follow the law where they are. But that's surely just boilerplate, and would equally apply to Chinese or Australian users.

I think it would be simpler to say (for example) that German law applies and then host all the files in Germany (because if you host some of the files in France or Hungary or whatever, why should anyone accept that German law applies?).

I just seems to me that putting files in various countries is not beneficial to anyone and it just makes it unclear what rules should be followed.

[Viktor]

I think it would be simpler to say (for example) that German law applies and then host all the files in Germany (because if you host some of the files in France or Hungary or whatever, why should anyone accept that German law applies?).

I just seems to me that putting files in various countries is not beneficial to anyone and it just makes it unclear what rules should be followed.

I understand your point, but I fear your solution to stick with just one legislation is too simple. We'll have to consider every case - at the best of our knowledge - individually anyway.

Many Europeans, and I think particularly many of the forum participants here, are "mixed" anyway. I think Peter Ustinov said once around the time of the Balkan war: "I'm not ethnically cleanable. Impossible." Technically, what counts? Take me as an example: My nationality is German, my place of residence is France, legamus.eu is registered with a French provider, in the whois you'll find my German e-mail address. Some subdomains redirect to French servers (as this forum), others might redirect to some of my German webspace.

Then, even if we clear the location of the servers, organisationally we'd still run into lots of problems with languages, readers and listeners from various countries. I fear that no single legislation can replace common sense, prudence and a case-by-case approach. Take English and German as examples. One can safely say that there is an important number of English speakers in the US, the UK, Canada, Australia and others (say, India). It is perfectly reasonable to create an audiobook of a text that is non-PD in the US but PD in one or more of the other mentioned countries.

On the other hand, creating a German audiobook on LV that is non-PD in Germany, Austria and Switzerland but PD in the US or Canada cannot be called reasonable. I think this kind of case-by-case reasoning does already take place within LV. Sure, this is subjective, but so is life

[Viktor]

Friendly answer from ge.tt:

Our servers are located in ireland. And for the moment it's not likely to change. I can not guarantee it, though. But since this will have consequences for some users we will notify users if this should ever change. Until now we've had no issues with using servers in ireland, so I don't see this change, though.

[kattekliek]

Great!