On Wed, Apr 1, 2009 at 7:28 AM, Todd Volkert <[email protected]> wrote:
> 1) I tried but couldn't find definitive info on whether we can > redistribute binary dependencies (System Requirements). I had > originally assumed that we could NOT, so I removed all such jar files > from the released source, and thus, as you saw, the build fails unless > you download those jars yourself and put them on your classpath. I > would love to include them, as it would make the user who's trying to > build from source much happier. As you say, "some people (like > myself) prefer to have them part of the source dist". What's the > official word from legal on this? I know that the jfree stuff is > LGPL, which from what I found sounds like we cannot redistribute, even > in unmodified binary form. Hold on a second here... You may only redistribute Category A and Category B licensed binaries. BUT, just saying that Category X is a System Requirement, may not be sufficient. You can have any GPL'd licensed dependency marked as System Requirement if it to build the system. For instance, you may require the gcc compiler. You may not mark something non-optional as System Requirement that your code directly depend on, rendering the product unusable without it. The exceptions are obvious; Java, Python, Perl and so forth are clearly system requirements, but Hibernate is not, MySQL JDBC driver is not, where as "a JDBC driver" is. So, it is fairly complicated, and I would be happy to give more concrete answers to each individual case. So, let's start; What is JFree and how is it used? > 2) Our NOTICE file is currently blank. Is there anything that needs > to go in there? I think this relates to question 1, in that we might > have to put legal notices of the binaries that we're redistributing in > there. NOTICE contains a single paragraph about each source and binary dependency used in the project, and where that dependency originate from. It would also contain the VMware Copyright notice, and any other individual's work that has been forked. So, license, origin, copyright holder and year (if available) in one paragraph, followed by a blank line. > 3) With the changes I've made today, if a user were to download the > release archive and follow the instructions in > http://svn.apache.org/repos/asf/incubator/pivot/branches/1.1/BUILD to > rebuild the JAR files, they'd end up with JAR files that are > bit-for-bit identical to the ones that came with the distribution, > *except* that the *built* file names would not contain "incubating". > Is this a problem? What surprises me is that you are struggling a lot with this. Isn't just "version" a property in the Ant file at the top, which would be appended to filenames? For this release, I will not make a fuzz over it, and I will try to help out 'hands on' with the Ant script later. > 4) I've uploaded my pgp code signing public key to the MIT key server. > Are there any other servers to which I should upload manually? I was > originally under the assumption that the key would disseminate > automatically, but that appears to have been a bad assumption. I am not very well educated in PGP systems, so I have no clue... > 5) Niclas, you said that "The binary output is NOT included in the > primary release artifact, but is "generated" by it." However, I see > many projects that include binaries in their main release artifact > (again, Wicket is an example). What's the final word on this? It > seems silly to me to not include the binaries, since pivot users don't > particularly want to build Pivot - just build applications that use > it. > 6) You speak of the primary release being source and the supplementary > release being binary, but I see some projects (again, Wicket, among > others) that only release one artifact, which contains both source and > binaries. This is what I was going for here, as I think it simplifies > things. Is that not kosher? Is 5. and 6. same question? Well, I guess it is a balance. I am of the opinion that 2 separate tarballs is preferred, but that could be due to my slow connection to the Internet. If you have a single tarball, then the most important bit is that it can be built to the same state as the in-house built one. Apache is less concerned about the quality of the released artifacts, and only really really care about the legal requirements. So, you have a lot of freedom, incl sticking binaries into the source tarball. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
