Closed MosheBerman closed 9 years ago
On Wed, Dec 3, 2014 at 3:49 AM, Moshe notifications@github.com wrote:
According to GitHub's ChooseALicense.com http://choosealicense.com/licenses/gpl-3.0/, the GPL only requires that closed source programs disclose the source of the library covered by the GPL.
Not sure who told you that. Where, exactly does GitHub say this? You may be thinking of the LGPL.
http://en.wikipedia.org/wiki/GNU_General_Public_License#Compatibility_and_multi-licensing
from the GNU FAQ:
What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation http://www.gnu.org/licenses/gpl-faq.html#MereAggregation)
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
——— Danny Sadinoff danny@sadinoff.com
From the very last paragraph of the GPL:
The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read http://www.gnu.org/philosophy/why-not-lgpl.html.
~Sci
On Wed, Dec 3, 2014 at 3:49 AM, Moshe notifications@github.com wrote:
Hey,
I've ported KosherJava to Objective-C so I'm happy to see a similar library available in Javascript. I'm just not sure that you're reading the GPL correctly.
Remember, the GPL means you can't use this in a closed-source program!
According to GitHub's ChooseALicense.com http://choosealicense.com/licenses/gpl-3.0/, the GPL only requires that closed source programs disclose the source of the library covered by the GPL.
If you specifically don't want to allow people to use hebcal-js in a closed source app, that's your decision, but you might be running into a GPL issue yourself.
Great work!
— Reply to this email directly or view it on GitHub https://github.com/hebcal/hebcal-js/issues/14.
@dsadinoff I GitHub runs ChooseALicense.com - it's there. Screenshot below. (Also, who's "we?") Perhaps GitHub is wrong, but I'm not making this up. EDIT: I missed the clause that reads "in the case of the LGPL..." MY question still stands:
Also, Is there a specific reason to exclude commercial projects from including hebcal?
Yes, it says "in the case of LGPL". Hebcal is released under the GPL, not the LGPL. Not sure why github would talk about the LGPL on a page devoted to the GPL. I can see how that would be confusing, but that's Github's oddity.
Also, Is there a specific reason to exclude commercial projects from including hebcal? Commercial projects are not excluded. Closed-source projects are.
http://en.wikipedia.org/wiki/List_of_commercial_open-source_applications_and_services
Right, that's what I meant. Why are closed source projects excluded?
The "We" in the GNU FAQ is probably the Free Software Foundation. Or perhaps just Richard Stallman. Either way it's not a judge.
:smile:
Fair enough, but it's your software, not Mr. Stallman's. Why did you choose GPL over LGPL or even a custom license?
Why did you choose GPL over LGPL or even a custom license?
Hebcal is derived from other GPL'd software, as described in the README, so there was never a decision to make, or rather, I decided to derive it from existing GPL'd software, and then the license flowed from that decision.
AAAnyway, I think we can agree that this issue is resolved. The GPL is not the LGPL, no matter what github says.
Got it. Thanks.
Hey,
I've ported KosherJava to Objective-C so I'm happy to see a similar library available in Javascript. I'm just not sure that you're reading the GPL correctly.
According to GitHub's ChooseALicense.com, the GPL only requires that closed source programs disclose the source of the library covered by the GPL.
If you specifically don't want to allow people to use hebcal-js in a closed source app, that's your decision, but you might be running into a GPL issue yourself.
Great work!