hello

first of all, thanks for your answer and IMDbPY!


>> i've written a desktop movie database app that uses IMDbPY  to
>> fetch movie information (http://www.corecode.at/moviedb/index.html).
> 
> Cool - when it's available to download, drop me a note (with a
> short description and the license) so that I can add it to the list
> of IMDbPY-based programs.
given you encouraging answer i hope to be able to make a beta release in the 
next few days.

> 
>> but now that the project approaches readiness for public consumption
>> i have some doubts if the "IMDB conditions of use"
> 
> Recurring question, as you can imagine. :-)
yeah sorry i had look at everything on the imdbpy website and also looked into 
the e-mail list archives but didn't find anything besides the small disclaimer 
site. perhaps most of the contents of this e-mail could be copied there?


> [...]


>> 
>> really it seems like using the plain text data files they are
>> distributing is the only legal way?
> 
> In my opinion, the real discrimination is amongst the ways you
> (and your users) will use your program and - even more important -
> the information fetched from IMDb (whether their come from the
> web site or from the plain text data files).
> To explain myself: the important thing is that you (or your users)
> do not make a profit out of it.
> I can foresee some problems if you sell your program, and
> _very serious and well deserved_ problems if you resell the data
> you gather.
ok thanks.
indeed i do not plan to sell my app.
anyway, this sounds a bit like "using IMDbPY or distributing a app that uses 
IMDbPY to fetch movie information is illegal, but they won't come after you 
until you make a profit out of it".

> Those information are _their_ property, and you must not profit from
> them.  For no reason and in no way.
it's a bit disturbing that the data is their property although most of it has 
been entered by users, akin to the gracenote thing.

> 
> Basically, as long as you (and your users) use it for your own
> personal and non-commercial reasons, I guess it's fine.
given i've put so much time into the app already i guess i'll just put the app 
online and if they don't like it they can always let me know and i'll take it 
down.

> This means no reselling (of the data or of a service based on
> that data) and no republishing under no circumstances [2].
yeah i think so much is obvious.

> Fetching data for your own good, with no economic return (not
> even in the form of ads associated to your program or their data,
> for example) is fine, and there's not much difference if you
> access it through a browser or another program.
right. therefore i find it a bit weird that they explicitly forbid extracting 
data from their webpage and on the other hand they put those useless text 
database online.

> 
>> also AFAIK the local access module was removed from IMDbPY and i
>> have the impression using the SQL module is difficult in my case -
>> since it is a self contained desktop app.
> 
> It's not that bad (it's practically identical to accessing the web
> server), but it's true that you'll force your users to run the
> imdbpy2sql.py script and download the plain text data files.
> Not exactly two trivial tasks, for a lot of people. :-)
especially mac users ;->


> 
> By the way, check if the information you need are accessible also
> via the 'mobile' data access system: it's faster and requires less
> bandwidth (but beware that the cast list will be shorter, some
> information will be missing and it's more prone to break, in case
> the html of the IMDb site changes).
ok thanks.

> 
>> what is with the programs listed on the IMDbPY Programs site? are
>> they ignoring the issue? do any of them use the http access module?
> 
> Most of them use the 'http' access module and a lot of them asked
> me your same question. :-)
> 
> Some (but here I'm mostly talking about writers of similar
> libraries, especially in the past), have even tried to ask permission
> to write this kind of program.
> Unfortunately, besides for some very rare exceptions, almost
> everyone got the wrong (standard) reply from IMDb's sell dept and
> they were invited to buy a licence (which - if I remember correctly -
> starts at 50,000 dollars).
the website lists 15.000 now.
which is ridiculous, there surely is demand for apps which can fetch movie info 
from imdb for personal usage. that is a scenario they don't seem to anticipate.
i'm sure they could make some money there, e.g. request a profit share in paid 
apps and require showing their ads in free apps.

> 
> To conclude: I've never intended IMDbPY to be a tool to break some
> copyrighted material and I've always asked IMDbPY users (end users
> and programmers) to do the same; it's their data with their terms
> of use and they must be respected.
> IMDbPY is almost 6 years old, and is by far the most complete and
> widespread library to access IMDb's data.  IMDb is by now well aware
> of its existence [3], to the extent of a public praise from Col Needham
> himself, from what I've heard.
> Anyway if I'm found dead tomorrow, killed by a bunch of ninjas, you know
> who to blame. ;-)
> 
> I hope this more or less answers your questions.

thanks a lot!
> 
> PS: your application looks very cool, and I loved Flesh+Blood, with
> my myth Rutger Hauer and a very young Jennifer Jason Leigh [4]! :-)
;-)
i hope the app is ready soon, though you'll need a mac to use it.

thanks, julian
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Imdbpy-help mailing list
Imdbpy-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/imdbpy-help

Reply via email to