On Sunday 06 September 2009 01:47:36 pm rbuc wrote: > I understand that I can take the code to use on a webserver without > even letting you know it. But first, I wanted to kind of ask the > developers about their opinion about it I really appreciate that, thanks!
> > Konrad Wojas: If you want to stimulate people to use the code for > > websites and other application, make libmnemosyne LGPL and the GUI > > frontends GPL. Don't make the license even more restrictive, it will not > > foster innovation and it's not that hard to reimplement the algorithm. > > This goes more in the direction I had in mind. This way a lot of > products can use a common space repetition library and if they choose > to distribute their product, they would have to provide the source > code. Your hard work, mainly the GUI, would be protected. First of all, I need to clarify that libmnemosyne 2.x is much more than the scheduling algorithm, that's perhaps only 5% of it. It also contains e.g. all the GUI controller logic that is UI toolkit independent. Because most of the heavy lifting is done by libmnemosyne, I was able to write a Windows Mobile client in only a weekend. So, libmnemosyne is where the crown jewels are, not in the different front Let's take a look at the following (hypothetical) scenario: libmnemosyne is LGPL or GPL licensed, and ChinesePod takes up our code in their website, removes the uploading of logs and the ability to interoperate with other Mnemosyne clients. They don't even tell anyone they use Mnemosyne, and because of the extra value they have, they sell much more premium subscriptions. I fail to see how this would benefit Mnemosyne or Mnemosyne users... Of course, one could argue that because of the presence of libmnemosyne, innovation has been made possible by creating a new product. However, in this case this just sounds to me like a euphemism for letting thousands of hours of work, shared freely in the spirit of cooperation, be abused by people who have no intention to share... (Once again, we are talking about a hypothetical scenario here) I'd feel much happier with a AGPL license for libmnemosyne and a LGPL license for libopenSM2sync. That way, Chinesepod could provide an option to sync transparently with Mnemosyne. Granted, the integration would not be as tight, but there is still innovation, and both existing Mnemosyne users and Chinesepod users would benefit. Sounds much fairer to me... > My idea for all this research/algorithm-thing is: > - Create an open research project on Google App Engine that collects ... > - License the GUI under the GPL so nobody copies it. Let others build > software with the library and innovate further. May be you can then > intgrate some of the other innovations. Interesting scenario, however it does not really motivate me :-) The thing is, the amount of logs is already quite scary now. Last month I tried parsing all the logs with an improved parser, but after 1 week, there was a power cut, and I only was 75% through :-( Here is another scenario. You implement an AGPL licensed website based on libmnemosyne. It saves you a lot of time, because you don't have to reinvent the wheel. People will gladly pay for the service you provide, because they realise there are hosting and maintenance costs involved. Also the fact that your site can be verified to use exactly the same scheduler as their favorite SRS system is a big bonus for many users. The fact that data can be moved transparently back and forth between a website and a desktop client is also a big selling point, and provides added value, both for users, developers of the website and developers of the desktop app. Of course, the fact that the code of your site is freely available, means other people can run their own site, but you have first mover advantage and have created so much goodwill in the Mnemosyne community by your contributions means that you don't worry about that too much. However, I do understand if that scenario does not appeal to you. But even if you go for a completely closed solution, I suggest that you consider the option of implementing interoperability with Mnemosyne through the upcoming LGPL-ed libopenSM2sync library. I think there can be many mutual benefits. Anyhow, I welcome further comments by you, Konrad on anyone else on these issues. Cheers, Peter --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mnemosyne-proj-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mnemosyne-proj-users?hl=en -~----------~----~----~----~------~----~------~--~---
