Re: Object usage payments

[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