View Single Post
Old 04-19-2011, 05:20 AM   #18
sourcejedi
Groupie
sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.sourcejedi ought to be getting tired of karma fortunes by now.
 
sourcejedi's Avatar
 
Posts: 155
Karma: 200000
Join Date: Dec 2009
Location: Britania
Device: Android
To be clear: I'm not a Calibre user. I use folders and filenames to organise an unusually large number of files in a more portable way. It's an impressive project, and I can imagine suggesting it to others as a solution for a range of needs.

Calibre is free to declare that strict respect for copyright in letter and spirit is an unimplemented feature. And potential users are free to raise feature requests that'd make them happier .

Quote:
Originally Posted by toddos View Post
RSS feeds can contain as much or as little content as a publisher wants. If they don't want to "give away" their content, their RSS feed can consist of nothing more than a link to the web page, and calibre won't follow the link to pull down the actual content.
Reading the Calibre manual on recipes, the BBC example shows it following the link in the RSS, and then downloading the "printable" version of the article. Checking the API docs, it does that dereferencing automatically for all RSS articles under a certain length.

Personally I'd assert Calibre's right to do this even without the RSS, if the issue was noted in documentation (including explanations in recipes where the website explicitly grants permission), and it avoided deliberate mangling or selection without permission. (And the maintainers respected opt-out requests). In my model, going through to the printable version without further comment fails that test. (The BBC is a public organisation, but their content is not in the public domain. What should work very nicely is using the mobile site, even using UA spoofing if necessary; after all, Calibre is acting on behalf of a mobile device.)

To complete the derail: I have recipes of my own to archive webcomics. General-purpose tools let me view the archive in a browser. My principles tell me I should start feeling slightly guilty after doing so (targeted archiving of a commercial site without checking for particular permissions), and slightly more guilty if I use an image-viewer to skip HTML framing (assuming no ads either way -- see "spoiler"). Distributing specific instructions for a large number of image-gallery style archives to a wider audience, who've probably been reading with ads, while soliciting donations for myself, would be well above my current threshold for cognitive dissonance. I've looked at various comic viewers for Linux, but I generally prefer the way things look in my browser. So I have to admit this isn't a very strong temptation I'm resisting, aside from the appeal of writing my own 'superior' programs.

Spoiler:

To some extent this is me showing geek privilege and hair-splitting. I disable AdBlock on Ars Technica, MobileRead and other visit-worthy sites, in line with their wishes. But most of the ad networks rely on Javascript -- and I don't have a reason to whitelist the third-party javascript, especially not on straightforward news sites that work fine for me without even enabling their JS. Tit for tat: I'll feel guilty about their business model when they (tech sites!) feel guilty about browser security.

Calibre and e-ink readers are in a similar position w.r.t. JS: they don't implement it, because it'd take extra effort for what looks like an immediate decrease in overall user-friendliness.

On a different front: I think more people would see an issue if the outputs of the recipes was visible on the Web, on a donation-supported site. I'm not sure that changing the scenario from a website to a desktop application makes much of a difference.

Last edited by sourcejedi; 04-19-2011 at 05:59 AM.
sourcejedi is offline   Reply With Quote