Skip to content
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

Open
mmadson opened this issue Feb 23, 2021 · 6 comments
Open

AGPL #11

mmadson opened this issue Feb 23, 2021 · 6 comments

Comments

@mmadson
Copy link

mmadson commented Feb 23, 2021

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.

@ssilverman
Copy link
Owner

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.

@ssilverman
Copy link
Owner

@mmadson I also don’t mind unlocking the other issue I’d you’d like to add something.

@ssilverman
Copy link
Owner

@mmadson would the plain GPL/LGPL be better for your use cases?

@ssilverman
Copy link
Owner

@mmadson still interested in communicating to see what I could change for something to work for you?

@mmadson
Copy link
Author

mmadson commented Feb 26, 2021

@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.

@matejsp
Copy link

matejsp commented Apr 28, 2021

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:
GPL with Classpath Exception (https://openjdk.java.net/legal/gplv2+ce.html). It is very similar to the LGPL. https://www.whitesourcesoftware.com/resources/blog/top-9-gpl-with-the-classpath-exception-questions-answered

AGPL is also possible if you plan to have commercial offering. But this is very hard when you already have Apache licensed competition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants