Alex, Many of the apparently minor issues actually bear on the legality and restriction of use issues. For instance, some licenses *require* attribution. Distribution of code with that requirement that has no attribution is not allowed under the license. It may be that a podling would be allowed to squeak out a release or two with a disclaimer that the release might be defective, but it really should be remedied.
But I think that the real issue you are highlighting is that there are many ways to comply with the Apache intent. Once upon a time, the Incubator tried to give podlings all the flexibility possible in complying. To do this required that the podlings be educated in a very hazy, somewhat self-contradictory and only vaguely documented philosophy. That proved essentially unworkable. The current Incubator approach is to define one particular way to proceed that fits with the philosophy. This has at least a chance of being documented. But it is important for the IPMC to never forget that it is only one way and variations will probably work almost as well. It is also really important to remember that trying to express that potential flexibility is potentially a disastrous approach in terms of helping projects get to TLP easily and effectively. Even just having long discussions about what can work is likely to cause huge amounts of confusion. On Tue, Jun 11, 2019 at 1:20 PM Alex Harui <aha...@adobe.com.invalid> wrote: > The "legal shield" has been brought up by others as the reason for being > so strict on policy compliance, hence my questions. > > My takeaway from your responses is that the key factors are: > 1) legal right to distribute. > 2) no downstream limitations on field of use. > > which I agree with and see no reason to change it. However, that implies > that other policy compliance issues (missing source headers, > not-quite-right handling of LICENSE and maybe NOTICE) are not showstoppers > and can be addressed in a future release, and that would save time not only > for podlings, but for TLPs as well. > > Then the main decision point for this thread is whether to allow podlings > more slack on #2 given their artifacts are appropriately labelled and > disclaimed. > > Could an incentive be offered to podlings that if their release complies > with both #1 and #2 that they can remove the -incubating label when copying > the artifacts to dist.a.o? > > Thanks, > -Alex > > On 6/10/19, 11:13 AM, "Ted Dunning" <ted.dunn...@gmail.com> wrote: > > The content of a release and the downstream limitations on field of > use are > not a matter of legal shield. It has always been the case that the > fundamental promise of Apache has been that Apache software is easy and > safe to adopt and use. > > Easy and safe meaning that you won't have nasty surprises like somebody > suing you for "being evil" or, worse, having your own lawyers veto a > critical release because a dependency of a dependency is GPL licensed > or is > restricted from being used in anything that competes with smart > plumbing > accessories. > > Getting the foundation to relax that attitude of no downstream > restrictions > is going to be nearly impossible. > > On Sun, Jun 9, 2019 at 10:53 PM Alex Harui <aha...@adobe.com.invalid> > wrote: > > > There's been a lot of discussion on relaxing requirements, but I > don't > > recall any long-time ASF person explaining how fragile or durable the > > legal-shield and the insurance rates for it are. > > > > ... > > > > Unless someone can explain why that would ruin the legal-shield or > raise > > insurance rates, I think that would save lots of community time > getting > > releases out. Otherwise, we might be expending precious energy > > overzealously trying to protect a legal-shield that doesn't need > that level > > of protection. > > > > Does anybody truly know what will and will not ruin the > legal-shield? I > > have to imagine that releases have been shipped by the ASF and later > found > > to be non-compliant with policy and that didn't ruin the legal > shield or > > raise insurance rates. > > > > >
