UniverseUniversity


Home Projects Jobs Clientele Contact

uu


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Object usage payments



Yes, donations for objects are OK. We just can't limit Study access
to anything but course based on payments.

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
> <mailto: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
>     <mailto: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 <mailto: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>
>     >> >> > <mailto: 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 <http://total-knowledge.com>
>     >> culturedialogue.org <http://culturedialogue.org>
>     >>
>     >>
>     >
>     >
>
>     --
>
>     Anatoly Volynets, Co-Founder
>     total-knowledge.com <http://total-knowledge.com>
>     culturedialogue.org <http://culturedialogue.org>
>
>
>
>
> -- 
> Alexey Parshin,
> http://www.sptk.net 

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com


Authoright © Total Knowledge: 2001-2008