hebcal / hebcal-js

⛔️ DEPRECATED - a perpetual Jewish Calendar (JavaScript)
GNU General Public License v3.0
123 stars 40 forks source link

I'm not sure that the GPL means what you think it does. #14

Closed MosheBerman closed 9 years ago

MosheBerman commented 9 years ago

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, 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!

dsadinoff commented 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

Scimonster commented 9 years ago

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.

MosheBerman commented 9 years ago

@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?

screen shot 2014-12-03 at 6 59 43 am

dsadinoff commented 9 years ago

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

MosheBerman commented 9 years ago

Right, that's what I meant. Why are closed source projects excluded?

dsadinoff commented 9 years ago

The "We" in the GNU FAQ is probably the Free Software Foundation. Or perhaps just Richard Stallman. Either way it's not a judge.

MosheBerman commented 9 years ago

:smile:

Fair enough, but it's your software, not Mr. Stallman's. Why did you choose GPL over LGPL or even a custom license?

dsadinoff commented 9 years ago

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.

dsadinoff commented 9 years ago

AAAnyway, I think we can agree that this issue is resolved. The GPL is not the LGPL, no matter what github says.

MosheBerman commented 9 years ago

Got it. Thanks.