Is stub code generated from an IDL file or a protobuf definition file a derivative work?
This has come up recently in a developer discussion between several partner companies.
We use a CORBA IDL file with omniORB, and the file itself has license X from a german company.
We also use a protobuf
.proto definition file, and this file has license Y from a german company.
The omniORB IDL compiler states in its license:
All parts of omniidl are licensed under the GNU General Public License, available in the file COPYING.
... we do not consider the output of the back-ends we distribute to be derived works of those back-ends. You may therefore use generated stubs with no restrictions.
The protobuf compiler states in its license clarification:
... Code generated by the Protocol Buffer compiler is owned by the owner of the input file used when generating it. ...
So as far as I can see, both tools seem to waive any copyright to the files they directly generate.
The question that is still unclear now is whether the generated source processing/messaging stubs are to be considered derivative works of the corresponding input IDL / message definition files, and what copyright license they fall under wrt. to the original
Given the other answer here - Is the code generated from a GPLv3 EBNF grammar a derivative work? - it seems the US copyright office would assign the same copyright to the generated output source code than the input definition.
However, we operate in the EU, and most companies in this group are from Germany: Is there any known ruling/rules wrt. generated source code for the EU / Germany?
And, yes, one developer actually asked their company lawyer, but I don't believe the answer, because this lawyer stated that:
- the output of the
omniIDLgenerated files is "owned" by the generating entity, because the IDL compiler states "use generated stubs with no restriction",
- but the output of the protobuf compiler is "owned" by the owner of the
.protofile, because the proto-compiler license states "is owned by the owner of the input file".
The case is that the group would like to open-source (MIT-style) a few tools based on the mentioned definition files, because that would ease collaboration quite a bit. We're now trying to determine whether the input files would also need to be under an MIT-style license to do this.