Check Extension Licenses

[ivargrimstad]

Go through the contributed extensions and verify that they have a license that is compatible with ASLv2.

[chkal]

You are referring to the dependency on the 3rd party template engines, correct? So actually we have to check the license of all template engines for which MVC view engines exist, correct?

[ivargrimstad]

Yes, if we package them together in the Ozark deliverable. This is definitely something that will be checked by the IP-team if/when we transfer to Eclipse.

A solution for potential non-compliant view engines is to extract them to a separate extensions project with appropriate licensing

[chkal]

What about provided scoped dependencies? During one of my pull request reviews I asked myself, whether having provided instead of compile scoped dependencies for the template engines would make more sense. Users would have to add the dependency explicitly, but they would also have more control over the exact version and updating would be easier.

So would that have any impact on the license requirements? Any idea?

[ivargrimstad]

I have to check up whether that makes a difference. Anyway, I think that if we provide the view engine, we should also provide the implementation with a specific version that we have tested it with. Letting the users do this themselves just adds complexity and lead to errors.

[chkal]

Ok! I'm not strong on the idea of using provided scope. It just came to my mind as an alternative. I'm fine with leaving it as it is. But maybe it could be a valid workaround if any template engine has a problematic license.

[ivargrimstad]

Extensions:

• - asciidoc - Apache-2.0
• - freemarker - Apache-2.0
• - handlebars - Apache-2.0
• - jade - MIT
• - jetbrick - Apache-2.0, BSD (antlr 4)
• - jsr223 - BCL
• - mustache - Apache-2.0
• - pebble - proprietary license?
• - stringtemplate - BSD (antlr 4)
• - thymeleaf - Apache-2.0
• - velocity - Apache-2.0

[Daniel-Dos]

Hi @ivargrimstad ,

In site - >pebble/license , really seems to be a proprietary license .

In link -> jetbrick-template informs that it is about the apache license.

[chkal]

@ivargrimstad So Jetbrick may be problematic because of the transitive antlr dependency?

[chkal]

Just a quick note on this. If we find incompatible license in our dependencies because of 3rd party view engines, we should most likely drop them before moving to EE4J. We can still keep them alive in a separate GitHub project if we want.

[ivargrimstad]

Let's wait and see. The CQ team at EF will do a pretty thorough job going through it when we transfer the code and they're much better at doing that than we are I guess...
Then we can omit whatever doesn't meet their requirements.

[chkal]

Ok, sounds great!