Closed tenzap closed 2 years ago
I don't know what discordant
is, but this project has a license file
I've added "do no sell this code" to the license, to be CLEAR.
No selling of Tagify, is allowed, no matter the amount of re-branding & code modifications.
Are you asking because you want to make profit of Tagify in some way?
I'm asking because I would like to use it in another project (kalkun) and was wondering if that sort of notice do no sell this code would actually prevent inclusion into Debian (either through kalkun package which would include it, or through tagify package) or other distributions.
For example I know that the "The Software shall be used for Good, not Evil. " note of json license implies this: →
I didn't understand much of what you've said, but are you an open-source contributor wishing to add Tagify to this kalkun project, and kalkun project is offered for free?
Hopefully it will be more clear this way:
One fact:
One question:
BTW: kalkun is gpl3 licensed...
The license file says:
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
Your header file doesn't mention MIT, neither any license except do no sell this code:
/**
* Tagify (v 4.9.8) - tags input component
* By Yair Even-Or
* Don't sell this code. (c)
* https://github.com/yairEO/tagify
*/
This in my opinion is contradictory.
I also think the license in the source file takes precedence which would mean the license and usability is unclear.
Both are applied together as I see it. my own comment is just an extension to the current license.
I will edit the LICENSE file to include it, so it's clearer. Why are you saying JSON license all the time? it's in the format of a text and there is nothing "json" about it
Thank you. Could you also clarify the headers of the files? They don't mention MIT at all.
I ended up asking on the debian-legal mailing list. I got an answer and it seems your license isn't DFSG compliant (more info on debian and wikipedia). That's unfortunate.
Why are you saying JSON license all the time?
It seems Json is also a package ;)
Cited from the links I posted above:
JSON package is licenced under a MIT license but with an additional infamous clause:
The Software shall be used for Good, not Evil.
This license is considered non-free by Debian, [GNU Project](http://www.gnu.org/licenses/license-list.html#JSON), [Fedora](http://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses), [Google](http://wonko.com/post/jsmin-isnt-welcome-on-google-code), [Red Hat legal](https://bugzilla.redhat.com/show_bug.cgi?id=455507), [Free Software Foundation](https://www.gnu.org/licenses/license-list.en.html#NonFreeSoftwareLicenses)
The author [Douglas Crockford is well aware](http://en.wikipedia.org/wiki/Douglas_Crockford#.22Good.2C_not_Evil.22) of the harm he's doing but numerous request from different projects and parties could not change his mind.
Thank you. Could you also clarify the headers of the files? They don't mention MIT at all.
Anyone who is serious about knowing license will go straight to the GITHUB page and look for the LICENSE file. commented headers are not a "must"
it seems your license isn't DFSG compliant
am not familiar with DFSG
... what changes are required for Tagify to be compliant?
From my little experience, when creating a new package for inclusion in Debian one has to check the copyright of all files to fill a debian/copyright file that is very detailed down to file level (the licence & copyright info is at file level if things are not consistent). File level license has precedence over project level license AFAIK. Then, in the process of submitting a new package to official Debian repo some people of Debian team will check everything again. You may see comment 5 here (at the bottom of the page) for a package I submitted for review → I was told: whoever sponsors this should check those files one by one, and so should do any FTP master member...
Concerning DFSG a fast introduction might be the DFSG wikipedia page I reference above. Then the DFSG page at debian wiki
You may also jump in to the conversation on the debian-legal@lists.debian.org mailing list by participating to the thread I started. (you don't need to subscribe to the list to post). It is very likely you will get there a rather accurate answer.
Cited from the followup on debian list
Given the usual disclaimers that I barely speak for myself, let alone anyone else, that I'm not a member of the Debian and my opinion is worth precisely what an anonymous voice on a mailing list says...
The usual recommendations are to pick a standard OSI compliant license and not customise it. Using a standard license makes life easier for users because they don't have to think about the implications --- everyone already knows what BSD licenses, GPL licenses etc mean. My usual analogy is to suggest thinking about it like an API. https://choosealicense.com/ is a good resource here and gives reasonable advice.
I'd suggest that if the author is concerned about people using their work commercially, then the author should look at the LGPL: this will make it easy to for users to use the library in another program, but will require that if the user modifies it or base work on it, they have to distribute the modified source.
well, what can I tell you.. I don't want to change Tagify's license because I want to clearly forbid people re-selling it. I have been working super hard on this code and had enough of people selling my open-source stuff online, earning tens of thousands of dollars while I do this for free (willingly).
I understand. Although Tagify is great, for my part I prefer to search & use an alternative.
Please, at least make the LICENSE file and the headers consistent. I think you should probably also remove the and/or sell copies of the Software part of the license, what IMO would result in your software NOT being MIT licensed anymore.
Some additional information was posted on the mailing list.
Hi @tenzap! Have you found a good alternative eventually?
I ended up adapting the component we already used: https://github.com/underovsky/jquery-tagsinput-revisited
@yairEO, I think you should remove the MIT shield from the readme because you clearly intend not to use the MIT license.
In the same vein, you should harmonize the text and remove the section that allows selling the code, as was mentioned before.
I also wanted to intent you have with the derivation from the MIT license. Do you just want to prevent someone from taking your code, rebranding it, and selling that, or do you also want to prevent your library from being used as part of a commercial application?
Do you just want to prevent someone from taking your code, rebranding it, and selling that, or do you also want to prevent your library from being used as part of a commercial application?
The first thing - I don't want people to sell my code as-is or re-branded. such a thing happened to me before (with another open-source project of mine) and had pissed me off tons.
This component is meant to be used in a part of a (much) larger system and I don't care if that system is generating money or not, because that is the common use case for web components, but I just want to be covered by the law in case I catch someone else selling my software as the main component of a package or as part of some components bundle they gathered from the internet and are selling as to be used as components.
I guess you get my point at this
I am making lots of open source, free of charge, as a hobby, for many years now, and it is meant to be kept free. it hurts me twice the profit someone is doing on over my hard work and also the shame my own code is being sold for money when it shouldn't be. pimped away.
@yairEO would you be amenable to change the line https://github.com/yairEO/tagify/blob/9bd64ed14cb951b27fb23e3bae2bef7f58128ee0/LICENSE#L19
to
This Software may not be rebranded and sold as a library under any other name other than Tagify or as part of another library.
why?
Because the current line is overly broad and makes our legal team uncomfortable, and as you stated:
This component is meant to be used in a part of a (much) larger system and I don't care if that system is generating money or not
you are fine with it being part of a large application that is being sold. The new text would clarify that distinction.
Maybe you could consider an alternative if the license doesn't fit. I did so for a website that targets inclusion in Debian because the licence is not DFSG (Debian free software guidelines)-compliant.
We already use it in our codebase, just with the last version that still had the unmodified MIT license. Replacing it would require work that could be avoided, even more so since we are happy with this library.
Tagify is licensed under MIT license.
However I noticed that in the headers of the files, for example tagify.min.js there is no reference to MIT license but the text "do no sell this code".
This seems discordant to me. Could you please clarify?