3 ms·

> If a community forms and after I understand the consequences a little bit more, the license may change if the community decides that it is better for the long

by ekidd 4y ago

> If a community forms and after I understand the consequences a little bit more, the license may change if the community decides that it is better for the long-term good of the project. For the moment though, it is staying AGPL. Yes, I do want to be clear: I encourage you to use whatever license you like. You wrote the code! I was just curious, because it would also affect the license of any hypothetical software I wrote that used the library. Here's a super oversimplified version of the main license types (I am not a lawyer): - Permissive: "Do whatever you want but don't sue me." - LGPL: "If you give this library to other people, you must 'share and share alike' the source and your changes to this library." - GPL: "If you use this code in your program, you must 'share and share alike' your entire program, but only if you give people copies of the program." - AGPL: "If you use this code in your program, you must 'share and share alike' your entire program with anyone who can interact with it over a network." The AGPL makes a ton of sense for an advanced database server, because otherwise AWS may make their own version and run it on their servers as a paid service, without contributing back. But like I said, I'm simplifying way too much. Take a look at the FSF's license descriptions and/or talk to a lawyer. This shouldn't be stressful. Figure out what license supports the kind of users and community you want, pick it, and don't look back. :-) (I may end up writing a super-simple non-persistent Datalog at some point for an open source project. My needs are much simpler than the things you support, anyways—I only ever need to run one particular query.)

zh217 4y ago
I realized my mistake, as I said in the other comments. The main repo is now under LGPL. I'll see what I'll do with the bindings. Writing code is so much better than dealing with licenses!
- ekidd 4y ago
  Oh, cool! And yeah, licenses can be challenging and frustrating, especially the first time you release a major project. I am really super excited by the idea of embedded Datalog in Rust. I sometimes run into situations where I need something that fits in that awkward gap between SQL and Prolog. I want more expressiveness, better composability, and better graph support than SQL. But I also want finite-sized results that I can materialize in bounded time. There has been some very neat work with incrementally-updated Datalog in the Rust community. For example, I think Datafrog is really neat: https://github.com/frankmcsherry/blog/blob/master/posts/2018-05-19.md https://github.com/frankmcsherry/blog/blob/master/posts/2018... But it's great to see more cool projects in this space, so thank you.

by ekidd 4y ago

zh217 4y ago

I realized my mistake, as I said in the other comments. The main repo is now under LGPL. I'll see what I'll do with the bindings. Writing code is so much better than dealing with licenses!

ekidd 4y ago
Oh, cool! And yeah, licenses can be challenging and frustrating, especially the first time you release a major project. I am really super excited by the idea of embedded Datalog in Rust. I sometimes run into situations where I need something that fits in that awkward gap between SQL and Prolog. I want more expressiveness, better composability, and better graph support than SQL. But I also want finite-sized results that I can materialize in bounded time. There has been some very neat work with incrementally-updated Datalog in the Rust community. For example, I think Datafrog is really neat: https://github.com/frankmcsherry/blog/blob/master/posts/2018-05-19.md https://github.com/frankmcsherry/blog/blob/master/posts/2018... But it's great to see more cool projects in this space, so thank you.