search

strongloop / loopback-component-oauth2

oAuth 2.0 server for LoopBack
http://www.strongloop.com
Other
62 stars 63 forks source link

License changed to Strongloop? #27

Closed asanchezdelc closed 7 years ago

asanchezdelc commented 9 years ago

What's the deal with the new license? this repo still heavily uses the oauth2orize module? Any information in regards to this matter will be great. Thanks!

JonnyBGod commented 9 years ago

Same doubts here, what is the plan for this component? Will it be a subscription only component or will it be possible to use as a community component?

At the moment I cannot even figure out how to enable it... When checking the licenses page in Arc it says that "Strongloop Gateway" is coming soon and no license is available.

The impression I had was that the Gateway would be a paid product while the component itself would be free.

wascou commented 9 years ago

+1

mbenaissa commented 9 years ago

+1

PuKoren commented 9 years ago

+1, can't udate the package to v2, licence blocks startup and there is no way to get the licence in Arc ("coming soon")

claylo commented 9 years ago

Luckily for us, we can fork at 2.0.0-rc3. See CHANGES.md

https://github.com/strongloop/loopback-component-oauth2/commit/2422c47d9a80928c895200cafc170dc86b184fe0

PuKoren commented 9 years ago

Well we can fork anywhere and just remove the require('strongloop-license') in lib/index.js but it would be great if they remove the licencing on this module since they version another open source project code in it

claylo commented 9 years ago

@PutKoren I'm not sure that's true. I skimmed the license file enough to see that it would take an unflattering view of what you propose. Cleaner to just fork it before the license change.

raymondfeng commented 9 years ago

We change the license to better support the module in a sustainable way. We'll continue to invest resources to maintain and build this module to be a robust oAuth2 provider.

altsang commented 9 years ago

as @raymondfeng pointed out, if you only need Oauth2, you can use oauth2orize or fork at a prior version, the commercial features asked by our customers were built on top of the component for our Gateway to handle backend pass-through auth and identity.

We have starter subscription packages for individual devs and small startups a like.

asanchezdelc commented 9 years ago

@raymondfeng @altsang Thanks for the clarification. I went ahead and forked the repo at an earlier commit as suggested, located here: loopback-oauth2orize

claylo commented 9 years ago

@raymondfeng @altsang I'm curious why you guys didn't go with a dual license on this component, as you have with others. Why did this one get special treatment?

asanchezdelc commented 9 years ago

@claylo I would think that somehow they need to make money and oAuth2 falls in their "paid" subscription model. StrongLoop Pricing

claylo commented 9 years ago

@qbanguy Red Hat makes plenty of money and have not had to resort to yanking the open source heart out of their flavor of Linux. CentOS keeps the pace quite nicely with RHEL, and that doesn't impact Red Hat's bottom line in a noticeable way.

It does feel sneaky. The component was developed all along with input from users like you and me, under the guise of contributing to an open source library. yeah, we can keep on with your fork, but it's just a poor choice on Strongloop's part. Did the Enterprise JavaScript world learn nothing from Sencha's similar licensing snafu a few years back? Apparently not.

asanchezdelc commented 9 years ago

@claylo Can't agree more.

altsang commented 9 years ago

heard loud and clear @claylo and @qbanguy - just speaking from my POV we've contributed a lot of OSS and most of it has been either MIT or dual licensed.

There wasn't anything intentionally deceptive. We could've created a separate private commercial fork, but in the interest of our company - we need to able to show we have these enterprise capabilities. That being said I can understand why it's been perceived that way. BTW - most of the the input where we flipped the license was done after being onsite with customers for their features. We're an early stage startup. If we had the user base of RHEL for RH or Spring for VMWare we probably wouldn't be worrying about the bottom line. Candidly - we've found that we've release a lot of functionality that folks have used without benefitting ourselves commercially. What to do about the other way around - that's our challenge.

JonnyBGod commented 9 years ago

That is all true and all of us would love to see you thrive. The problem here is that yet again you take this decision lightly, without any consultation to your user base and contributors and with zero preparation time.

When I find out about something like this through an error in my console, SOMETHING IS REALLY BAD.

This is not the second or third time you make decisions like this and a lot of us have invested a lot of time with your framework just to feel deceived every now and then.

Just another point to try to help you out with your business model, it is impossible for you to monetize on something that I can use by simply commenting one line even if against your licensing. If you are trying to do it you will fail for sure.

