I guess it's all about this bit of the license: The Software shall be used for Good, not Evil
which doesn't fit in legalese speak :) > On 24.11.2016 г., at 17:27, Svetoslav Neykov > <svetoslav.ney...@cloudsoftcorp.com> wrote: > > Thanks for the heads up Richard. I'll check whether we are using it. > > Svet. > > >> On 24.11.2016 г., at 16:56, Richard Downer <rich...@apache.org> wrote: >> >> Svet, >> >> There's a discussion going on elsewhere in ASF[1] about The JSON License[2] >> - it was previously acceptable to ASF and was on the Category A list[3]. >> However, it's been realised that the decision to place it in Category A was >> incorrect, and it has now been moved to Category X. This means that >> software covered by The JSON License must not be a transitive dependency of >> Apache software releases. >> >> I believe that the software this affects is the "json.org" or "org.json" >> Java JSON library. I don't think that we use this, but it's possible that >> it's a transitive dependency. >> >> If this comes up in your LICENSE rework then we'll need to take some action >> on it - we have a grace period so it doesn't necessarily have to be >> replaced this release, although we would need to update NOTICE. However >> there exist drop-in compatible replacements so it may be easier to just >> deal with it now. >> >> If you'd like me to link you to more of the discussion then I can do that. >> >> Richard. >> >> [1] >> https://lists.apache.org/thread.html/bb18f942ce7eb83c11438303c818b885810fb76385979490366720d5@%3Clegal-discuss.apache.org%3E >> [2]http://www.json.org/license.html >> [3]https://www.apache.org/legal/resolved#category-a >> >> On 24 November 2016 at 13:52, Svetoslav Neykov < >> svetoslav.ney...@cloudsoftcorp.com> wrote: >> >>> That's some good news. Thanks for taking the time to look at this Andrea. >>> I also have some progress to share. Today I was finally able to build >>> Brooklyn with all tests passing (consistently at that) - on a branch that >>> had all my recent PRs. Thanks Geoff for reviewing and merging all of them. >>> I'm currently checking whether our LICENSE files need an update because of >>> updated dependencies and fixing the corresponding scripts to work with the >>> current project structure. Next will turn my attention to testing the >>> jclouds 1.9.3 PRs. As soon as they are merged we can have our first RC. >>> >>> Also would be nice to include a proper fix for what #452 [1] tried to >>> solve (but failed at). >>> Any other suggestions for PRs to include in the RC are welcome. >>> >>> Our change log needs some love so any help there will be greatly >>> appreciated. >>> >>> Svet. >>> >>>> On 24.11.2016 г., at 15:16, Andrea Turli <andrea.tu...@cloudsoftcorp.com> >>> wrote: >>>> >>>> Hi >>>> >>>> jclouds 1.9.3 is officially out -- see >>>> http://markmail.org/thread/qlapnppmfbilje7p for more details >>>> >>>> ---- >>>> >>>> FYI @bostko already created this PR to bump jclouds version >>>> https://github.com/apache/brooklyn-server/pull/457 >>>> >>>> I've generated the dependency:list from tag rel/jclouds-1.9.2 and >>>> rel/jclouds-1.9.3 from jclouds/jclouds repos (see >>>> https://gist.github.com/andreaturli/b7c178519ab4d029d562643426a2738d and >>>> https://gist.github.com/andreaturli/8d54e4340ef0a4c650022396b4b54b89) >>> and >>>> apart from org.apache.jclouds versions I can't see any new version for >>> the >>>> transitive dependencies. >>>> >>>> ---- >>>> >>>> I've also checked the swift vs openstack-swift issue when targeting the >>>> brooklyn persistence to IBM SoftLayer Object Storage: it works fine with >>>> jclouds 1.9.3 and jclouds 2.0.0 so this shouldn't be an issue for the >>>> release. (see https://github.com/jclouds/jclouds-examples/pull/90) >>>> >>>> HTH, >>>> Andrea >>>> >>>> On 18 November 2016 at 12:19, Andrea Turli <andrea.turli@cloudsoftcorp. >>> com> >>>> wrote: >>>> >>>>> Hi there, >>>>> >>>>> I've released the Apache jclouds 1.9.3-rc1 (see [1] and [2] for more >>>>> details) >>>>> >>>>> Please download, test and vote if you can! >>>>> >>>>> Andrea >>>>> >>>>> [1]: https://lists.apache.org/thread.html/ >>> 42f3a91008890939cf344f35320f86 >>>>> bcc48f814119655d7347c9bcca@%3Cdev.jclouds.apache.org%3E >>>>> [2]: https://lists.apache.org/thread.html/ >>> 94981b8f456785ffea640af3be9207 >>>>> 103bb4b7ee2f6d5bb783e98c2c@%3Cdev.jclouds.apache.org%3E >>>>> >>>>> On 17 November 2016 at 19:01, Duncan Johnston Watt <duncan.johnstonwatt@ >>>>> cloudsoftcorp.com> wrote: >>>>> >>>>>> +1 Andrea thanks >>>>>> >>>>>> Duncan Johnston-Watt >>>>>> CEO | Cloudsoft Corporation >>>>>> >>>>>> Twitter | @duncanjw >>>>>> Mobile | +44 777 190 2653 >>>>>> Skype | duncan_johnstonwatt >>>>>> Linkedin | www.linkedin.com/in/duncanjohnstonwatt >>>>>> >>>>>> On 17 November 2016 at 06:09, Aled Sage <aled.s...@gmail.com> wrote: >>>>>> >>>>>>> +1, sounds great - thanks Andrea! >>>>>>> >>>>>>> There are some really import jclouds fixes in 1.9.3-SNAPSHOT (or >>> 2.0.0) >>>>>>> that we want, such as an OutOfMemoryError deploying to Softlayer [1]. >>>>>>> >>>>>>> It's worth hanging fire on Brooklyn 0.10.0 until we have a jclouds >>> 1.9.3 >>>>>>> release. >>>>>>> >>>>>>> In the meantime, we should still get our own house in order by doing >>> the >>>>>>> first of the steps below (i.e. dealing with open PRs; ensuring no-one >>>>>> has >>>>>>> any imminent important contributions to make for 0.10.0, etc). >>>>>>> >>>>>>> Aled >>>>>>> >>>>>>> [1] https://issues.apache.org/jira/browse/BROOKLYN-364 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 17/11/2016 11:37, Alex Heneveld wrote: >>>>>>> >>>>>>>> That would be a great solution Andrea! >>>>>>>> >>>>>>>> Best >>>>>>>> Alex >>>>>>>> >>>>>>>> On 17 Nov 2016 08:18, "Andrea Turli" <andrea.tu...@cloudsoftcorp.com >>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> I'm happy to volunteer for releasing an official jclouds 1.9.3 which >>>>>> may >>>>>>>>> be >>>>>>>>> the half-house solution here. >>>>>>>>> >>>>>>>>> wdyt? >>>>>>>>> >>>>>>>>> Andrea >>>>>>>>> >>>>>>>>> On 17 November 2016 at 08:25, Svetoslav Neykov < >>>>>>>>> svetoslav.ney...@cloudsoftcorp.com> wrote: >>>>>>>>> >>>>>>>>> This is going to be the first release that actually works in Karaf. >>>>>> The >>>>>>>>>> docs are still assuming classic though so I suggest we keep >>>>>> recommending >>>>>>>>>> the classic distribution for 0.10.0. >>>>>>>>>> For next release let's plan on updating the docs and switching the >>>>>>>>>> recommended distribution to the Karaf based one. >>>>>>>>>> >>>>>>>>>> Svet. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 16.11.2016 г., at 13:22, Aled Sage <aled.s...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> It's far past time that we did a Brooklyn 0.10.0 release! I >>> suggest >>>>>> we >>>>>>>>>>> >>>>>>>>>> aim for that soon. >>>>>>>>>> >>>>>>>>>>> To that end, I suggest the following steps: >>>>>>>>>>> >>>>>>>>>>> * Deal with open PRs: >>>>>>>>>>> o People shout out about any PRs you think are very important >>>>>> to >>>>>>>>>>> be merged, before that release. >>>>>>>>>>> o Review open PRs >>>>>>>>>>> (for any that won't get merged into 0.10.0, clearly mark >>>>>> them as >>>>>>>>>>> such and say why). >>>>>>>>>>> * Any pending/remaining work: >>>>>>>>>>> o Give people until Friday evening (uk time) to submit any >>>>>> other >>>>>>>>>>> very important PRs that are being working on. >>>>>>>>>>> o People shout out about any known issues that they see as >>>>>>>>>>> blockers for a release. >>>>>>>>>>> * Do some initial testing, using master (before Friday). >>>>>>>>>>> * Aim to produce a first release candidate on Friday evening (uk >>>>>> time). >>>>>>>>>>> * Do the usual QA/fix cycle until the release is ready. >>>>>>>>>>> * Write release notes, etc. >>>>>>>>>>> >>>>>>>>>>> Of the first steps, reviewing the PRs is a big piece of work! If >>> you >>>>>>>>>>> >>>>>>>>>> have time to help, then please lend a hand by reviewing and/or >>>>>> testing >>>>>>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>>> PRs, and commenting on them. >>>>>>>>>> >>>>>>>>>>> I don't think we should try to squeeze lots of additional PRs into >>>>>>>>>>> >>>>>>>>>> 0.10.0 - there is already a huge amount in there compared to 0.9.0! >>>>>>>>>> >>>>>>>>>>> Richard, are our release process docs up-to-date at [1]? >>>>>>>>>>> >>>>>>>>>>> Aled >>>>>>>>>>> >>>>>>>>>>> [1] http://brooklyn.apache.org/developers/committers/release- >>>>>>>>>>> >>>>>>>>>> process/index.html >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>> >>> >
