[libre-riscv-dev] kazan | Dual license (#6)
Jacob Lifshay
programmerjake at gmail.com
Mon Feb 25 19:57:22 GMT 2019
On Mon, Feb 25, 2019, 10:50 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:
> PS I am annoyed with myself for not asking questions in my previous
> replies. Feel free to assume that what I wrote is up for examination,
> questioning and alternatives.
>
> On Tuesday, February 26, 2019, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > On Mon, Feb 25, 2019, 03:29 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > wrote:
> >
> > > Or pay us.
> > >
> > If we're going to allow people to buy a proprietary license from us, we
> > need to have that in a contributor agreement because not all the
> > contributor's have agreed to allow that.
>
>
> I hadn't specifically discussed it, however it's part of the Charter to
> ensure that everyone is financially rewarded.
>
there are some drive-by contributions already, so we'll need to either
totally replace them or get the contributors' permission. I personally
think that we shouldn't license drivers under a proprietary license even if
we're paid, we should only license them under the lgpl. we can license the
hw design under a proprietary license for those who want to buy a license. 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.
>
>
> > 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.
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, 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
>
More information about the libre-riscv-dev
mailing list