Hm... shouldn't it be populated?

Umm, this is the template for the boilerplate that should be added to licensed files.

This makes me think that it may be more complicated to apply the license than just adding the text file, if we manage this, we should also ensure that all files have their expected headers.

Maybe a better approach for all this could be:

• Make it part of elastic-package format instead of elastic-package build (but to be practical this may require Introduce new package spec version  #345).
• elastic-package format would add the license file according to the definition in the manifest, and the license headers.
• We would only support a limited set of licenses (as we are doing by now).

It looks to me more like a part of the building procedure:

• you could use data from the manifest to populate the license
• it's more advanced than just formatting.
• user can define their own custom license, store it in _dev/build like docs templates.

But take into account that it is not only about populating these fields, in principle the Apache License requires headers in licensed files, this may be difficult to support here.

Also we don't have enough information in packages now, at least we are missing the copyright owner now, we only have a github handle, for example for the "Apache" package the github handle is now elastic/obs-service-integrations, but the copyright owner should be "Elasticsearch B.V.".

Another option I see is:

• The source.license field is only an indication for package consumers, it is responsibility of package developers to properly apply the licenses.
• Developers may use tools like go-licenser to properly apply the licenses to their work, or do it manually, as they prefer.
  • elastic-package format could be this tool if source.license is set and we add a field in the manifest for the copyright owner. License text could be still included in build time.

user can define their own custom license, store it in _dev/build like docs templates.

In principle we were considering allowing only a limited set of licenses, see the mentions to an enum here and preference over arbitrary text files here.

Or do you mean to include here the template for the headers of the files?

Also we don't have enough information in packages now, at least we are missing the copyright owner now, we only have a github handle, for example for the "Apache" package the github handle is now elastic/obs-service-integrations, but the copyright owner should be "Elasticsearch B.V.".

For such cases, we can assume default field values (for example "Elasticsearch B.V.") to populate the license template.

Or do you mean to include here the template for the headers of the files?

Could you please provide a sample header that needs customization? If we want to support a limited set of licenses, those can be for sure embedded in elastic-package. I'm still wondering if this is something we can render out of embedded templates. Even if we have to add more properties to the manifest.

Also we don't have enough information in packages now, at least we are missing the copyright owner now, we only have a github handle, for example for the "Apache" package the github handle is now elastic/obs-service-integrations, but the copyright owner should be "Elasticsearch B.V.".

For such cases, we can assume default field values (for example "Elasticsearch B.V.") to populate the license template.

How would we support external developers (community, partners...). Or we delay this by now?

Or do you mean to include here the template for the headers of the files?

Could you please provide a sample header that needs customization? If we want to support a limited set of licenses, those can be for sure embedded in elastic-package. I'm still wondering if this is something we can render out of embedded templates. Even if we have to add more properties to the manifest.

With customizations I mean here for example filling the placeholders in the header for the Apache license.

How would we support external developers (community, partners...). Or we delay this by now?

Yes, as we want to start with a predefined set of licenses, I meant postponing the community area.