for another thing, the asf *does* have a higher standard: we require transfer of ownership and ip. it makes perfect sense to me that a company may be willing to transfer those to the asf, but *not* be willing to throw them into the open -- which is the potential if the code is exposed before the acceptance and transfer.
Well, this worries me some more. The simplest thing a company could do to meet the requiremet is put the code on their own site as a downloadable tarball. In such a scenario, the company can elect whatever license they'd want, Apache or otherwise; and they'd call themselves the copyright owner. The only risk to the company in doing so, compared to giving it to Apache, is that any third-party claims others might make (based on copyright, patent, or trademark) would be against the company, rather than to the ASF. If a company isn't willing to put the code base out themselves under their own ownership, but would rather it be (C) ASF, that leads me to wonder about what liability the company is attempting to avoid by doing so. It may be paranoia, but seeing a company willing to put the code out under an open source license with a (C) to them does a lot to quell concerns about whether the codebase is IP-clean. We're not a code-laundry, and I don't want to even allow for the possibility that we might be abused as such.
On Mon, 12 Jul 2004, Leo Simons wrote:
One of the key requirements is that there's enough people interested in a project and willing to help. Ensuring that will usually be very difficult without making code available, but not always. Consider geronimo. There was no code, but we accepted it anyway (IIRC the board did, even). Good decision.
Not strictly true, there was a lot of pre-existing code, and it was the quality of that code that I think excited a lot of people about the project.
On Mon, 12 Jul 2004, Noel J. Bergman wrote:
That said, if there are ASF Members who want to incubate a project, I would prefer that we give them a chance to succeed, even if the endeavor ultimately fails. I don't share the concern that "it's code that the ASF will become responsible for maintaining." I don't see that we have an obligation to maintain a failed project, although I would put the CVS tarball in the archives, or preferably just do an svn remove, as an audit trail. Nor do I believe that there is any requirement for the Incubator to expend extraordinary efforts to make a project successful beyond that which ASF Members are willing to contribute as mentors.
To be clear, the ASF takes a legal risk with every line of code it publishes to the public. Projects that go quiescent are a liability; as are failed projects. There's also a PR problem for the ASF if there are too many failed projects. So some care should be taken in deciding what to admit into the incubator; less so than to graduate, of course, but care nonetheless. We should probably also do more active garbage collection on established projects, but that's another topic for somewhere else...
An IP pre-review could cause a problem. IP made available for review would have to be free of encumbrances. We do not want a situation where people who have reviewed it become tainted. Certainly that can be the case if the license were a proprietary one, but it does not seem to matter if the license is an OSI-approved one or not. Claims can be made based upon (L)GPL as easily as upon more classically recognized proprietary licenses. So, no, I do not agree that "any legal mechanism that provides for anyone in the community to conveniently read the source should be acceptable, even if the license restricts distribution, for instance."
Good point; that suggests the requirement be to be very clear that review of the code places no encumbrances. This could be as an additional freedom granted above and beyond the (L)GPL, so it doesn't have to be Apache licensed.
Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
