[libre-riscv-dev] kazan | Dual license (#6)

[Luke Kenneth Casson Leighton]

On Mon, Feb 25, 2019 at 7:57 PM Jacob Lifshay <programmerjake at gmail.com> wrote:

> For
> those who haven't paid I think we should have the hw under a lgpl-style
> license with an exception for not needing the results of conversion from
> hdl when taping-out, but we still need a copy of the source with all
> pre-tape-out modifications.

interesting approach, and also important to make sure it's clear that
yes, a commercial license *is* available.

>
> >
> >
> > >  We will also need a method of
> > > determining how much each contributor is payed based on how much they
> > > contributed and a method for contributors to specifically opt-out/opt-in
> > of
> > > receiving any payment for some of their code since they may have had
> > > conflicting agreements with other people/organizations at the time of
> > > contribution.
> > >
> > >
> > I had heard of something called "slicing pie" which has proven extremely
> > effective. The principle is that the number of shares issued increases
> > continuously as each contribution is added, according to the direct
> > proportionate value of that contribution.
> >
> that's what I was thinking of. I was thinking we could determine value from
> the number of lines of code/documentation and a difficulty adjustment that
> would be the mean, geometric mean, or arithmetic-geometric mean of at least
> two other people's opinions who reviewed the code.
>
> In particular we need to not have the value be able to be adjusted after
> the fact to prevent revenge devaluation or similar occurrences.

at the same time the whole basis of slicing pie is that, well,
effectively, new contributions (such as ideas or actual cash) do
actually "devalue" (or inflate) the total number of shares.

this aspect of slicing pie conflicts badly with a one-to-one mapping
onto say ethereum or other crypto-currency, as we cannot simply issue
new ethereum out of thin air when the number of shares increases due
to a new contribution.

in effect we actually need our *own* cryptocurrency to fully recognise
the requirements.  i did come up with a concept of allowing people to
create "sub-currencies" that are [ethereum-]contractually enforceable.

basically for now a standard contract is about what we have time for


> If anyone can think of a totally objective, preferably automated, way of
> measuring value that works well, I think we should adopt it, since that way
> we will avoid arguments about how valuable some contribution is and how
> someone thinks someone else cheated them.
>
> >
> > People may at any time request receipt of either shares or of cash or a mix
> > of both in any proportion that equals the value of their contribution.
> > Obviously if there is not enough available cash then they would *need* to
> > receive shares.
> >
> I think we should only hand out shares, and contributors can sell them to
> other people if they want money right away.
>
> Note that the shares would not give the owner voting rights,

 agreed.

> those belong
> to the original contributor and are not sold, preventing some rich person
> from buying most of the shares and then telling us to do what they say
> since they own all the shares.
>
> >
> >
> > Thus, there is no fixed and unequal founders who get more because they
> > started earlier, then do absolutely nothing and get all the money when
> > everyone else did the actual work.
> >
> > My friend mentioned this scheme to someone who is used to spongeing and
> > controlling others: he hated it. Which is a good sign :)
> >
> >
> > I suggest we set up a token on ethereum that we give some to each
> > > contributor at the time of contribution (or somewhat later to save
> > > transaction fees) and then when we are payed, we split the payment evenly
> > > between all the owners of the token with a threshold amount being
> > required
> > > so we don't have to pay much more in the form of transaction fees. this
> > > allows owners of the token to sell their share or buy more. the token
> > would
> > > basically act like stock.
> > >
> > >
> > Good idea except for ethereum having been recently compromised by over 50%
> > processing power.
> >
> From what I can see, it was ethereum classic that had been compromised, not
> ethereum. ethereum has a 15x bigger hashrate than ethereum classic, making
> it much harder to run a 50% attack. Also, ethereum is switching to
> proof-of-stake soonish so that will make the expense of attacking ethereum
> much higher ($7000M for 50% attack).
>
> we will probably want to ask someone who has more experience with ethereum
> contracts to review it for security to avoid stuff like the DAO incident.
>
> Also, ethereum is the second or third largest cryptocurrency, so it's not
> going away anytime soon.
>
> >
> > Decred might be a better fit, although I like the idea of executable
> > contracts.
> >
> > Needs investigating.
> >
> >
> >
> >
> > --
> > ---
> > crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> > _______________________________________________
> > libre-riscv-dev mailing list
> > libre-riscv-dev at lists.libre-riscv.org
> > http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
> >
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev