Hi Bruno, Commercial involvement with Mayan is not a problem at all, it is encouraged and the license was changed a while back from GPL to Apache 2.0 to be more commercial friendly.
Forking and doing specialized versions is not bad and I encourage it, it is the way FLOSS projects grow. If a feature can then be added upstream, we do so, if not, it is made into a 3rd party app or sub project (http://www.mayan-edms.com/ecosystem/). In this case Ranjith offers a customized version with features that we have not been able to included because they are very specific to him and his clients. Your concerns are not unfounded either. We had some troubled a few years back (http://www.theregister.co.uk/2012/08/28/mayan_edms_gpl_violations/), but unlike forks these were appropriation (hostile takeover) attempts that included copyright and license violations. For the whole breakdown read here: https://web.archive.org/web/20150611092841/http://www.thepowerbase.com/2013/04/negative-to-positive-interview-with-mayan-developer-roberto-rosario/ In the end this became one of the case studies of the extent of rights of the copyright holders under the GPL license and served to educate many developers on the topic. On the other hand was Ranjith is doing is perfectly OK since there is no copyright violation and the terms of the license are being followed. The work he is putting into his fork of Mayan is helping the software get into other markets where the upstream version might not have been a choice. We've been talking and we are looking into backporting some of the more general work he's done in his fork. After 5 years Mayan EDMS is a well known brand, with a lot of users and installations, still, now there is an entity (Mayan EDMS LLC) whose primary focus is looking after the project. Brand protection is something that is now is being done consciously. Any more ideas how to keep the project growing and protected are welcomed. Thank you for your voicing your concerns, I hope this shine some light into your preoccupations. --Roberto On Saturday, May 14, 2016 at 4:10:30 PM UTC-4, Bruno CAPELETO wrote: > > Dear Ranjith, > > I do not really understand why at such an early stage of an opensource > project there is already a forked version. > > What is your intention behind ? Is it just to get new functionnalities > faster, or to really have a separate software in the end ? > > The strategy is very important for the fate of an opensource project, and > I would also like to know Roberto's thoughts about this. > > Cheers, > Bruno > > > Le mercredi 27 avril 2016 14:22:29 UTC+2, ranjith pillay a écrit : >> >> Hi, >> >> We have tried to make workflows practicable in Mayan in our forked >> version. Please feel free to use it. >> https://gitlab.com/ammaranjith/mayan-edms >> >> Thanks, >> Ranjith >> >> On Sunday, April 10, 2016 at 4:27:33 AM UTC+5:30, Bruno CAPELETO wrote: >>> >>> Dear Roberto, >>> >>> Third night I am spending on Maya EDMS and it is so promissing ! >>> Congratulation to you ! >>> >>> In order to test it I am trying to implement the workflows of my own >>> company, and there are several comments I would like to address (is it the >>> right place here ?) : >>> >>> - the documentation is too short and too advanced : I have a great >>> experience in Linux but not in python, and it was difficult for me to set >>> it up. To enforce the awareness of your software, we should make it >>> accessible to others than specialists in Linux, python and programming. >>> Especially it must be available to entrepreneurs who have concrete examples >>> to manage. By the way, I would be glad to contribute to the French >>> translation (how can I do ?) >>> >>> - the "Actions" menu must become more convenient : for example to add a >>> metadata after scanning, one has to view the document, go to the "metadata" >>> tab, then "Actions" and at last add metadata. Even then, it is cumbersome >>> if one has several metadata to fill in. >>> I suggest at least the "Actions" menu to become an option submenu when >>> passing over with the mouse. >>> >>> - Still after scanning, there is a great function to fill the missing >>> metadata ; again, this option is hidden. I suggest that, as soon as a >>> document enters the system via a watch folder and is missing metadata, >>> there is blinking icon "set metadata" inviting the user to set the >>> metadata. The content of the metadata may even be suggested. For example a >>> document type "Bill" can have a "Supplier" metadata. For each possible >>> value of "Supplier" like "EDF" (a French electricity company) an associated >>> list of keywords to detect via OCR would help to suggest the best value for >>> a list metadata. >>> It is essential to easily assign metadata to incoming documents so that >>> they can be classified. We still cannot rely completely on OCR :-( >>> >>> - Autoincrement variables : that would be great (and a must) to link >>> different document together. For example I have an order (let's say number >>> 001) and I want to be able to link all the related documents to that order. >>> I need to set somehow this 001 to a metadata in the other documents. This >>> kind of variables could be assigned to a document type. Or "autoincrement" >>> could be a property of a metadata for a given document type, and a choice >>> list for the other document types. Another possibility would be to easily >>> see the original document's uid. >>> >>> - workflow is a good start with the possibility to give the status ; >>> however I was not able to exploit this functionality at all (that was the >>> subject of my recent post). At least one should be able to classify the >>> document based on the state of the workflow via the indexes. >>> >>> - I love the "Indexes" concept >>> >>> Hope that feedback can help to improve the product. >>> >>> Cheers, >>> Bruno >>> >>> >>> >>> >>> >>> >>> >>> -- --- You received this message because you are subscribed to the Google Groups "Mayan EDMS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
