-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AGPL #11
Comments
I’m very happy to have a discussion to see how maybe this could be adapted for your needs. Want a voice chat? That may be faster than discussing here. Send me an email with your contact info if you like. |
@mmadson I also don’t mind unlocking the other issue I’d you’d like to add something. |
@mmadson would the plain GPL/LGPL be better for your use cases? |
@mmadson still interested in communicating to see what I could change for something to work for you? |
@ssilverman thanks for being so engaged. Apologies for not having the time to follow up yet. I'd love to have a conversation but honestly I'm not an expert on the topic. I'm really just following Google's lead in deciding what kinds of licenses might be okay to use within a business setting. As far as your suggestion of GPL/LGPL, I believe that falls under a restricted categorization for Google, where in some special circumstances it might able to be used, but it's generally much harder to get approval for as opposed to a license that falls under the notice classification: https://opensource.google/docs/thirdparty/licenses/#notice If your goal is to allow the vast majority of users in corporate setting the ability to use your software, I'd recommend selecting a licenses from Google's notice list. I usually see Apache Version 2.0 and MIT. Those are the 2 licenses I'm most familiar with and feel comfortable using at work. |
It is very important to make a decision about the licensing early in the project life other wise it is really hard to relicense (if you have external contributions). I don't want to start a license war but I think this project would benefit mostly from LGPL. It would protects changes to this library to stay open source (bug fixes, new features) and it does not force projects that use this library to be also published under AGPL (or GPL). This would expand the usage of your library in other projects (yes even open source ones). For example if somebody integrates it with Apache licensed software their software would effectively become AGPL and would no longer be Apache licensed. Personally I like to use and contribute to open source projects that I can use myself without imposing its license on my code. If your library was complete software (like InteliJ) AGPL license would be totally fine. Apache license would be even better (from my point of view) but your code would be a bit less protected. There is also another very interesting alternative that Java uses itself: AGPL is also possible if you plan to have commercial offering. But this is very hard when you already have Apache licensed competition. |
Hi there @ssilverman
I know this is a bit of a sore subject, considering how the last discussion went. Apologies for A) bringing it up again and B) not adding to the previous issue as it was locked to further discussion.
Before jumping in, I just wanted to say thank you for your hard work on this project -- it really is very much appreciated.
I would very much like to use your schema validator for both my open source and closed source projects, however, when it comes to the closed source projects I have similar concerns to those that are outlined in Google's AGPL policy:
https://opensource.google/docs/using/agpl-policy/
Specifically Google does not permit any use of AGPL licensed OSS code in its closed source projects.
I'm definitely not an expert of OSS licensing policies but it seems to me that the AGPL license requires corporate users to open source their closed source projects if they depend on your AGPL library.
Sadly, it's not very likely that we will be able to convince our business partners that all proprietary source code should be open sourced which means -- at least in a corporate setting -- it's unlikely that we will be able to benefit from your hard work.
Perhaps you have already considered this and feel very strongly that all code should be open source and that users who wish to use your code should also open source their code as well both in an OSS setting as well as a corporate setting.
If that is your stance, I totally respect it and please consider this issue resolved. If, on the other hand, you'd like to consider a more permissive OSS license that would enable folks to use your library in corporate settings. I'm sure I and many others would appreciate it.
The text was updated successfully, but these errors were encountered: