On 8/3/12, Greg Stein <[email protected]> wrote: > On Fri, Aug 3, 2012 at 12:27 AM, Olemis Lang <[email protected]> wrote: >> my comments below . Please recall that I'm not an expert neither in >> the art of licensing nor in ASF best practices and standards . > > No worries. You've got myself as the first stop, and then the rest of > Foundation as the second stop :-) >
:) >> On 8/2/12, Greg Stein <[email protected]> wrote: >>... >>> * remove LICENSE/NOTICE from bloodhound_* subdirs. just the top-level >>> dir is proper. (and maybe generally simplify; eg. why CHANGES in >>> bloodhound_dashboard?) >> >> Even if Bloodhound is distributed in a single file (tarball) it is >> developed in the form of a set of plugins . bloodhound_* folders >> contain source code for each one of them . License files are in there >> because it makes sense to checkout only that particular subset of the >> code in svn repos , build the corresponding plugin, install it and use >> it . Indeed it's also possible to build packages for each plugin and >> distribute them . >> >> Is this a reason good enough to keep license files in bloodhound_* folders >> ? > > Nope. > > The LICENSE/NOTICE files are for releases, not for checkouts from our > repository. By your logic, there would be a LICENSE/NOTICE in *every* > subdirectory because people could check out anything. > I understand your point , but according to my reasoning that's not the case but ... > It is important to make a distinction here. If somebody checks out > files from our repository, that is NOT a release. The ASF is not > standing behind it as a release. The important work of the Foundation > is when we make a release. And the *only* release that this project > will make is the entire bundle (unless I'm horribly mistaken on the > community goals here). Since the plugins will not be released > individually, they exist merely as an architectural convenience. The > *release* is trunk/ and that is where the LICENSE/NOTICE files should > reside, and then be delivered in the resulting tarball to the users. > ... after reading this I see there's no point in following the discussion . It's clear to me now . Thanks >>... >>> * would also be nice to indicate what release/revision of Trac is >>> incorporated into this release, >> >> for Release 2 (... or maybe later) we have to work on this direction. >> We need to know that information in code as well . Right now it turns >> out that the revision number in the footer represents changeset ID >> corresponding to ASF repos rather than Trac's . My initial suggestion >> is to update footer with something like >>... > > Sounds good! > ;) >>... >> My second suggestion is to include in trunk a file named TRAC_VERSION >> containing the version, changeset ID, ... of Trac code committed in >> vendor branch . > > This would be great. Details TBD, and I don't really have any input > for the dev community. > ok . that's to be continued in a separate thread >> NOTICE , LICENSE and other files will only need to >> mention that file (<= I'm hoping we can do that). > > There is no need for these files to refer to a proposed TRAC_VERSION > file. It is sufficient to state "portions developed by..." (as they do > now). > I said so in order to say something like this in e.g. NOTICE file . "A modified copy of Trac is included in this source release package. Exact version of Trac may be found in TRAC_VERSION file" ... etc , etc .. >>... >>> along with a notice that local patches >>> have been applied. >> >> +1 ... and if current modifications need to be mentioned then maybe a >> link to (or a copy of) aforementioned (non-existent) wiki page (i.e. >> http://issues.apache.org/bloodhound/wiki/Patches) may be included as >> well > > Trac's BSD license does NOT require any mention of changes. We do it > because we're nice :-) ... not to mention that users may need/want to > know that information (like I wondered when reviewing the tarball). > Exactly ! [...] -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
