Notesnook is going open source in August! #747
Replies: 14 comments 21 replies
-
|
I like the Apache license because it protects against patents, and I personally don't like copy-left licenses. In the Rust community, they like to have dual licenses with MIT and Apache. But because of this:
GPL or LGPL is probably best because businesses would have to open-source their fork too. If you plan on open-sourcing the server, I think the AGPL license would be the most appropriate for that repository because that license covers legal stuff regarding servers. But if you don't want Notesnook copies, then open-sourcing the sync server would help encourage that. I personally don't care about the server being open source because the client is the only part that matters. But I can understand how other people would feel differently. |
Beta Was this translation helpful? Give feedback.
-
|
This is great help! Thanks for taking the time to comment.
I'd want a permissive license too but the reality is that there are some people out there just waiting to abuse. We want to be protected against that so Notesnook remains a healthy ecosystem.
A lot of people have suggested AGPLv3 with GPLv3 for the clients so I am going to do in-depth research on that.
Maybe not open source but definitely self-hostable. |
Beta Was this translation helpful? Give feedback.
-
|
Just a note: Open source per definition does not allow to prevent other people or businesses to sell the software and even GPL doesn't do that. GPL just says the forked work has to be licensed under GPL too and be open source too which makes it a little less attractive to do that. |
Beta Was this translation helpful? Give feedback.
-
|
You can by the way exclude trademarks: https://opensource.stackexchange.com/questions/7635/can-i-force-to-use-a-different-name-when-redistributing-gpl-software |
Beta Was this translation helpful? Give feedback.
-
|
Personally I would go for the GPL license for the clients and not open source the sync server which raises the barrier even more for someone to just copy and sell the product as a whole. |
Beta Was this translation helpful? Give feedback.
-
Yes, unfortunately that is a reality. Nothing can prevent someone from ripping off of our hard work but we can certainly make it difficult. For an honest contributor or person, this would make no difference. It's the companies we want to protect against. |
Beta Was this translation helpful? Give feedback.
-
LicenseI usually advocate for permissive licenses, as it allows easy reuse also in commercial environments. That's the reason why it's usually applied to libraries. If you are not willing to allow that, then GPL would make sense on the client as it does not make it as appealing for a business to change and resell. If you open source the server, you may want to consider using the Affero GPL, so (I'm oversimplifying) one cannot run a modified version as a service without publishing their source code. Example: MongoDB, Bitwarden. License changeIf you change your mind down the road: you can always change your license afterwards for a new version of your product, because you are the owner of it. You can also add a second (third, fourth, ...) license retroactively to past versions of your product if you change your mind. The only thing you cannot do it remove an existing license after publishing. RepositoriesI would reccommend one repo per project: one per client, one per server. Maybe clients could also be split into web, mobile, desktop. It makes it more understandable and easier to for. If you are using shared libraries, you can place them into a separate repository and use that as a Git submodule. Check out how Signal and Bitwarden do it. Open source serverSignal and Bitwarden are open sourcing it. I believe having the possiblity makes it helpful for people that don't want to self-host, it would help in finding bugs ("sync does not work" is not really a helpful bug report, right?) Have you considered releasing it as a compiled binary? That would allow self-hosting while keeping your intellectual property more protected. Where to marketThe Changelog is a great place to start. Once you open source it and you notify them, they are probably going to include it into their newsletter and maybe even invite you on the podcast, who knows :) Get a professional security auditIt would make it clearer to the world that your project is safe and secure. Not every programmer is a security researcher that may find vulnerabilities in the source code :) Anything else to consider?It's better to open source a project and then clean it up, if it's not perfect, than to wait until it's perfect to release it, because you will never release it. |
Beta Was this translation helpful? Give feedback.
-
AGPL has been recommended by almost everyone for the server so it must be good for this. Thank you for the examples!
This is definitely helpful to know that we won't be perpetually locked in.
I really like the Bitwarden approach. Separate repos for clients & server. Each library can further have a separate repo as well. If a library is too closely shared among the clients, it can also remain in the clients repo. The other approach is to put everything in one place but that will become a hassle too quickly.
This has been on my mind but I don't know how it'll be received by the community. Personally, I have no issue with open sourcing the server. Not everyone has the technical abilities or the required time to self-host. The few people who do are probably also the ones helping you find bugs or improve the code etc.
Changelog is definitely going to be huge. I'll make sure to tip them once Notesnook goes open source.
That's what we have figured as well. The whole preprocessing stage has very little to do with the code and more to do with licensing, documentation, optimizing different processes etc. Work on code will be done afterwards.
Definitely but we aren't financially capable for that just yet. Hopefully open sourcing will put us closer to that goal. As far as I know, audit goes invalid as soon as a change is made in the audited code. It needs to be performed regularly or it has no meaning for the latest versions. |
Beta Was this translation helpful? Give feedback.
-
This isn't that simple. If there are contributions from other people, then these contributions (code parts) are authored by them, and therefore they own them and "by default" they license these code parts back to you under the same license. Therefore you must abide licensing terms for these code parts, that were authored by someone else. If you want to change license for not-fully-yours code, which also has other authors, then you need to collect approval for license change from them also. Or, you can make them sign CLA before accepting any contribution. But, some open-source developers dislike or even hate CLA and don't touch / contribute to a project covered by a CLA. There are plenty heated discussions online about this. However, if you want to be not locked in to a certain license, then CLA is the safest and easiest way. EDIT: if you open-source the server under AGPL, then even you must abide these licensing terms if there are other contributions. Therefore you no longer have the option to offer modified version of an open-source project, because you run some else's code (parts) licensed under AGPL. Unless you have it covered by a CLA. |
Beta Was this translation helpful? Give feedback.
-
|
That's a really good point I completely forgot about, thanks @kravemir. I should've written "you can always change the license to your own code". |
Beta Was this translation helpful? Give feedback.
-
Monorepo vs. repo-per-packageI personally don't like monorepos, everything should be separated into its own piece. Monorepos are also often overwhelming for new people who want to contribute to FLOSS. How to make it easier to contribute to Notesnook?I think it would be really really cool if you could provide a README where you give an abstract explanation of how Notesnook works under the hood. This is something I'm missing on a lot of projects, but I have seen it once and it helped me very much to understand the project. Where to market & spread the news? (we'd appreciate your help is getting the word out there)I honestly think you have to go to mainstream media to be really successful. Share photos & videos on Instagram, Twitter, TikTok, etc.. I think it's necessary to be mainstream, because otherwise FLOSS will always be something that normal people think is only used by nerds and terrorists. |
Beta Was this translation helpful? Give feedback.
-
This is really good advice. I was thinking of adding an
Separate repos are an ordeal to manage especially if there are too many of them. Perhaps a hybrid approach would work best? |
Beta Was this translation helpful? Give feedback.
-
|
Here are my general thoughts. I've professionally developed software for about the past 10 years, with only 4 of those in true software engineering shops (I usually code as part of IT automation because of the freedom I get to do so in those roles). My highest priority when I release source code is that I don't want my labor exploited by a company, which can happen with weak copyleft licensing. I want to be paid for my work if someone is going to use it for profit, so I ensure I release under licensing that is the hardest for companies to use as possible (because they can always pay me to relicense or sublicense under a non-copyleft license, not that I think I've truly release anything revolutionary, but accidents happen).
AGPL is the best thing that fits your case. While it technically doesn't prevent forking and selling, most companies will not allow employees to merely use the software, let alone build upon it. If you plan to accept contributions and dual license to sell, you will also need to ensure any contributor understands that they transfer exclusive rights for you to use their additions if they contribute (or else you'd be relicensing their source code, and your releasing a proprietary version may violate copyright). Some projects opt to do this by ensuring someone understands that a completed merge will transfer the copyright to you in the pull request discussion, and others (such as System.Data.SQLite) require a signed contributor agreement on file. I am not a lawyer, so please consult with a licensed copyright attorney versed especially around software copyrights. Note that this is mostly a concern for code that has copyleft licensing (both GPL and AGPL) where you plan to dual license to a proprietary license to sell. If you want people who are employed to use the software, you might be able to get away with GPLv3 for any client-only code, but the server, if you're worried about fork & sell, should be AGPLv3. If you use AGPLv3, you need to use GPLv3 (GPLv2 is not compatible unless it allows you to go to any later version of the GPL). (Note: companies' stances against AGPL are often extra paranoid. If one uses the software or merely hosts an unmodified version of software, there's nothing to really do to comply with the licensing) Read up on these licenses, and ensure you understand the implications of these licenses before you publicly release software under them.
Generally, monorepo is more friendly (having to use git submodules can be a pain) until the project gets too unwieldy. If it makes sense to break something out, break something out. Someone may come along and request something to be broken out because it's useful for them outside of Notesnook. However, often if you need a change in a depended-upon repository, you'll also need to change code in the main repository, and it's a hassle to keep all that in sync.
Make building the software easy. As awesome as software like Firefox or Libreoffice are, their build process could take a few days for even an experienced programmer just to get to working order, let alone the trouble for a novice programmer. If your build process has manual steps and tweaks for a normal build, that's going to discourage people from casually pulling it down and seeing if they can make a quick change. The best way to ensure your build process is streamlined is to make it work in an automated build pipeline with as few actions needed as possible (like
Absolutely. Open source everything. For the server, you should AGPL the server so that someone won't be able to sell your software as a service. That is a common loophole in the GPL.
Ensure you fully understand the implications of any license you use. Run through scenarios, like "What if Google/Amazon/somebody_somewhere_else takes the software. Can they sell it for money? If they do, do we or the community have access to those changes?". Also ensure you fully understand the implications of your contribution process, especially around joint copyright ownership. The simplest model, used by SQLite, is to not allow contributions. If you are unsure of any of license or how contributions could operate with your repository, consult with a copyright attorney. They might be pricey per hour, but if you can even get a few hours with a decent attorney just to cover your bases, you'll be farther ahead than many open source devs in the long term. I am certain if money is potentially an issue here for an attorney to fill the knowledge gaps, people would be happy to donate to cover the costs. You may not want to be in a position where your labor can be exploited by a big company for profit, which can happen if you naively decide to release under a weak copyleft license (like MIT or BSD), and so thinking about that ahead of time is definitely a good thing to do. I will say you're much farther ahead than a lot of people just by thinking about these things. Stay thinking, and don't rush, and you'll be fine. |
Beta Was this translation helpful? Give feedback.
-
|
I personally disagree on the mono-repo option. Having one repository with inside
get's messy reeeeally fast, especially when you want to release a new version of, say, the desktop client, but there was no change of the server code. I heavily agree on all other points, especially the "make it easy to build". 👍 |
Beta Was this translation helpful? Give feedback.
-
|
@itchychips thank you for your detailed response. All of your points make a lot of sense.
This is exactly our standpoint is as well.
Does a CLA work for this? I have contributed in Big Corp repos such as
This is where a monorepo shines. Heavily depended-upon code can easily be changed along with all the dependents without sync issues.
Definitely. The client apps will be as easy as running |
Beta Was this translation helpful? Give feedback.
-
My understanding is a CLA, contributor license agreement, definitely works for this. You should definitely consult with an attorney for specifics, but it sounds like you are on the right track! |
Beta Was this translation helpful? Give feedback.
-
|
Gpl is probably best choice |
Beta Was this translation helpful? Give feedback.
-
|
One more thing to consider about licensing the server: one option could be to create a custom license, that allows non-commercial usage only. This would allow any private user to run the server code for self-hosting their own notes, but not a company to self-host theirs. The company would need to pay you for a commercial license. BUT BEFORE YOU DO such a thing, creating your own license is not easy and discourages people to even use your code in the first place, because it's not clear what a custom license allows you to do. So, please check if there existing "standard" licenses out there that allow you to do that. I'm thinking about the CC BY-NC 4.0, but Creative Commons does not work well for software, so you may need to consult a copyright attourney for the details. |
Beta Was this translation helpful? Give feedback.
-
I'll definitely research further on this. Perhaps someone has already done the necessary homework. |
Beta Was this translation helpful? Give feedback.
-
|
@thecodrr Just a note on this, if you do use such as license which prevents commercial (Or any kind of usage) then the project would no longer be considered "Open Source", but instead "Source Available" or similar. It's a point I often see confused so I've recently written about this topic, which has some examples of those kind of licenses. |
Beta Was this translation helpful? Give feedback.
-
If you're considering GPL / AGPL, know that this goes against the spirit of open source / free (as in freedom) software. See this article for more info: Ask yourselves why you are going open source. Do you want to increase your users' freedoms? or are you doing it for marketing / as a way of getting more users by ticking the "open source" checkbox? If you don't care about the user freedom perspective, then a non-commercial source available license might be for you. But I recommend GPL for the clients and AGPL for the sync server as a way to maximize the freedoms of your users and any fork's users. |
Beta Was this translation helpful? Give feedback.
-
Or the third option, to allow external contributions to Notesnook :) |
Beta Was this translation helpful? Give feedback.
-
|
Giving users the right to distribute their Notesnook contributions to others does increase their freedoms 😄 It's also required under the OSI's definition of "open source" [1] and the FSF's definition of "free software" [2]. [1] https://opensource.org/osd#derived-works |
Beta Was this translation helpful? Give feedback.
-
|
I have updated the announcement with decisions regarding licensing & everything else. Thank you everyone for your input! |
Beta Was this translation helpful? Give feedback.
-
|
I have done a post in LinkedIn yesterday, I have more then 2000 contacts there and the post has been seen more than 5k times so far, hope it helps. I think linkedin and reddit are good places to spread the voice (for free). Regarding "Anything else we should consider before/after going open source.", I think Notesnook is great but maybe I would give more "look and feel options" for the end users, most of end users choose software depending on how it looks more than the features it has. Anyway, all the best for the Notesnook and the ppl behind. |
Beta Was this translation helpful? Give feedback.
-
|
I have been spreading the word to the privacy community, and people are genuinely interested so far! I also wanted to bring attention to this discussion, as it is related to Notesnook open sourcing: #719. As I said in this discussion, changing the Pro subscription to pay for storage/sync would be more reasonable (more in the spirit of libre, free as in freedom software) and better protection for the company (to prevent forks that remove the paywall) as opposed to having customers pay for actual features such as organization and editor features. |
Beta Was this translation helpful? Give feedback.
-
|
It's finally been done! Notesnook is now fully open source! |
Beta Was this translation helpful? Give feedback.
-
|
Congratulations! All the best |
Beta Was this translation helpful? Give feedback.
-
|
I am an ignorant non-techie who had just made the switch to Joplin as i am degoogling all I can. Are there features and attributes in Notesnook that make it a better choice than Joplin? Thank you. |
Beta Was this translation helpful? Give feedback.
-
|
@quicksite Notesnook has a more plug-and-play experience you'll be used to. For example, Joplin's mobile experience is severely lacking compared to their desktop clients. Similarly, syncing is not the default — they offer it as Joplin Cloud which needs to be setup. I think you can also set up something of your own for this. Notesnook on the other hand gives you everything in a very easy-to-use & safe way. You don't need to do anything to get sync working, encryption is on by default, all the clients on all the platforms have 99% feature parity (so if it works on mobile, it'll mostly work everywhere). The other thing that makes Notesnook a better choice is that it is primarily self funded through subscriptions. Joplin has Joplin Cloud but it is not their primary offering. We actually prioritize that users purchase our Pro plan which makes us less likely to shutdown Notesnook in the near feature (on the same line, Notesnook has crossed $2K MRR). And it also allows us to work full time on making Notesnook better. In the end, the decision is yours. In my opinion, Notesnook is quite superior to Joplin (with all due respect). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks very much that was very helpful. That's the very thing I was stuck on is figuring out the whole cloud sync issue. Follow up question: does notesnook having ability to import Apple notes? I already exported my Apple notes last night using the Mac app store's Exporter app. I am so ready to dispense with Apple notes because I'm a Mac guy who uses Android phones, but of course Apple maintains their wall of fortress to prevent Android users from having a mobile client. Thanks again |
Beta Was this translation helpful? Give feedback.
-
|
If they are in markdown or HTML, you can use our Importer: https://importer.notesnook.com/ If it's in some other format, you'll have to send over an example so I can add support for it. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to be that guy, but you might want to clarify whether it's "GPL 3.0 only" or "GPL 3.0 or later". I see you are using the "GPL-3.0" identifier in some packages and that is officially deprecated in favor of "GPL-3.0-only" or "GPL-3.0-or-later". notesnook/packages/core/package.json Line 5 in b840274 Thanks either way, this is great! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for letting us know. Will update this asap. |
Beta Was this translation helpful? Give feedback.
-
Notesnook is officially going open source in August!
To that end we want to use this discussion thread to:
Agenda & decisons
First of all, thank you everyone for your contribution & your help in guiding us! After listening to everyone in this discussion & everywhere else, these are the decisions we have arrived at:
License
I am glad we asked the community's help in this because I for one have 0 experience with choosing licenses. After everyone's input (especially @HyphenSam @itchychips @TheMatjaz @ssddanbrown & @tannercollin), we have decided that the best way forward for Notesnook would be GNU GPL licenses. There are a couple of points I want to touch regarding this particular decision (I'll keep it short, promise):
Freedom
As someone who has extensively benefited from the FOSS ecosystem (Linux, KDE, Firefox, Chromium etc.) it'd be extremely hypocritical to infringe upon our users' freedom just for the sake of a monopoly. Drew Devault's article especially helped in making me realize this. Open source (& FOSS) is about you & everyone else. I believe this is the way forward for Notesnook & it's users & contributors.
I am aware that this will allow someone to resell a modified version of Notesnook but I think that's part of what makes OSS so amazing. I know this means sacrificing on some of our original points (less fragmentation etc.). In conclusion:
CLA
To avoid many complexities with contributing in an open source project, some form of agreement between the contributor is necessary. We are not going the CLA route as it basically extorts the hard work of contributors. Instead, Notesnook will go with a simple DCO which will allow everyone to freely contribute without fear that their contribution will one day be part of a proprietary software.
We want to maximize our users' & contributors' freedom & rights so that Notesnook can grow as a community.
No going back
The DCO ensures that we won't one day close the doors and become a proprietary product again like Elastic, Redis etc. This is very important to earn the trust of our users & contributors.
Self hosting
Self hosting will be allowed & 100% supported.
Repo structure
After much thought, I think the best way to encourage contributions & be most efficient in delivering value is to go the monorepo route. This may deter some so here are my thoughts:
After the above decisions, I have marked off items that have been completed. Feel free to comment on everything else:
What license should be used?Monorepo vs. repo-per-packageShould we open source the sync server? What would be the pros/cons of that?Guidelines
Roadmap
TBD
What's going to be open sourced?
Technologies under use
Beta Was this translation helpful? Give feedback.
All reactions