Hi Dave, It would help to make license problems rare if we also do something else Roy has mentioned recently that has to do with trust and intent. If you dig hard enough, or take an "untrusting" philosophy that if something isn't perfectly documented that someone is going to use that imperfection against you or the foundation, you can continue to find small licensing issues, especially in the third party artifacts we consume.
Roy basically said that folks want us to use the stuff the make available on open source sites otherwise they wouldn't have put it there. They might have slightly different rules about sharing it and modifications to it, but the intent is to share it. So let me add to "better and not illegal" with "trust". Thanks, -Alex On 11/10/17, 10:47 AM, "Dave Fisher" <dave2w...@comcast.net> wrote: >Hi - > >For source code we can point to github from the website. > >For nightly builds we can let people know about it on dev@ but should not >link to it from the website. We can explain on the website or wiki that >we are doing nightly builds and that they can find out from the dev@ list. > >At this point it should be rare to have a license problem in the >repository because we all should know the rules or how to ask on dev@ or >private@ first. > >Clear? > >Regards, >Dave > > > >Sent from my iPhone > >> On Nov 10, 2017, at 10:36 AM, Alex Harui <aha...@adobe.com.INVALID> >>wrote: >> >> Forking this specific issue about nightly builds... >> >> AIUI, this issue about nightly builds has arisen before with other >> projects. I'd have to go through board@/member@ archives but I think >>some >> projects have found some pretty clever solutions to linking to nightly >> builds. >> >> That said, one of the benefits of creating a Royale project separate >>from >> Flex is that there should not be any 'competition' in the release queue. >> For example, the Flex project is currently trying to get two releases >>out, >> and if some other Flex member wanted to rush out a BlazeDS release, >>they'd >> probably have to wait. >> >> Royale has 3 main repos, and under FlexJS/Falcon, we created 2 sets of >> release artifacts. Royale might still have 2 sets of release artifacts >> (compiler, framework), or we could have 3 (one per repo: compiler, >> typedefs, framework), or we could have 1 by bundling the 3 repos >>together. >> And whatever we choose now, we can change later, since some day there >> will probably be a Tour de Royale or something like that. Also, I have >> made changes to Royale release packaging so that they should not be >> dependent on an Installer release. IOW, we have hopefully simplified >>our >> releases (assuming folks are ok with the new ways to get SWF-related >>code). >> >> The main Apache philosophy, AIUI, is simply that the foundation cannot >>be >> telling the general public to download source that has not been vetted >>by >> the Foundation (actually a PMC) as being entirely open source under >> licenses compatible with ALv2. Yes, there are exceptions for Cat B and >> Cat X with proper handling, but that's the primary principle: the >>general >> public must only be consuming things we've reviewed and approved. A >> nightly build simply hasn't undergone that level of review. >> >> Meanwhile, there appears to be distinctions at Apache about user-facing >> and developer-facing "channels". For sure, there is a dev@ and users@ >> mailing list, and there appears to be a notion of user-facing vs >> developer-facing web sites or pages. I haven't found a definitive >> description of the latter, though. >> >> In theory, folks who are reading dev@ have their "developer" hat on, and >> so we can freely discuss nightly builds and where to get them on dev@. >> AIUI, we can even tell an individual or group on Forking this specific >>issue about nightly builds... >> >> AIUI, this issue about nightly builds has arisen before with other >> projects. I'd have to go through board@/member@ archives but I think >>some >> projects have found some pretty clever solutions to linking to nightly >> builds. >> >> That said, one of the benefits of creating a Royale project separate >>from >> Flex is that there should not be any 'competition' in the release queue. >> For example, the Flex project is currently trying to get two releases >>out, >> and if some other Flex member wanted to rush out a BlazeDS release, >>they'd >> probably have to wait. >> >> Royale has 3 main repos, and under FlexJS/Falcon, we created 2 sets of >> release artifacts. Royale might still have 2 sets of release artifacts >> (compiler, framework), or we could have 3 (one per repo: compiler, >> typedefs, framework), or we could have 1 by bundling the 3 repos >>together. >> And whatever we choose now, we can change later, since some day there >> will probably be a Tour de Royale or something like that. Also, I have >> made changes to Royale release packaging so that they should not be >> dependent on an Installer release. IOW, we have hopefully simplified >>our >> releases (assuming folks are ok with the new ways to get SWF-related >>code). >> >> The main Apache philosophy, AIUI, is simply that the foundation cannot >>be >> telling the general public to download source that has not been vetted >>by >> the Foundation (actually a PMC) as being entirely open source under >> licenses compatible with ALv2. Yes, there are exceptions for Cat B and >> Cat X with proper handling, but that's the primary principle: the >>general >> public must only be consuming things we've reviewed and approved. A >> nightly build simply hasn't undergone that level of review. >> >> Meanwhile, there appears to be distinctions at Apache about user-facing >> and developer-facing "channels". For sure, there is a dev@ and users@ >> mailing list, and there appears to be a notion of user-facing vs >> developer-facing web sites or pages. I haven't found a definitive >> description of the latter, though. >> >> In theory, folks who are reading dev@ have their "developer" hat on, and >> so we can freely discuss nightly builds and where to get them on dev@. >> AIUI, we can even tell an individual or group on users@ to grab a >>nightly >> and see if it fixes a bug they've been experiencing or try a new feature >> as long as we use the right words that the nightly is not a release for >> the general public. >> >> I'm not sure how to do the same on a web site. AIUI, the main page at >> royale.a.o is supposed to be a combination of user-facing and >> developer-facing content. It must instruct the general public where to >> get releases, and it must also instruct newcomers as to where to get the >> source code and participate. >> >> But to tie all the above to the subject title, I want to mention >>something >> Roy told me recently. Roy said that for many projects, the criteria for >> voting on a release is "better than the last release" and "not illegal". >> And "not illegal" truly means breaking a law, not whether the release is >> perfectly compliant with some Apache policy. Apache Policy does not >> always support compliance with some law. Much of it is for consistency >> and convenience. >> >> For those of you who have participated in Apache Flex releases, the >> philosophy there was quite different. There was lots of nitpicking done >> at the last phases of the release process. This made some sense for >> Apache Flex as each release was targeted at 100's if not 1000's of >> existing Flex customers that may have had mission critical applications >> relying on certain code-paths. However, for Royale, at least for the >>next >> few years, I think we should adopt the "better and not illegal" >> philosophy. I think that philosophy, combined with fewer release >> artifacts, should allow us to release way more often than we used to. >>And >> that will reduce the importance of linking to nightly builds off our web >> pages. Nobody should really need to look at our web pages for links to >> the nightly builds because they should be following the dev@ list or we >> will be telling someone on users@ to try some nightly and giving them a >> link in the email. IOW, the links to the nightly should just keep >>coming >> up in email conversation, and as long as we are careful on users@, we >> should be fine. >> >> I think I am done with renaming references to Flex in the framework. We >> could cut a release now if we want to, especially with a "better and not >> illegal" philosophy. I am choosing to wait on the release in order to >> finish a major refactoring of the compiler because I saw some folks >> struggle to get the repos to build and because the refactoring is needed >> to remove the last batch of Flex references from the compiler. The >> refactoring is intended to make building from the repos much simpler and >> leave a better first impression for those who try it, so I thought that >>we >> should wait to make "first release" noise until we have smoothed that >>out, >> but I'm fine if we want to ship what we have now. This refactoring >>could >> be at least another week or two of work. Cutting a release with this >>new >> philosophy should be much less than that although I suspect folks may >>have >> feedback on the new packaging. >> >> Thoughts? >> -Alex >> >>> On 11/10/17, 3:24 AM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>> We’re not tied. It just needs to be on a different page to avoid users >>> downloading nightly versions by mistake. >>> >>> There needs to be two download pages: >>> >>> 1. For “normal” users who only want to use stable releases. >>> 2. Framework developers and users who want to use the latest. >>> >>> Right now, we don’t have content for #1. >>> >>> Harbs >>> >>>> On Nov 10, 2017, at 12:31 PM, Carlos Rovira <carlosrov...@apache.org> >>>> wrote: >>>> >>>> Hi Piotr, Justin, >>>> >>>> as Justin, comments, I think we are tied until we get our first >>>>release. >>>> It really doesn't matter to me since "downloads" page is something >>>> currently not widely used is project like us. >>>> As always, I like to refer to competence, and they use to point to NPM >>>> or >>>> Github and not post releases. >>>> We can do it, but for me this is to conform with old habits. We should >>>> expect that "young devs" will go directly to NPM >>>> to get Apache Royale ;) >>>> >>>> >>>> 2017-11-10 0:30 GMT+01:00 Justin Mclean <jus...@classsoftware.com>: >>>> >>>>> Hi, >>>>> >>>>>> Great job. I think we have all links on the mailing list web page. >>>>>>The >>>>> one >>>>>> thing which I really really miss is place on the download site >>>>>>where I >>>>> will >>>>>> be able to download Nightly Build - >>>>> >>>>> Please read this [1] about linking to nightly builds. >>>>> >>>>> Justin >>>>> >>>>> 1. >>>>> >>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ap >>>>>ac >>>>> >>>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f8 >>>>>04 >>>>> >>>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7 >>>>>C6 >>>>> >>>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBw >>>>>E% >>>>> 3D&reserved=0 < >>>>> >>>>> >>>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ap >>>>>ac >>>>> >>>>>he.org%2Flegal%2Frelease-policy.html%23host-rc&data=02%7C01%7C%7C022f8 >>>>>04 >>>>> >>>>>829b540f2b8ea08d5282daf79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7 >>>>>C6 >>>>> >>>>>36459099045827202&sdata=YpwkTlmVVziJiXkXkD3R8mxDxPJPNn5CGm%2BHMz%2BSBw >>>>>E% >>>>> 3D&reserved=0> >>>> >>>> >>>> >>>> >>>> -- >>>> Carlos Rovira >>>> >>>> >>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.m >>>>e% >>>> >>>>2Fcarlosrovira&data=02%7C01%7C%7C022f804829b540f2b8ea08d5282daf79%7Cfa7 >>>>b1 >>>> >>>>b5a7b34438794aed2c178decee1%7C0%7C0%7C636459099045827202&sdata=lvwM%2Bm >>>>BW >>>> p%2FhvTcq7Vy%2Fi9lVbyiNq%2Btzr25lC2V3whBU%3D&reserved=0 >>> >> >
