On Tue, Aug 9, 2016 at 3:52 PM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > >> If you're asking why adding ALv2 header is against the letter of the >> policy, the answer is simple. >> Quote: >> "3. Do not add the standard Apache License header to the top of >> third-party source files.” > > In the case when they are not actually ALv2 licensed. It assumed that any > files that is APLv2 license would already have a APLv2 header.
Well they are not. They are available under the PostgreSQL license overall and *may* have originated under a different (but still very much compatible with ALv2 -- so no alarm bells ;-)) license. >> Because I actually don't know what the original license on the file is. > > That should ring alarm bells. Why? It would be perfectly fine for PG project to include, lets say an MIT source code. MIT is a compatible license. Whether the fact that the code was originally licensed under MIT is reflected in the header of that *particular* file is an open question. That's why I don't feel comfortable putting the overall PG licensed header there on my own. It may not be, strictly speaking illegal, but it makes me uncomfortable. And since the NOT putting it there has no downside (aside from making scanning a bit more complex) I'd prefer for the file to remain unmodified. >> IOW, I can't add ALv2 header because of #3 on the policy > > No you can’t add ALv2 because you don’t know that the file is licensed under > ALv2. I think we're talking slightly past each other -- I told you I do KNOW that they are licensed under the different ALv2 compatible license. > Given the age of some of the files (predating when ALv2 was created) it’s > very likely that they are not. Again, no reason to speculate -- we do KNOW what the overall license on these files are -- that is PostgreSQL license. We may not know what the original license on each individual file was, but we do know that it was compatible with the PostgreSQL license. >> I think documenting it in LICENSE should be enough, no? > > Yep that’s one one of doing it. Again I don’t thing everything has to be > solved for the next release, > but documenting the issues/what may be missing is probably the best way to go. Sounds good! Thanks, Roman. --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
