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 .idl/ .proto files.

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.

For Europe

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 omniIDL generated 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 .proto file, 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.

  • There was a court case Oracal vs someone. Oracal claimed there was an infringement, Other claimed that interfaces can not be copyright. Other won. Oct 4, 2017 at 8:32
  • I think the two licences say the same think (ish). As the licence for the compiler can not change the licence for the input. Imagine a command copy / cp with these licences. What would this imply? Oct 4, 2017 at 8:35

1 Answer 1


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

My take is that the files generated are derived (and generally considered derivative works) of the input used for generation. Which generator you use has little bearing on this (unless there is also significant addition to the output as part of the generation process).

This is the case when you compile a binary from source code. Compiling some alternative format through some other generator would be the same be it IDL or else.

So I would treat the output of such generation to be under the same license as its input in the general case.

  • Thanks. Glad to see someone seeing it the same way as me. :-)
    – Martin Ba
    Oct 2, 2017 at 17:35
  • @MartinBa I have never seen anyone have a different view on this topic. If this were different, then you pick any license you like when generating some binaries from some sources.... Or transforming some binary would allow to escape the original license ;) ... but it does not, does it? .... Now that said, I posted a quick answer and I will need to reread your question in details Oct 3, 2017 at 1:26
  • Actually I stand by my response: unless the generator adds significant bits to the generated output, the output is derived from the input and rarely if ever "owned" by the generator. Oct 3, 2017 at 1:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.