Hi, On Tue, May 10, 2022 at 09:53:05AM +0100, Daniel P. Berrangé wrote: > > > * License > > > > > > While the generator (golang.py in this series) is GPL v2, the > > > > I'd make it v2+, just to express my displeasure with the decision to > > make the initial QAPI generator v2 only for no good reason at all. > > Our policy is that all new code should be v2+ anyway, unless it > was clearly derived from some pre-existing v2-only code. Upto > Victor to say whether the golang.py is considered clean, or was > copy+paste in any parts from existin v2-only code
Should be fine to consider it v2+, the generator. > > > generated code needs to be compatible with other Golang projects, > > > such as the ones mentioned above. My intention is to keep a Go > > > module with a MIT license. > > > > Meh. Can't be helped, I guess. > > This does make me wonder though whether the license of the QAPI > input files has a bearing on the Go (or other $LANGUAGE) ouput > files. eg is the Go code to be considered a derived work of the > QAPI JSON files. GPL does not enforce that the generated code to be GPL [0] unless the generator copies GPL code to the output. My only concern has been the fact that I am copying the documentation of QAPI specification to the Go package in order to have data structures, commands, etc. with the information provided by the specification. [0] https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLOutput > I'm not finding a clearly articulated POV on this question so > far. I don't find it trivial either but I've accepted that the Go data structures are fine based on [0] and the documentation can be split from the Go module (sadly!) if someone finds it to be a legal issue. Cheers, Victor
signature.asc
Description: PGP signature
