Hey folks, On May 14, 2009, at 11:28 AM, Vincent Siveton wrote:
Before dropping the war, I would like to hear our mentors (or members) about the release state and what's going (so) bad.
The rule you're running up against at the moment is not so complicated: all official ASF release artifacts (files) must have a top-level LICENSE file containing *all* the license info that applies to all the things inside that release, *and* a top-level NOTICE file containing all the legal notices that apply to all the things inside the file that is downloaded by the user, *and*, if applicable, a crypto export notice in a README file).
Complying with the rule is also not really all that complicated, it can just be a lot of work if your releases contain a lot of non-ASF IP. The binary shindig releases include a lot of non-ASF IP in the dependencies, so there's indeed a whole bunch of work to do.
Just about every project that goes through incubation has a lot of pain the first time they attempt to do a release -- many engineers just aren't used to paying quite as much attention to details of licensing as the ASF requires of them, so there is a bit of a backlog to dot the i's and cross the t's. Fortunately, once y'all get used to paying attention to this stuff there will be less of that backlog, and releases will be much easier to do.
While you could of course opt to just do a source-only release, or a binary release that doesn't include the dependencies shindig needs to run, that just means shifting burden to your users. I'm one such user and I know I'd really prefer to get a ready-to-run proven-safely- licensed asf-sanctioned binary!
On May 14, 2009, at 11:28 AM, Vincent Siveton wrote:
2009/5/13 Ian Boston <[email protected]>:3. Maintain a separate NOTICE, LICENSE and README for the war, manually, listing all licenses of all jars contained within the war. (39 jars at thelast count) 3 will become an unpleasant burden to the release process.
It ought to be possible to mechanize (though not fully automate) a lot of that work, though.
Its also a lot easier/less annoying to do this legal-doc-management work if you get into the habit of doing it early on . Whenever you change your pom.xml to pull in a new dependency (or a new version of a dependency), check the licensing info on that dependency and update your NOTICE, LICENSE, and README. At that point in time it should be relatively easy -- you should already be paying attention to that stuff every time you commit something!
Similar advice applies to things like source code license headers and such - if you get them right the first time, you don't have to spend a lot of time fixing them when you want to make a release.
Good luck with these last few hurdles!! cheers, - Leo
smime.p7s
Description: S/MIME cryptographic signature
