See further below for an unfortunately trimmed thread. A couple paragraphs that I wrote early-thread are important to add:
---- Option (F): stop calling them official ASF releases, which means PMC votes are not required. ---- > In that case voting would not be required and they wouldn’t have to follow > ASF policy. Right. > If they are not official releases then we probably can’t release or > distribute them on ASF infrastructure. I see no problem with using our infrastructure to distribute F/OSS materials. Why would the Foundation want to be against that? If it is labeled properly, then ... roll with it. We distribute a *ton* of stuff that wasn't produced by the ASF. We incorporate that stuff into a larger work, but it isn't "ours". Yet we put it onto our servers. Clearly, these bits and bobs and blobs *are* intended to be F/OSS. Maybe somebody thinks a LICENSE file isn't correct, so maybe ACME Inc. can't use it ... but John and Jane and Joe certainly want to, and *can*. Isn't that our goal? ---- I see no problems with the purported "risk" mentioned below. Would some mis-licensing occur? Likely. Is it material to the Foundation's mission? Nah. What if something appears on our servers without a clear F/OSS license? Does John or Jane care? Nopes. But we fix it in a future release. Move along, everybody is happy. I'd like to see the IPMC get out of the way of the podlings' releases. I see no reason for us to be a gate, and many more reasons to back off and let podlings get their work done. Cheers, -g On Sun, Aug 11, 2019 at 7:46 PM Greg Stein <gst...@gmail.com> wrote: > On Sun, Aug 11, 2019 at 6:32 AM Justin Mclean <jus...@classsoftware.com> > wrote: > >> Hi, >> >> > I see no problem with using our infrastructure to distribute F/OSS >> > materials. Why would the Foundation want to be against that? If it is >> > labeled properly, then ... roll with it. >> >> It often isn’t labelled properly. There’s a reasonable risk that some of >> what would be placed there and distributed isn’t actually F/OSS. > > > And what would be the blowback of something on our server with incorrect > information? Very little. Mostly, we'd just move on. Maybe we delete it. > > >> I can point you to several example of this. I’m not sure how the >> incubator (or the board) would feel about that risk, so that would be >> something we would be need to consider further. Also > > > Welp. Then I will pose that question, rather than this endless > pontificating about "risk". > > >> while Jane and John may be fine with that, a lot of companies that use >> Apache releases may not be. >> > > I already acknowledged that. Many people could use software regardless of > its licensing. The license typically only matters in *redistribution* > scenarios. Things like the AGPL affect *usage*, but that is very, very > atypical. I'd think 99% of downstream could use our software, even with > gummed-up licensing. > > >> > You're conflating *learning* with *releases*. These can be handled >> separately. >> >> How exactly? > > > You're saying that releases are the control point to learning. I say just > let the releases go. > > You want to teach? Then you can use the releases like "that wasn't good. > next time: do A and B". Over time, releases will get fixed. But the IPMC > should not have to manage the releases. > > Cheers, > -g > >