Make services with your opensource software. Arc is a good example, the rest is just a no go.

What is the point in saying "you can do your own" anyway? Are you saying copy us but not literally? You will just loose your community and they will start competing with you. So good luck with it...

claylo commented 9 years ago

@altsang You'll notice that the companies you cite didn't pull the licensing rug out from their initial user base in the name of generating revenue sooner.

I get struggling startups. I even get struggling startups in the API gateway world, as a co-founder of Mashery. The fact remains you guys went into the open source enterprise software business, presumably with the intent to generate revenues by value adds such as debugging dashboards, production monitoring, strong-pm, support & training, etc.

It's not as though the need to generate revenue on the back of open source software you're contributing to snuck up on you.

Its a risky move that doesn't guarantee a boost in revenues you couldn't have gotten through support contracts ... but it does guarantee some pissed off developers. You've made your choice.

I would argue it's not too late to solve by dual-licensing. If you choose not to dual-license this component, don't be surprised if the open source community doubts you in the future. These are the types of moves that burned Sencha's house down. "Guys, we're getting some traction! Quick! Set the house on fire!" It just strikes me as a very short-sighted decision with a clear downside and a very debatable upside.

Yes, it's your challenge. You knew that when you guys launched the first package. So while I sympathize with the strapped part, please don't bullshit us on it being some kind of emergency ripcord you needed to pull in order to save the business.

We're all grateful for the OSS you guys have contributed, MIT or dual-licensed, which is why we have all contributed patches and gotten behind you, building services on unstable software and providing feedback. It was for the benefit of all of us ... but for some reason you still have not clearly articulated, the OAuth2 component somehow qualifies for special consideration in a license change.

You gotta do what you've got to do. But while thinking of the interest of your company, don't forget its the open source supporters like those on this thread that built the kinds of libraries you guys forked to build the LoopBack stack in the first place that keep you afloat. We're the guys who carry the sway with the companies who write the enterprise licensing checks. Are you certain you want to deliberately cause us to start questioning your intentions? To wonder if you'll yank the licensing rug out from under us with the next release of some component?

asanchezdelc commented 9 years ago

I invested lots of time learning the docs and you structure specially your examples. I even forked your loopback-gateway2, because it did not work with this component.

Anyways, after seeing the license change without notice, it was a big flag(no-no) for us. The funny thing is that we were going to use StrongLoop services in the long run. However, the way you handled this made us go with another framework.

altsang commented 9 years ago

I don't make the call on the licensing. As an OSS supporter and a member of this company I understand both areas and am vocal in advocating both view points both internally and externally.

Again, there's no deception on my part nor that of SL's part, so I don't see the need to callout for "bullshitting" anyone - but your remarks and choice of diction are your own. One would hope that with all the good we do with no angle to ever monetize that you'd be given the benefit of the doubt. No such luck I suppose on the goodwill of this representative set of the community.

I'm more than happy to see if this component can be made dual licensed.

thpham commented 9 years ago

it's really not cool, I invested couple of days with a prototype. I removed the trial licenses and I see my project is unable to work without ... why there is no message on the readme page that tell us this component is not under license !?

itamar-Cohen commented 9 years ago

hi, insted StrongLoop API Gateway i reccomend https://tyk.io it is open source, self-hosted, full-featured API management, gateway, dashboard (close source but free to use) and host manager

BoLaMN commented 8 years ago

Hey All,

Ive been working on an open source oauth2 component to solve this issue. its not complete yet but its starting to come together if anyone wants to check it out go look at my github repo.

chris-hammons commented 7 years ago

Hello all,

It looks like the license has now changed to be "Property of IBM IBM StrongLoop Software Copyright IBM Corp. 2016". With this new license, can this component now be used as is with a loopback project not on apiconnect at no cost? Or does it now require a subscription to apiconnect to use it at all?

chandadharap commented 7 years ago

This was most likely oversight on our part when we moved to another org. @raymondfeng can we make this MIT. Feel free to assign to the correct person to make it happen. @rmg FYI.

raymondfeng commented 7 years ago

+1 to switch back to MIT license. I think the circumstance has changed since 2015.

superkhau commented 7 years ago

PR at https://github.com/strongloop/loopback-component-oauth2/pull/61

stale[bot] commented 7 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 7 years ago

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.