Hacker News Reader

Comment by zh217 | Hacker News Reader

No, my understanding is that if you don't make any changes to the Cozo code, you don't need to release anything to the public. If you do, and you cannot release your non-Cozo code, then you must dynamically link to the library (and release your changes to the Cozo code). The Python, NodeJS and Java/Clojure libraries all use dynamic linking.

There is no plan for any commercial license - this is a personal project at the moment. My hope is for this project to grow into a true FOSS database with wide contributions and no company controlling it. 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.

View on HN

Let me preface by saying that this seems like a great piece of software and it is absolutely within your right to license it as whatever you would like, no matter what any of the commenters here think.

However, I don't believe your understanding of AGPL is accurate.

> No, my understanding is that if you don't make any changes to the Cozo code, you don't need to release anything to the public. If you do, and you cannot release your non-Cozo code, then you must dynamically link to the library (and release your changes to the Cozo code). The Python, NodeJS and Java/Clojure libraries all use dynamic linking.

This sounds like you're thinking of the LGPL, not AGPL. Whereas LGPL is less strict than GPL because the exception you describe above applies. AGPL on the other hand is more strict. Essentially, if you use any AGPL code to provide a service to users then you must also make the source code available, even if the software itself is never delivered to users.

The intention here is that you can't get around GPL by hiding any use of the GPL code behind a server, so it makes perfect sense to use it for a database. But I don't think it does what you want.

Whichever way you decide to go, be it AGPL, LGPL or something else, I encourage you to make a choice before accepting any outside contributions. As soon as you have code from other authors without a CLA you will need to obtain their permission to change the license (with some exceptions).

(Disclaimer: I'm not a lawyer, just interested in licenses.)

Thank you for your perspective.

Maybe I was confused about the case of using an executable vs linking against a library. Let me double-check with a few friends who understand copyright laws better than me. If everything checks out, the next release will be under LGPL.

About CLA: at the previous suggestion of a friend, the repo was locked with CLA requirement currently (even though nobody outside contributed yet). This will be lifted once the situation becomes clearer.

It seems that I really did misunderstand the differences. It is now under LGPL. The repo still requires CLA for contribution for the moment until I am really sure.

> The repo still requires CLA for contribution for the moment until I am really sure.

I just wanted to mention that this sounds like a great idea for a new project. Stay behind a CLA, for a while, just in case the initial license turned out to be an issue.

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

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!

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... But it's great to see more cool projects in this space, so thank you.

I am not a lawyer, but I work in an open source programs office and am currently working specifically on open source license compliance.

Beyond what the sibling comments have said about LGPL sounding more like what you're going for, I'll just note that if you'd like broad adoption of this while still ensuring that changes to your code remain open, you might also want to consider the Mozilla Public License.

From what I understand of MPL and LGPL is that MPL is better for instances where dynamic linking isn't possible. The MPL basically says that any changes _to the files you created_ must be available under the MPL, preserving their public availability.

That said, most organizations are fine with the LGPL, but it just gets gnarly if there are instances where you really want to statically link something but you still fully want to support the original library's openness.

Licensing under AGPL will make it hard for any startup to use Cozo. Lawyers always ask about AGPL in venture financing diligence and it is considered a red flag. You can argue that they are wrong, the linking exception and so on, but you’re basically shouting into the wind.

AGPL is a variant of the GPL, not the LGPL. Meaning that dynamic linking still constitutes (according to them) a derivative work, meaning that even programs that dynamically link against it must themselves be AGPL in their entirety. Dynamic linking is also meaningfully complicated to do in Rust, and this licensure of the crates.io crate will be a footgun for anyone not using cargo-deny.

I think this is a very cool project, but its use of *GPL essentially ensures I'm not going to use it for anything. If you're planning on reducing it to LGPL, I'm not sure what the GPL is getting you over going with the Rust standard license set of MIT + Apache 2.0.

If I'm not mistaken that sounds more like LGPL than the AGPL?

Maybe, and maybe I need to consult a lawyer someday to get the facts straight. To tell you the truth my head hurts when I attempt to understand what these licenses say. Regardless, I intend this project to be true FOSS, the "finer detail" of which FOSS license it uses may change.

My understanding is the same as kylebarron's[0] since you lack linking protections (which you would get under LGPL), so any work that includes cozo would be a "derived work" under the (A)GPL. Interestingly there doesn't seem to be an affero LGPL license[1], which could be what you might want here.

Otherwise, simplest solution provided you want a copyleft license would be to use the LGPL I think.

NOTE: not a lawyer.

[0] https://softwareengineering.stackexchange.com/questions/1078...

[1] https://redmonk.com/dberkholz/2012/09/07/opening-the-infrast... (old link, but I couldn't find anything since then describing this kind of license?)

We kinda do have it; it's just mostly useless, given the linking clause. (Not entirely useless, though, as that article sets out.)

GPL and AGPL have the same layout, so you can just take the LGPL, and replace all references to 'GPL' and 'GNU General Public License' with 'AGPL' and 'GNU Affero General Public License'. Of course, you couldn't call that license 'GNU ALGPL' or 'GNU LAGPL'; you'd have to come up with your own name. (Disclaimer: I'm not a lawyer, and I haven't checked this as thoroughly as I would if I were going to use this for my own software.)

Maybe it's worth bothering Bradley M. Kuhn (http://ebb.org/bkuhn/) again and seeing what the current status of a Lesser AGPL is?

That's a fair enough stance. I'd recommend not taking any outside contributions until you are sure about the license, since it'll make it much harder to change the license if you do. Or maybe require all outside contributions to be licensed very permissively, like using the BSD license. Or you could use a CLA, but that's not something I'd recommend. Either way, licensing is hard :(. I can emphasise with the head hurting.... Oh, also, check out https://tldrlegal.com/ .

its also odd then re the python bindings being MIT, as the AGPL will convey throughout any aggregation or library usage, as would GPL, the primary delta for GPL vs AGPL is the intent on the later for network offered services, which in the context of an embedded library/db is odd. rightly or wrongly many orgs will refuse to allow usage of gpl/agpl software due to the licensing concerns around the effects of the rest of their ip. duckdb (embedded analytics sql) uses mit, etc. so in terms of creating a "true foss" project ie a community of users and contributors, its definitely worth considering a licensing change imho, but of course dealers choice.

OP here. Nothing about the license is final yet since there are no outside contributors. I just changed the main repo to LGPL, not because what I believed in changed, but because it seems that I really misunderstood the licenses.

Reply on news.ycombinator.com