Binaryen: Consider moving binaryen (and other tools) into a different org

[wycats]

Per @jfbastien, I am opening a separate issue to discuss possibly moving binaryen (and other wasm tools) into their own org.

The conversation originally came up in #1340 when I asked whether any of the main contributors to these tools require the W3C's IPR protection (as opposed to licensing under something like Apache2) in order to contribute.

The W3C's contribution process is more involved than other projects, so there could be benefits to pulling these tools out into a more traditional organization.

@jfbastien replied:

To answer your question: binaryen was started early in WebAssembly's history when much of the design was in flux, and it definitely provided significant input to what will become the final WebAssembly standard. I was one of the 4 CG chairs at the time, representing Google, and advice from representative companies' standards folks + lawyers, and W3C folks, was that WebAssembly contributions which affect the design must be under the W3C umbrella and contributors who provide significant input must be CG members. Binaryen fit that description and was therefore under the WebAssembly organization.

Now that the design has settled more we could reconsider and put binaryen as well as other tools under their own organization. For example, the LLVM work now occurs directly in upstream LLVM. It remains true that significant contributions to the standard must come from CG members, but at this point tooling development doesn't influence the design as much as just get stuff working.

So I'm opening this issue to track it 😄

@jfbastien mentioned that this might be added to the agenda for the next CG video call, which I'd quite appreciate.

[kripken]

fwiw, I created this repo, and I don't care where it resides. (not that it matters much who created it)

The only things I care about are

• the code being useful to as many people as possible, and
• as many people as possible being interested to contribute to it.

Might be useful to know if moving the repo would change things either way for someone.

[dcodeIO]

Being part of the WebAssembly org is probably the most effective way that someone discovers it by accident. And then a wild bureaucracy appeared 💥

[jfbastien]

I think reducing code contributor friction is good, as long as the project remains something that people can use without fear of non-technical issues (i.e. having to talk to lawyers). With the W3C we have a solid framework, but most open source projects have also figured out similarly solid frameworks so I'm not too worried.

I do think binaryen will contribute to the CG in the future, but these cases can be handled one at a time, and we can make sure such contributions come from CG members. Does anyone think that extra binaryen -> CG contribution hurdle is a problem? I certainly don't want to add friction to CG contributions.

Another thing to consider is whether we're "promoting" binaryen more than any other similar project. Are there competing projects which don't get as much traction as binaryen, and would it be better for the WebAssembly organization to feature each such project prominently on its website without promoting one more than the other?

Let's also make sure any move doesn't break existing links on the internet!

Finally, where would binaryen live if we were to move it?

[dschuff]

Bureaucracy (although the term I'd use is "lawyers") notwithstanding, I'm curious what you mean by "more involved". There are really just 2 steps:

1. Sign up for the CG (agreeing to the IPR provisions)
2. Contribute.

Obviously step 1 is absent if we pull out of the wasm org. Is there a concrete issue for you, or someone who will be unable to contribute with this requirement? Is it the extra step? Or some unwillingness/unclarity on the W3C IPR requirement vs the bare apache2 license?

I don't have strong feelings about the org per se, and of course binaryen isn't really much different from LLVM which is its own org. although I do wonder if it means we would have to e.g. be careful to only discuss tool development in the tool repo (and avoid feeding ideas from the tool back into wasm itself? but what does that even mean?)

[dschuff]

Oh, I raced with @jfbastien. I guess another way of putting the the only concern I have: how much do we have to worry about transitioning binaryen contribution to CG contribution. Although thinking a bi t more, I don't really think it would have been an issue in practice. Probably the opposite actually, since we don't have to ask people to join the CG to accept bug fixes or whatever. And also in practice if people what to discuss wasm itself we already punt those discussions to CG forums just to ensure that all the stakeholders will see it.

So yeah, I guess I'm not actually too worried about that.
It is a separate question about promoting projects. In some sense we don't want to privilege particular projects (although we, the employees of the browser vendors, do sort of do that anyway by virtue of actually contributing to them). There might be some value to indicating for people on the internet which projects are being actively worked on, and are up-to-date with the proposals, etc, but that could just as easily be done via some list on webassembly.org.

[wycats]

@dschuff I don't want to speak on @krisselden's behalf too strongly, but I believe that step 1 has, indeed, been a contribution blocker for him.

In his case, it's because the process of getting approval for new IPR provisions requires legal approval, and legal approval can drag on.

I don't have strong feelings about the org per se, and of course binaryen isn't really much different from LLVM which is its own org. although I do wonder if it means we would have to e.g. be careful to only discuss tool development in the tool repo (and avoid feeding ideas from the tool back into wasm itself? but what does that even mean?)

Since the current process doesn't require IPR agreement simply to have a conversation that could eventually result in a spec change (but rather in order to submit a patch to the spec), I don't think we would need to worry about conversations that happen outside of this org.

[wycats]

@dschuff now I raced with you:

Probably the opposite actually, since we don't have to ask people to join the CG to accept bug fixes or whatever

That's what I was saying, yeah.

[wycats]

There might be some value to indicating for people on the internet which projects are being actively worked on, and are up-to-date with the proposals, etc, but that could just as easily be done via some list on webassembly.org.

Indeed. We could even just move things to an org like webassembly-tools that would have the same "feel" as today's blessed tools, but without the CG/IPR overhead.

[dschuff]

Since the current process doesn't require IPR agreement simply to have a conversation that could eventually result in a spec change

My impression is that the intent of the process actually is to cover discussion and ideas to the extent possible. This is sort of a consequence of the fact that the actual design of wasm in practice hasn't happened via spec updates but rather design docs, etc. Although now that the process for new proposals is a bit more formalized and actually does involve forking the spec repo, maybe that's less of a concern than it was.

[dschuff]

Oh my other question was, is the W3C IPR more really onerous than the apache2 license requirements? My non-lawyerly impression was that they have similar requirements around patent licensing, so if someone needs heavyweight legal approval from their employer to comply with one, then they might need it for the other too.

[jfbastien]

This discussion makes me wonder if we even need people to join the CG to contribute significantly to binaryen without actually contributing to the design... That would be a question that W3C folks could answer, we might be in uncharted territory. If not then we can just change our PR approval process.

[wycats]

Oh my other question was, is the W3C IPR more really onerous than the apache2 license requirements? My non-lawyerly impression was that they have similar requirements around patent licensing, so if someone needs heavyweight legal approval from their employer to comply with one, then they might need it for the other too.

My understanding from @krisselden is that their lawyers already understand Apache2, so it's an easy rubber stamp, while the W3C IPR is a new one for them. Also, the agreement is about the spec, while this contribution is to a tool, so it was a little ambiguous.

[dschuff]

Seems reasonable. I can bring it up at the next CG video call.

[krisselden]

Definitely caused confusion with my request that it was a PR of code changes and I needed to sign a CLA that is about contributing to the web assembly spec.