Richard,

No, this change should not affect you at all.
---------
Matt Taylor
OS Community Flag-Bearer
Numenta


On Sun, Jul 19, 2015 at 7:47 PM, email email <[email protected]> wrote:
> Hi, Matthew,
>
> I would like to know if the license changes research students or fellow like
> me will not download and study the source code? or develop our own research
> programs on the base of NuPIC?
>
> Thanks for your response
>
> Richard
>
> On Sun, Jul 19, 2015 at 1:30 AM, Fergal Byrne <[email protected]>
> wrote:
>>
>> My view as someone working to make a living using and extending HTM
>> technology is very simple. If you stay in (A)GPL-land, you're completely
>> free. If you build something for private use or on behalf of a single
>> client, you're good (you may transfer the responsibility to your client if
>> they're making money). Otherwise contact Numenta.
>>
>> There will be billion dollar businesses based on HTM in the next few
>> years. Those businesses should repay Jeff and Donna for the money and effort
>> they invested to start this.
>>
>> There is huge debate in Deep Learning right now about Google's decision to
>> try and patent several key ideas, many of which go back decades. So it's not
>> just us.
>>
>> Regards
>>
>> Fergal Byrne
>>
>> --
>>
>> Fergal Byrne, Brenter IT
>>
>> Author, Real Machine Intelligence with Clortex and NuPIC
>> https://leanpub.com/realsmartmachines
>>
>> Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014:
>> http://euroclojure.com/2014/
>> and at LambdaJam Chicago, July 2014: http://www.lambdajam.com
>>
>> http://inbits.com - Better Living through Thoughtful Technology
>> http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne
>>
>> e:[email protected] t:+353 83 4214179
>> Join the quest for Machine Intelligence at http://numenta.org
>> Formerly of Adnet [email protected] http://www.adnet.ie
>>
>>
>> On Sat, Jul 18, 2015 at 6:21 PM, Austin Marshall <[email protected]>
>> wrote:
>>>
>>> I considered the MongdoDB example.  One interesting aspect of MongoDB is
>>> that while the server is AGPL, the drivers are Apache.  This helps to make
>>> it straight-forward from a use/licensing standpoint.  If I create mongodb++
>>> as you describe, I'm bound to AGPL, but if I run it verbatim, and connect to
>>> it with the official drivers, then I'm not bound by AGPL and am free to
>>> build a proprietary product.  I don't think such an arrangement is being
>>> suggested here.
>>>
>>> The pro-forma idea is interesting, and certainly helps to mitigate the
>>> barriers for entry for commercial applications.
>>>
>>> On Sat, Jul 18, 2015 at 10:05 AM, Fergal Byrne
>>> <[email protected]> wrote:
>>>>
>>>> Hi Austin,
>>>>
>>>> The best example of this is MongoDB, which operates under the AGPL for
>>>> this reason. I cannot take MongoDB on its own, modify it in some way (let's
>>>> say by incorporating a new caching algorithm) and then market it as my own
>>>> MongoDB++. I also couldn't provide MongoDB++ as a service without providing
>>>> full source to my mods.
>>>>
>>>> I also raised your other point with Donna, about using NuPIC as a back
>>>> end for some software service. As far as I can tell, you could simply build
>>>> an API layer on NuPIC and release only that under (A)GPL, while keeping 
>>>> your
>>>> client app completely closed. Since your code is only a "user" of NuPIC,
>>>> this would fall outside the AGPL per se. You would however then be in the
>>>> territory of building technology using Numenta-patented IP, so it'd be wise
>>>> to think about talking to Donna at that point.
>>>>
>>>> On your comments re bootstrapping to an MVP using NuPIC, would it make
>>>> sense for Numenta to develop a "pro-forma" precommercial license, with a
>>>> timeout such as 12 months? This way, you can notify Numenta that you are
>>>> likely to want to negotiate a commercial license, but they give you a year
>>>> to get to that point at no cost. In the event you get no traction, just 
>>>> Open
>>>> Source your code and you're good.
>>>>
>>>> Regards,
>>>>
>>>> Fergal Byrne
>>>>
>>>> --
>>>>
>>>> Fergal Byrne, Brenter IT
>>>>
>>>> Author, Real Machine Intelligence with Clortex and NuPIC
>>>> https://leanpub.com/realsmartmachines
>>>>
>>>> Speaking on Clortex and HTM/CLA at euroClojure Krakow, June 2014:
>>>> http://euroclojure.com/2014/
>>>> and at LambdaJam Chicago, July 2014: http://www.lambdajam.com
>>>>
>>>> http://inbits.com - Better Living through Thoughtful Technology
>>>> http://ie.linkedin.com/in/fergbyrne/ - https://github.com/fergalbyrne
>>>>
>>>> e:[email protected] t:+353 83 4214179
>>>> Join the quest for Machine Intelligence at http://numenta.org
>>>> Formerly of Adnet [email protected] http://www.adnet.ie
>>>>
>>>>
>>>> On Sat, Jul 18, 2015 at 5:33 PM, Austin Marshall <[email protected]>
>>>> wrote:
>>>>>
>>>>> I see a couple of issues with the AGPL.  The wording of AGPL is
>>>>> absolute regarding "all users interacting with it remotely through a
>>>>> computer network".  This may become a barrier for anyone potentially
>>>>> interested in a commercial license later.  For example, in Lean Startup
>>>>> parlance, I may want to experiment with a minimum viable product to gauge
>>>>> interest before investing too much effort into developing a commercial
>>>>> product.  If I'm not already planning on using AGPL (very few do), I'm
>>>>> forced to consider the implications before I start my experimentation.
>>>>> Personally, I'd rather not have to worry about it -- I'd want to get users
>>>>> on my mvp as early as possible and not have to delay the process with
>>>>> commercial license negotiations, especially since I'd be at a 
>>>>> disadvantage,
>>>>> not having any experience with the technology and not having much of an
>>>>> opportunity to make an informed estimate of the commercial viability.
>>>>> Google has even taken a stand and outright banned AGPL-licensed software 
>>>>> for
>>>>> internal use
>>>>> (http://www.theregister.co.uk/2011/03/31/google_on_open_source_licenses/).
>>>>> I find that position to be reasonable, and I'm sure they are not alone.
>>>>>
>>>>> I'm also skeptical about the enforceability the AGPL with respect to
>>>>> closing the loophole.  Let's say I want to get my product out and either
>>>>> don't want to seek out a commercial license or don't want to do it now.  I
>>>>> might argue that, in many ways, you can incorporate nupic into your tech
>>>>> stack and not be required to share your source.  For example, let's say I
>>>>> have a product that makes recommendations, and behind the scenes I use 
>>>>> nupic
>>>>> in some small part of an ensemble.  If this process is done in an
>>>>> offline/batch mode on behalf of the user and only the results conveyed to
>>>>> the user, then I might argue that my user has no interaction with nupic, 
>>>>> and
>>>>> therefore my service is not subject to the virality of the AGPL.
>>>>>
>>>>> In other words, I'm either likely to avoid it like the plague, or try
>>>>> to get crafty.  I'm not convinced that the AGPL helps in the long term
>>>>> adoption of nupic and related software, from either free or commercial
>>>>> licensing standpoints.
>>>>>
>>>>> On Fri, Jul 17, 2015 at 10:00 AM, Matthew Taylor <[email protected]>
>>>>> wrote:
>>>>>>
>>>>>> Good questions...
>>>>>>
>>>>>> On Fri, Jul 17, 2015 at 9:46 AM, Dean Horak <[email protected]>
>>>>>> wrote:
>>>>>> > How does a project transition from GPLv3 to a different license,
>>>>>> > when all the existing code has already been released as GPLv3. I 
>>>>>> > assume that
>>>>>> > the GPLv3 license will remain in effect for all existing code, and 
>>>>>> > only new
>>>>>> > code specifically contributed by Numenta specifically identified as 
>>>>>> > AGPL
>>>>>> > will be affected by this.
>>>>>>
>>>>>> Correct. The NuPIC (and related) code that currently exists on Github,
>>>>>> and all the history of that code, is GPLv3. There is nothing we can do
>>>>>> about that, it will always be GPLv3. When we change the license to
>>>>>> AGPLv3, from that point forward, the repository and all future
>>>>>> developments in the repo will be AGPLv3. So there will be a line drawn
>>>>>> in time at the commit SHA when we make the license change.
>>>>>>
>>>>>> > But what about community contributed code?  Surely Numenta cannot
>>>>>> > force the community to adopt AGPLv3 should they choose not to since 
>>>>>> > Numenta
>>>>>> > is technically only a contributor (albeit the prime contributor) as 
>>>>>> > well and
>>>>>> > not the "owner" of the codebase.
>>>>>>
>>>>>> Actually, Numenta is the sole copyright owner of the NuPIC codebase,
>>>>>> and the copyright owner has control over the license of the code. This
>>>>>> means that Numenta, as the copyright owner, has the legal right to
>>>>>> change the license without input from any contributors, because all
>>>>>> contributors signed our Contributor License Agreement [1] that signs
>>>>>> over all their copyright of their contributions to Numenta.
>>>>>>
>>>>>> > Do contributors have the option of choosing AGPLv3 or GPLv3?  I
>>>>>> > suppose a vote from the community to adopt AGPLv3 for all future code 
>>>>>> > could
>>>>>> > be enforced by the committers - only allowing AGPLv3 code into the 
>>>>>> > codebase,
>>>>>> > but this seemingly could lead to a fork of the code, which is probably 
>>>>>> > not a
>>>>>> > desirable outcome at this point.
>>>>>>
>>>>>> No, contributors will not get a choice in the matter. If this codebase
>>>>>> were copyright many authors, a vote would be necessary to change the
>>>>>> license. But because Numenta is the sole copyright owner, a vote is
>>>>>> unnecessary. We do, however, care what our contributors think about
>>>>>> licenses, and we certainly to not make such changes wantonly.
>>>>>>
>>>>>> > Again, I do not expect that this will have any real impact on me,
>>>>>> > but in the spirit of clarity and transparency, I think response to 
>>>>>> > these
>>>>>> > types of questions should be considered.
>>>>>>
>>>>>> I am happy to answer any more questions.
>>>>>>
>>>>>> [1] http://numenta.org/licenses/cl
>>>>>> ---------
>>>>>> Matt Taylor
>>>>>> OS Community Flag-Bearer
>>>>>> Numenta
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to