Closed skmp closed 6 years ago
Check: "Verein" and "Genossenschaft" in the OR (Obligationenrecht), for under swiss law.
I'm going to be taking a step back in how much I take on at once. I think this helped to put things in perspective and make me realize I have been placing too much focus on this project and neglecting my personal life. I have invested more time in this than anything else and cannot keep putting other things off. As for the legal side of things, I have not been overly involved in the core ("at risk") components of the emulator primarily because I am in a region where it would not be unrealistic to become a target for legal action. That said, any "open source" license should fit me fine as long as it does not exploit my intentions of contributing it to reicast.
I see. Will you stick around the following weeks during the android studio merge or shal I take over that work?
I'll only be taking a step back in terms of quantity, not disappearing. The work is already done, though. It's been idle for nearly a month now.
Kk
On Thu, 10 May 2018 at 14:38, TwistedUmbrella notifications@github.com wrote:
I'll be taking a step back, not closing my account. The work is already done, though. It's been idle for nearly a month now.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1148#issuecomment-388029422, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYAMv837pHU-Dd86CjkL2WwDkk29Pbcks5txCadgaJpZM4T3kp7 .
-- ~skmp
Other important stuff happening or getting organized this month: #1150 #1144 #1138 #1093
After chatting w/ @twinaphex today, I found that bountysource also supports regular donations, without us needing a legal entity, tax liability or fees, apart from a 10% fee on cashout, which is incurred to the final recipient. From my understanding, re-invested money has no tax liabilities or fees. It's not an ideal paradigm, but looks fair enough to me. Opinions?
I claimed the project that had been auto-imported from github, and >>> https://salt.bountysource.com/teams/reicast <<< should work. If there are no objections, can the core team members please register these and get in touch with me to add them to the team? Thanks :)
As a large portion of our userbase comes via retroarch, and I'm not personally a huge fun of bounties, I propose to use the donations to cover regular dev costs, and let the bounties up to the RA community / independent users like we are doing right now. Thoughts on that as well?
@MrPsyMan @LoungeKatt
edit Updated URL to the correct one
edit #2 Updated to clarify how this is independent from the existing bounty system
edit #3 Looking at bountysource it looks like it has all the bounties from @twinaphex also listed, I guess bountysource automagically created the org via github import?
edit #4 Whoa, bountsource looks really good so far. Thanks for the referral @twinaphex :3
Being brutally honest, I think avoiding the legal entity hoopla and bounties directly are both for the best, but without completely denying any means for allowing some of the cost to be shared. I understand that the whole premise to RA trying to link back to the main source with the bounty program is, at its core, an attempt to improve RA by improving the entire core. That is fine for that program because it is a "private" project that aims to plug this core into a larger collection of cores. They need everything to work or the idea doesn't "sell" as a complete solution. As an individual project, doing the same would be selling out. It is pretty standard for the core emulator to be a community project based on charitable donations, while others establish bounties to push it.
Keeping the bounty system separate also eliminates three possible adverse effects. One is that contribution becomes a job, along with the pressure and stress associated. Another is that contribution becomes competitive, where the goal of having it worked gets blurred by the goal of achieving the payment. The last is that bounties can direct progress, where throwing some money makes something a goal with undue influence. The first two do have their benefits, which is where allowing an "attached" entity to filter them through is an optimal solution. The project doesn't sell out, but the idea still exists. As for the third, where an after-the-fact gratuity outweighs a stipend for completing a desired task, is why they are better left indirectly integrated.
I have never been entirely fold of the legal entity discussions because that is a huge leap of trust. While I don't feel @skmp would ever have any intentions but the best for the project, the "typical" assumption dictates that such a step is taken to gain ownership for reasons that are not always the best. A perfect example was the initial response to the CLA. Often, the assumption is that someone is trying to "take" code to exploit for their own gain. Having been a part of contracted work in the past, I understand that it is just as important for the person being provided the code to have some legal proof of rights to it as it is for the person providing it to not sacrifice their rights. Anything that can be done to avoid too much individual control is probably for the best.
We live in a very skeptical world where people always assume the worst of everything. The best we can do is avoid as much room for doubt as possible without having to bankrupt the project trying not to admit we need the help. It seems like the idea above is as close as we can get.
Please don't grade this essay. I forgot a cover page.
Yeah, that’s why I don’t want us to rely mainly on bounties. It’s nice to have inventive for hard tasks, however the project needs to have sober technical guidance and leadership
On Mon, 11 Jun 2018 at 21:25, TwistedUmbrella notifications@github.com wrote:
...and then there is the aspect of bounties directing progress versus aiding it. This is perhaps the biggest reason to make them "donations" over "payments" because a donation is an after-the-fact gratuity for what was done, where as a payment means a defined stipend for desired services.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1148#issuecomment-396357690, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYAMtYTcF7Ur26iF-NZU_5Gbg9VbbLmks5t7sQngaJpZM4T3kp7 .
-- ~skmp
And often the correct solution is totally not obvious to external observers/contributors
On Tue, 12 Jun 2018 at 13:22, skmp skmp@emudev.org wrote:
Yeah, that’s why I don’t want us to rely mainly on bounties. It’s nice to have inventive for hard tasks, however the project needs to have sober technical guidance and leadership
On Mon, 11 Jun 2018 at 21:25, TwistedUmbrella notifications@github.com wrote:
...and then there is the aspect of bounties directing progress versus aiding it. This is perhaps the biggest reason to make them "donations" over "payments" because a donation is an after-the-fact gratuity for what was done, where as a payment means a defined stipend for desired services.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/reicast/reicast-emulator/issues/1148#issuecomment-396357690, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYAMtYTcF7Ur26iF-NZU_5Gbg9VbbLmks5t7sQngaJpZM4T3kp7 .
-- ~skmp
-- ~skmp
(ahh comment was outdated on my inbox, will re read and reply more thoroughly)
It is basically the same thing with better spacing and the added comment on bounties redirecting focus. I think you got the same idea.
that’s why i used a cla and not caa. The authors keep copyright, i only get a license.
Re legal entity - that’s why i want a non profit form, they have very strong legal requirements around openess of financial data and internal discourse which i think is a fair shield from adverse actors
Also, just to point out, there are various private versions of nullDC that would be much better starting points for me for a commercial product and without any of the licensing complications. While reicast is highly optimized for armv7, armv8 is where it is at right now, and doing an armv8 jit from scratch isn't that much of effort.
I'm not thinking or planning to do that, and redream is a much better match for any company that wants commercial licensing right now anyway. Just further pointing out there's no good reason for me to be a bad actor in reicast's development.
Personally, I trust you. It's good to put that out there, though. Hopefully it can help to ease anyone else's doubts about the purpose of everything (or at least be a reference if it comes up)
Reicast open beta #1208 is now public. https://github.com/reicast/gamedb/issues now hosts game and hw compat bug reporting and tracking. http://forum.reicast.com for first level support (either running or compiling), and general discussion. Github discussions and ticket tracking for team coordination. We also have a testing team. Still loads to do.
Working on code of conduct (gh discussion link here?)
Should also get an update for 1st of August.
Closing in favor of #1389 A review for these months could take place
Hello Team,
As many of you probably know, I've been thinking of setting up a legal entity/non-profit over the past 3-4 years to handle donations, expenses, contributor sponsorships and such. Overall the rough research has been completed, and I'm looking in the non-profit forms of ggmbh, or non-profit cooperative, both under Swiss Law. We need to decide on who wants to be part of the legal entity. It will revolve around the concept of http://emudev.org. Any takers?
I still don't have the green light from nv, and I hope to get it soon. Preliminary advice from my union is that it should not be an issue. Let's hope that proves true.
Just to clear up things I want to note that this effort is separate from @inolen's work in redream. Redream is a separate project, and while me and inolent have discussed dc stuff a lot and exchanged notes in the past, to my knowledge it is not based on reicast or nullDC. I also want to make clear that @inolen's decision to close the source is totally fine by me, and I think the way he handled the transition was fairly smooth, considering there were no major 3rd party contributors.
The reason reicast is a separate project is that unlike redream, I (we?) am(are?) not interested in a customer-centric approach, and prefer to work things out via donations and the open source path. That's why I(we?) am(are?) also aiming for MIT license in the future.
I (We?) do look forward on colaborating with @inolen and other members of the redream team in whatever fronts it is possible, and I fully trust them that any information they discover will not get lost in the mists of time. I also had a short chat w/ @inolen today, and we discussed timing our next releases together, as a sign of unity :p
We also need to update the team roles. I'm not sure if @dmiller423 wants to still be part of the CORE team, and I'm not sure if anyone else wants to join (@LoungeKatt ?). As part of the core team there are some more responsibilities (time wise, code of conduct wise, etc, and there's a lot of work to do). I also like to meet members of the core team face to face or at least videocall as that adds an extra layer of trust.
I think that's all for now
How does that all sound?