It's hard to do business with unknown people. That's the case here from possible donnors/patrons to Riley and vice-versa. It's much easier if there's a trusted intermediary.

Riley Baird:

I'm very glad that you're interested in free software. I support commercial development of free software. However, I think that you're misguided in the way you're raising funds for your work. The main problem with publishing a binary-only ISO image is that it doesn't respect the user's rights (The 4 freedoms), in other words, it's proprietary software. Additionally, from what I understand, users can't verify that the system you offer works as intended from the binary ISO image, since it doesn't includes source code or can be installed, it's incomplete, and hence can't be checked. With Linux-libre you can see the scripts that have been used to deblob and check whether any blob remains, which isn't possible with the published LibertyBSD image from what I understand.

I would be glad to see that you succeed in commercially contributing to free software, without distributing proprietary software. I propose a means that I think you can use to raise funds for your work more effectively, and reduce the uncertainty that some people interested in LibertyBSD may have of being scammed:

Stop distributing the binary ISO image.

Further donations would be made to a Bitcoin address overseen by an escrow composed by members that you and the free software community generally trusts[1] while the following process is undergoing:

Make a written specification in which you describe at depth what you offer. Here's an incomplete list of questions that the specification should answer, in my opinion:

Does LibertyBSD meets the GNU FSDG to the best of your knowledge? If not, on which point is it not compliant?. Bear in mind that there may be recommendations of proprietary software scattered in free programs, did you made an effort to remove them?.

what system it's based on (OpenBSD version, patches applied, and additional software included, if any)?

What is the difference of features? I see that you already mentioned that it works only on x86-64 in the project page, but an complete list is better.

What's the software that was included/removed/modified? For modified software, how many lines were modified[2]? Are all of those changes of your authorship?. Under which license are they released?. This is very important, as it gives interested parties an idea of how much work was done.

Was the system rebranded? If so, which packages have been modified for rebranding?, and also include a sample of the artwork.

In my proposal, you would make such a specification and publish it for a public comments period in which people may ask whether LibertyBSD does something that you haven't specified, or suggest clarifications of your specification; you would then modify the specification at your sole discretion given this feedback (or chose to ignore all feedback). The point with this is that you have an opportunity to clarify doubts and arrive at a specification satisfactory to you and the possible donnors or patrons.

After the comments period, if enough money was sent to the escrow address, you would send the final version of the specification (which would be public) and the complete LibertyBSD (As would be published) to an escrow. If not enough money has been sent, then you have the option to wait until all the money you originally asked for is raised before submitting LibertyBSD to the escrow, or send it anyway to the escrow

At your option, you can publish and timestamp a cryptographic hash of the submission *before* sending it to the escrow. This make is less likely that the escrow will cheat, since you can prove that you had the submission before they did. They can't rebrand LibertyBSD and successfully claim that developed it, for instance.

After receiving LibertyBSD, the escrow evaluates whether it meets the specification, and if so, releases the money to you, otherwise, if it contains minor problems you'd have a period of time known in advance to fix them (14 days for example). In case you failed to meet the specifications within the allowance period, the escrow returns the money to donors, or sends it to another end, chosen in advance (for instance, the Free Software Foundation).

Of course, the escrow must be a non-empty set of people who free software supporters generally trust, you trust, would be willing to offer his work as escrow and know enough about OpenBSD to perform this evaluation.

The Bitcoin pay-to-script can be used to make sure that a minority of the members of the escrow can't cripple the process by requiring the signature of more than half the escrow members to act on the money. I think that it may be possible to additionally make the Bitcoin address correspond to an script that allows the received money to be released only to you or the FSF (for example), but not to any other Bitcoin address.

Doing the fundraising this way gives more confidence to the interested parties while making it less likely that either you or the escrows will defraud, while it avoid the problem of publishing a proprietary version of your work that doesn't accomplishes the goal of proving that the system works as intended.

This proposal is incomplete, some points require opinions and further thought, and must be made clear before the process begins. An incomplete list is: Which people would act as the escrow? I ask the community to state their opinion, and to offer to volunteer as members of the escrow, especially to those who have contributed to free software already. What would be the public comments period and the allowance period? I suggest 30 days for the former and 14 for the later, but I suggest to start the fundraising on 2015, since the FSF is currently running an fundraising campaing and some people who want to donate to free software may split the amount between to only one of LibertyBSD or the FSF (possibly giving zero to either, which is less efficient for both projects). What would happen to the funds if you fail to meet the specificaion in time? I suggest that in such a case, the funds should be donated to the FSF, since that way the effort of collecting funds isn't wasted. What would be the exact Bitcoin script?. I don't have much experience with this, so I can't give a suggestion on the details of it.

All of this must be agreed in advance. Riley: If you agree to this proposal please state the specific terms on which you agree to it. I recommend waiting until some interested members give their feedback before you deceide on which specific terms to accept the proposal.

Thanks to Jason Self (jxself) for his feedback on this proposal. I made some modifications accordingly before posting.

[1]: I said “generally trust” rather than “trust” because given that the set of free software supporters is large and uncentralized, it's not possible to say something for sure about them regarding whom they trust, so I don't want to imply otherwise.

[2]: Not counting aesthetic changes such as formatting, and provided that they're coded as common practice. You should state in your specifications that the changes follow “common practice” in the sense that you didn't split what normally would be a single line of code in as as many as possible (one per character) or similar to artificially increase the modified/added line count.

Reply via email to