Noel J. Bergman wrote:
they _have_ accepted this as a model for distribution management. The wiki is a very different topic.all PMCs whose committers 'commit' to the repository should maintain
some oversight.
Infrastructure hasn't considered that a good model for the Wiki, and I don't know that it would work any better for the repository. Someone needs to take responsibility for the oversight.
The www.apache.org/dist/ setup is something 'conventional', with a filesystem and permission
management and SSH encryption and stuff. It is tried and tested, and perfectly secure (to the extend
daedalus itself is secure).
AIUI, there is currently a "no" on the ASF providing a redistribution point for things like JUnit in theI'm not suggesting we place non-ASF jars online, which
simplifies license issues rather by a large amount.
Yes, that does. But I am expecting that people will want common things like JUnit,
style of a maven repository. At least not a definitive "yes".
which I understand to be acceptable so long as the IBM license is there.
IANAL, but I understand the same thing ;)
yep. So don't drop the binary until you have a) policy, b) desire and c) an ok to make apache intoOnce the binary distinction of ASF v non-ASF is dropped, then the simplicity of it being OK because it is all ASF-licensed code turns into the policing scenario that Maven is currently practicing, through Dion Gillard.
a redistribution point of third-party software. Just b) doesn't cut it.
www.apache.org/dist is the authoritive place for distribution of apache software. It is _not_ currentlyBut using the repository to hold third party jars for which the ASF has specifically ascertained appropriate license rights exist seems to be what gives us the most bang, because it is the third party libraries that are the most potentially time consuming and "risky". Rather than each project have to deal with each third party jar, using the repository for that purpose would both share the burden of acquiring suitable license rights, and ensuring that they were acquired.
intended for redistribution, authoritive or not, of "ASF-endorsed" or "ASF-acceptable" software. Quite
binary, yes (ant it is not something I made up, but what I took away from comments from Dirk or
someone else entitled to make "official" statements).
Changing this setup is something to be done only very cautiously after consulting with the projects
that mirror our stuff and answering lots of other questions. I can see the argument as to why we would
want to do such a thing, but I think it is best to hold this off for at least a month or two even if we were
to decide to do it. Slow & controlled evolution :D
Licensing policy is quite tricky and lots of things need to be done before the ASF should even considerSo, yes, the ASF-only distinction simplifies repository policing, but using it as the central location for authorized third party jars simplifies overall policing of third party license issues for the ASF as a whole.
setting up a centralized easily user-accesible distribution point of materials not copyrighted by the ASF
that can be called "authoritive" either by definition or default. For example, the docs started at
http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made into an authoritive source on
www.apache.org that unambiguously answers "yes" or "no" with regard to
"can we link to software under license X?",
"can we redistribute software under license X in source form and/or binary form?",
"how do we provide these licenses when we redistribute or link to software under license X?",
"what other steps doe we take when we redistribute or link to software under license X?"
and similar questions, so it is crystal clear what we can and cannot include and policy can be formulated
and applied. Something like
http://www.fsf.org/licenses/license-list.html#SoftwareLicenses for the ASL. Until these answers exist and
are well-known throughout the community and relevant PMCs, we need to be as conservative as possible.
Not sure if your project can distribute JUnit? Then don't, even if that makes life terribly inconvenient.
Want to be sure? Ask the board to pour resources into getting answers. But we need to be sure before
we act. I'm sure it is okay for the ASF to distribute jars from its own hardware based on its own
sourcecode under its own license. Yes, binary, but it is the best first step and it solves a real need.
cheers!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
