Re: Object usage payments

[Anatoly Volynets <av@total-knowledge.com>]

That is out of my area of expertise. Let's see what Ilya says.

Alexey Parshin wrote:
> Well, then any object for donation or payment should have an account.
> If any
> UMO object that can be studied can also accept the donation, or get paid
> for, then my latest schema changes (about a week ago) apply.
>
> 2007/7/2, Anatoly Volynets <av@total-knowledge.com>:
>>
>> If those mechanisms I described called your way, then let it be, I
>> confirm. However, what we need to provide (as described) in terms of UMO
>> usage control and payment, is to be provided.
>>
>> Alexey Parshin wrote:
>> > From what is said I can conclude that we aint going to help authors
>> > get paid
>> > anyhow. Please, confirm.
>> >
>> > What's the next big think we are still missing in the database?
>> >
>> > 2007/7/2, Anatoly Volynets <av@total-knowledge.com>:
>> >>
>> >> Alexey Parshin wrote:
>> >> > So, how are you going to stimulate authors to develop UMOs?
>> >> > Especially, on
>> >> > commercial server?
>> >>
>> >> We are not. Once and forever: we presume that authors create because
>> >> they want to, period. This is out of discussion (sorry, if this
>> sounds
>> >> too harsh; you may put it this way: whenever anyone raises the
>> problem
>> >> how to stimulate authors, my answer will always be the same and this
>> >> answer represents our policies at uu).
>> >>
>> >> Please, remember what our policies are (and thus are to be
>> implemented):
>> >>
>> >> 1. For the Open server (taking Open source as model)  payment for an
>> UMO
>> >> may be asked for, but NOT enforced, while all UMOs are in free
>> usage by
>> >> all. AFTER the UMO was published its author can enforce a stamp only:
>> >> have he got paid or not, according his request. So, author's request
>> can
>> >> sound only like: "I would like...", but this may not go too far, I
>> >> think, this can be only about direct usage only. However, if an
>> UMO was
>> >> ordered, its author must have a tool to negotiate payment from the
>> >> customer and get the payment.
>> >>
>> >> 2. For the Closed (closed-closed-closed... NOT commercial, damn it!)
>> >> server, author must have tool to control usage of his UMOs and
>> thus he
>> >> will have tool to get payment de facto.
>> >>
>> >> > What's the point to write the text, or develop are
>> >> > complicated multi-level UMO, if you aren't get paid? Donations may
>> >> > work for
>> >> > certain category of people/UMO and for certain conditions. But
>> if you
>> >> > want
>> >> > to have commercial server - it doesn't work, IMHO.
>> >> >
>> >> > Also, UMO price offers ways to regulate any funds paid for the
>> class.
>> >> > W/o a
>> >> > UMO price, we can't distinguish the amount of work put by different
>> >> > authors..
>> >> >
>> >> > We can, of course, define a new entity, 'Agreement', and define the
>> >> > percentage of every author for the course.
>> >> >
>> >> > 2007/6/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>> >> >>
>> >> >> 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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >> Anatoly Volynets, Co-Founder
>> >> total-knowledge.com
>> >> culturedialogue.org
>> >>
>> >>
>> >
>> >
>>
>> -- 
>>
>> Anatoly Volynets, Co-Founder
>> total-knowledge.com
>> culturedialogue.org
>>
>>
>
>

-- 

Anatoly Volynets, Co-Founder
total-knowledge.com
culturedialogue.org