mirabilos

Vladimir Sitnikov dixit: >> hence the licence analysis for >>everything shipped and the reluctance to place binaries in the repo > >I have never seen a case when build instructions...

Vladimir Sitnikov dixit: >It might be "use current Java if its version is good enough, or >fallback to downloading if no java detected or java version is >incompatible". Or “error...

Kirill Gavrilov dixit: >> What do you think of PDF or ODF files in the repository? >> Those are binaries as well. > >I think that's not good idea to...

Vladimir Sitnikov dixit: >Here's a recent comment by Cédric Champeau which lists key requirements >and ideas behind Gradle Wrapper: >https://issues.apache.org/jira/browse/LEGAL-570?focusedCommentId=17346632&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17346632 I personally disagree strongly with that. But let’s play along...

Vladimir Sitnikov dixit: >I doubt it is worth splitting gradle wrapper development in its own >repository That’d not be good. No, but you could generate a wrapper sources JAR during...

Vladimir Sitnikov dixit: ***@***.*** , could you clarify what do you mean by "sources"? > >Do you suggest that build scripts should be included? Ideally yes, but we don’t get...

Well, for all files ☺ it’s just that nōn-text files often don’t contain legible copyright information, if there is any provenance documentation at all (I also look at commit messages)....

Jonathan dixit: >I think in practice as @mirabilos says we can assume non-text resources >are inheriting the licence we have in the repo, and that they had the >necessary status...

Yes, e.g. GNU autoconf copies the Makefile (with substitutions) and everything else needed, and in general just points to the source directory.

Simon Ser dixit: >I'm not talking about autotools, I'm talking about other software using >raw Makefiles like we do. It’s not about the Makefile, it’s about the configure script.