Hi, everyone :)
I would like to choose #2 with additional comments on it.
Generally, we do use tools to do something quickly or not to add human-errors.
Meaning, a tool is nothing a logic which helps us to create something we need.
Therefore, I think we need to more focus on for what reason this tool is being
used.
The purpose of this tool to generate a set of codes which represents the
resource model
that control manager(IoTivity Service) uses.
So I think the syntax or structure of the resource model that this tool
references
to generate a set of actual codes should be the main topic to discuss, but not
the tool.
But then, since the tool is not for pulbic use, we need to provide the
information about
that resource model to application developer so that they can understand,
modify & use
it in a proper way.
And even though, we decide to use that tool by default, it is us to check the
code whether
newly generated a set of code by tool is backward-compatible or not.
In conclusion, I?d choose #2 with providing information of the resource model
that control manager
uses. And making that tool a public one, or contributing a new tool which
supporting
identical code generation feature & etc are another problem.
(Need to exclude the tool from the project by default, however, I will leave
the decision for people
in this mailing list to make or for Uze at least :) )..
Thank you.
Jay.
PS. Personally, the resource model of Control Manager is very useful and can be
a good
reference model for IoTivity resource model.
> 2015. 1. 26., ?? 9:05, Thiago Macieira <thiago.macieira at intel.com> ??:
>
> On Monday 26 January 2015 10:59:53 Stephane Lejeune wrote:
>> Who is(/are) the final author(/s) or right holders of the generated code?
>> (Does the tool owner become inadvertently a contributor ... )
>
> It depends on the tool.
>
> Usually, the output of tools bears the same licence as the original source
> code it processed from.
>
> Unless that tool copies part of its own input code to the output, like bison
> or yacc do. If that's the case, then copyright and licence from the tool
> itself apply to the generated output too.
>
> Needless to say, we'd rather avoid the latter case.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
