Interested in contributing! License?

[jcflack]

Hi!

I like this approach. I'd be interested in contributing.

Has a license been chosen, for the work that's already in this repo? For contributions?

Thanks!

[jcflack]

Hi!

I'm following up on this issue, because I really am quite enthusiastic about this approach. It seems very much like the "right", most Acmeist :), way to go about producing parsers. I would like to contribute and work on some additional target languages.

There is kind of a serious issue of license clarity though. I'll link this issue to yaml/yaml-spec#25 too, because that's kind of inseparable.

Using this approach, any parser that gets produced is going to legally be a "derivative work" of the spec itself. The spec's own license (the wording added in yaml/yaml-spec#95) does not currently say that's allowed. It allows unmodified copies, but a derived parser is a modified copy.

Ultimately, there are three interrelated issues here:

1. What license applies to the tooling that's maintained in this repo (⟶ if I contribute to this tooling, what license do I contribute under)?
2. For a parser that is generated as an output from this tooling, with the spec as an input, what is considered to be the license on that resulting parser?
3. Does the license on the spec itself even allow that to happen?

As to my own preferences ... for (1), well, I've made most of my contributions to projects under the least restrictive kinds of open-source license, like MIT or simplified BSD, but I would also be willing to contribute to this tooling under some other recognized open-source license if that's what the team prefers.

For (2), I think it would be pretty important to say that generated parsers will be usable under the least-restrictive of terms, like MIT or BSD. Anything else, and some projects will be tempted not to use the generated parsers and use something else instead, and that would seem counterproductive for the YAML ecosystem.

For (3), I'm no lawyer, but it seems that the wording in the spec would at least have to say something about algorithmically deriving parsers from the spec, and that such parsers would be usable under (MIT, BSD, or whatever) terms.

Does that better explain what I'm asking about here?