[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Object usage payments
Alexey Parshin wrote:
> Ok, the question is, then:
>
> If any UMO is included into any other freely, how do the authors of
> the UMO get paid?
They don't.
> In my understanding, every UMO has a price of usage (one way or
> another, including price = 0).
This is where you are off. UMOs don't have price. We can associate
donations with them.
Maybe. But that's it.
> In turn, if a particular UMO of one author includes some UMO(s) of
> other authors - the payment for that UMO should get to other authors
> somehow..
>
> 2007/6/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
> Alexey Parshin wrote:
> > Gentlemen,
> >
> > It's time to discuss - how do authors may define the payment policy
> > for their UMOs. I came up with the following potential policies:
> >
> > 1) Fixed payment. Once an author pays a UMO, he can use it in as
> many
> > other UMOs as he needs. I doubt that is what the author of this UMO
> > wants.
> > 2) Fixed payment for any including of the UMO in one's UMO.
> > 3) Periodic payment: same as 1) but with lease period.
> > 4) Periodic payment: same as 2) but with lease period.
> > 5) ?
> From the original proposal:
> ---------------------------------------------
>
> 10. Following class creation rules are available:
> - Fully open, accept donations: anyone can create class, if
> donation
> of minimum
> is given to author, teacher has an option to show a stamp
> on his
> course. Not
> giving a donation will show up on course as well.
> - Fully open, don't care about money: anyone can create class, no
> donation absence
> marker will be shown.
> - Payment required, perpetual: Fixed payment is made, and class
> exists indefinitely
> - Payment required, periodic: Flat rate payments for defined
> period
> of time.
> - Payment required, percentage: Percentage of teacher's income
> from
> this class
>
> ---------------------------------------------
>
>
> >
> > These policies, of course, should be implemented as stored
> procs, so
> > we can always define more. But I need to estimate at least the
> general
> > requirements for them.
> One important thing is: we do not bind payment to an UMO. Any UMO
> can be
> included
> into another one without limitations (except for limitations
> imposed by
> kinds - can't make
> a topic a part of a problem). With this in mind, you'll realize it
> makes
> no sense to assign
> payment to any UMOs besides course (which is the only
> non-shareable UMO
> - you can't
> include the course itself into anything else).
> >
> > It is more or less clear, that every non-free UMO should have an
> > account. Such accounts would be created simultaneously with the
> > payment policies. The absence of the payment policy indicates free
> > object.
> >
> > A separate issue is a distribution schema. A payment(s) made to
> a UMO
> > account, eventually (or periodically) should lead to author's
> payments.
> > After some money paid to UMO's account, how do we distribute this
> > money among the authors? We can, of course, just distribute the
> money
> > among the author(s) of top-level object. But, is it the only schema?
> The issue is not distributing money between authors of UMOs (for
> reasons
> stated above), but between authors of a course.
> We need to come up with a way to let authors come up with proper
> distribution of funds between each other.
>
> >
> > --
> > Alexey Parshin,
> > http://www.sptk.net
>
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com