Potential use in proprietary products

[edescourtis]

I was wondering if there would be a way to integrate this software with a proprietary product?

Do you have a commercial license or could this be used as a library somehow?

[brianharvey]

Snap! is distributed under the AGPL, which means that anyone can use it, but the resulting product must also be AGPL -- distributed with source code and licensed to anyone under the same terms.

[edescourtis]

Okay understood so you do not have dual licensing for it.

I guess Google Blocky does what I want.

[bb010g]

I believe you could build a program under your chosen license that interoperates with Snap!'s export format, however.

[jmoenig]

@edescourtis can you tell us more about what you'd like to do with Snap? I'm sure we can find a way to let you do it (I am, after all, a fully qualified lawyer). Thanks!

[introlinux]

@edescourtis You can incorporate Snap! to other products and distribut it commercially with no problems and no extra licenses only if you don't modify it. If you modify it you only have to share the code of the new snap version.

[jmoenig]

@introlinux @edescourtis that's right. But my point is that I'm not going to let some licensing rabulism stand in the way of letting interested developers make use of the Snap source code in reasonable ways. Personally I couldn't care less about the license, and I'm perfectly willing to allow exceptions if somebody so makes their case...

[edescourtis]

@jmoenig I wasn't aware of Blockly when I asked the question. I was looking for a user friendly way that non-programmers could program parts of a system (such as a callback or routing decision) this allows us to get much better flexibility without increasing the complexity of an application.

In any case I wanted to compile down to Elixir and Erlang as a target so I would probably have to extend it. I have no problem redistributing my changes however. What would be the benefit of using Snap! vs Blockly?

[brianharvey]

@jmoenig I care about the license! It's not an issue of commercial vs. non-commercial; the point is that if they invent some generally useful feature, the rest of us should get to use it. Imagine how you'd feel if someone like Bernat demoed a Snap! extension and told us we couldn't see the code. That's what the GPL is meant to prevent. But since @edescourtis says he's willing to redistribute his changes, we don't have to argue about it.

@edescourtis The advantages of Snap! are (1) we have lambda; (2) we already have a feature to translate Snap! scripts into whatever programming language you want. (See the project "Codification" in the examples library.)

[birbilis]

Problem with gpl is they have to distribute the source of the rest of their system if they use any GPL code in it! That's why MS is calling it viral. GPL v2 with classpath extension was a workaround but GPL v3 was made to close such backdoors

Stallman from GNU has this vision of free systems where you pay for consulting but this is in favor of big companies with good logistics. Single programmers can't follow this path if they want to make a living writing code and selling apps instead of becoming trainers

[birbilis]

Truly liberal licences are MIT, New BSD, MSPL in my opinion. People will give back if you trust them. They'll decide which parts to give back in their own schedule (internal code needs cleanup often, esp if a prototype was rushed and then extended)

[birbilis]

Haven't checked snap!'s codegen feature yet, would be nice if it could do AST->XML (with a snap! XSD Schema) and then from that via XSL to various other languages, so that you could add more such stylesheets

[brianharvey]

I think probably this is the wrong forum for a debate about free software in general. But in the case of Snap!, we're not talking about someone putting a snippet of our code into their vast Microsoft-scale project; we're talking about people building a small extension to what is essentially still mostly Snap!. So I don't think Microsoft has to worry about us, and I do think that we're right to want any such extensions to be available to all.

[jmoenig]

@brianharvey I understand and mostly agree about the license. That said, I'm flabbergasted by the fervent debates the open-source community loves to engage in around legalities. In fact, I occasionally have the impression the community is more about discussion legalese than writing (and sharing!) code. That's why I'm saying:

Tell us what you want to do with our code, we'll find a way for you, even if the current license might appear not allow it.

There your are, @edescourtis ! Tell us about your project, and we'll make the license work for you. I'd much rather discuss projects than contracts, especiall if the discussion is only theoretical, as happens most of the time when there isn't even a project :-)

[birbilis]

I think they already said they want to add some visual scripting inside a (proprietary I guess) product. With GPL they'd be forced to release the source code for their own product too (that's the "viral" [and "sneaky" in my opinion since not all people speak legalese] nature of the GPL license)

Not sure if Blockly that has been mentioned has a more liberal license or a dual license as some GPL v2 projects have (I think GPL v3 was made to also exclude the dual license scenarios) that the users can choose

[birbilis]

the text for various "approved" OpenSource licenses is available at http://www.opensource.org e.g. here are the ones I referred to above as more liberal ones (also appropriate for using in commercial closed-source software - and I mean the rest of the software product, not necessarily the original or evolved opensource modules included): MSPL: http://opensource.org/licenses/MS-PL MIT: http://opensource.org/licenses/MIT New BSD: http://opensource.org/licenses/BSD-3-Clause

[birbilis]

just checked, Blockly has Apache license: https://github.com/google/blockly/blob/master/COPYING

[brianharvey]

@jmoenig It's only @birbilis who wants to have a tendentious argument, because he hates free software (the whole notion of "open source" was designed as an explicit attempt to kill free software, and that's why opensource.org defines it as they do).

@edescourtis has already said that his use will be conforming:

I have no problem redistributing my changes however.

so there shouldn't be a problem. But, Jens, if he were saying, e.g., "I want to use Snap! in an industrial-scale programming system, and so I'm going to make it run 100 times faster, keep my code secret, and sell the result" then imho you should not say "we'll find a way to let you do it." You should say "NO, you cannot arrogate our work into a product that will not be freely available to everyone."

But there is nothing in the GPL that would prevent us issuing a specific license to a specific person or organization on different terms. The GPL just says what the terms are that people can use without asking us. @edescourtis, properly, asked us for permission, you said yes, I agree (in this case, although I strongly disagree about overgeneralizing as you are doing in this discussion), and so everyone except @birbilis, who wants to pick a fight, is happy, and I'm closing this thread.

[birbilis]

Never meant to put up any fight. This is the legal situation. If they use GPL code (even in the form of dynamically linked library) in their product ANY user can ask them to release the sourcecode of all of their product. I use MIT or New BSD in my opensource projects btw

[birbilis]

GPL v3 doesn't allow dual licensing if I remember well. If you know better, please correct me (might remember wrong)

[birbilis]

Did some reading, from the following wording seems that under GPL v3 you could issue separate license on a case by case basis (but not dual license with user picking the license they need)

"You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable Section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it." http://en.m.wikipedia.org/wiki/GNU_General_Public_License

[Alwahsh]

Hi everyone,

Not sure if I should open a different issue but I'm having a very similar problem. I'd like to integrate Snap!(may be after some small modifications mostly to the look) into some system. Modifications to JavaScript would definitely be seen by anyone dealing with them(it's JavaScript so they can normally see the file). If I understand correctly, I now have to show the whole code of the system(including back-end code which is not in JavaScript) to everyone which I can't. It's not quite clear what's allowed and what's not allowed. The best case for me would be to allow me to integrate it into any page without restrictions and without forcing me to show the code that generated that page. If you don't want to provide me with that, although that would limit me, would it be OK If I make all pages that show Snap! show only Snap! in the whole page but deals with the system through cloud.js file? In this case do I have the right to not show the whole code of the system? Thanks

[bb010g]

@Alwahsh Snap! is licensed under the AGPLv3, which means any modifications to the source that are used over a network (or anything else covered under normal GPLv3) must be provided upon request. If you are making modifications to Morphic.js that are used, those must be provided. If you make it interface with a backend, you don't have to LGPL the backend as long as you don't link it (read: directly call Morphic from your backend), but instead communicate through some sort of protocol.

[birbilis]

Some were saying dynamic linking was an exception at older GPLs, but v3 I think makes it same as static linking. Communicating via data protocol instead of RPC could be ok, maybe RPC is ok too, but not sure about GPLv3's wording. That's the problem with placing constraints, others get uncomfortable by not being sure if they're ok. Prefer licenses that just ask for due credit

[bb010g]

  5. Conveying Modified Source Versions.

  You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:

    ...

    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.

    ...

  A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit.  Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.

It ultimately depends on how "seperate and independent" your work is. However, Morphic.js is not designed to use plugins, and I'm pretty sure your interfacing code would fall under static linking, as it is an "extension of the covered work".

As for @birbilis's note about communicating via data protocol, I'm going to direct you to the FSF's GPL FAQ:

What is the difference between an “aggregate” and other kinds of “modified versions”? (#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.

Considering your interfacing code would probably just be passing around general, simple GUI commands, you should be fine.

That's the problem with placing constraints, others get uncomfortable by not being sure if they're ok. Prefer licenses that just ask for due credit

@birbilis, if @Alwahsh wants to know about your opinion about the GPL, he can read the rest of the thread. Also, stop spreading around FUD. It took me 5 minutes to check Wikipedia, see where it references the FAQ, check the FAQ myself, and find a definite answer, not just say that something "may be ok". This project is not realistically going to be moved to a different license (besides any future AGPL if @jmoenig feels so inclined) because every contributor would need to be contacted (or have their contribution removed) and consent to a relicense because Snap! does not have a CLA.

Just for kicks, you can dual license the GPL. There's nothing in there saying you can't, and projects like MongoDB are examples right now.

[Alwahsh]

Thanks for clearing things out. I'm afraid I'm still a little bit confused... I believe any file that would be directly dealing with Snap! would definitely be JavaScript or HTML running in the client's browser, so by default, everyone who uses any modified version of Snap! would be able to see the modified source code. Now for the backend. Let's say I make a very simple website that contains a customized version of Snap! and has its own authentication system. Do I have to show the code of that full website with how authentication is done(since Snap! talks to it through cloud.js)? If I use some authentication system that has a different license, then I can never use it with Snap! for example? Thanks

[bb010g]

(Feel free to correct me if I misread what you were asking.) Any modifications to Snap! itself are of course AGPL. Your backend consists of an authentication system for what I'm guessing to be user accounts and a Snap! Cloud equivalent. What I would do is just PR here to allow for more generic Cloud servers (different auth types, servers, etc.) and then just hook up your backend. They're not tied together enough to bring your Cloud server under GPL.

[Alwahsh]

Yes, that's what I meant. Do I have to PR here to allow for more generic cloud servers? I mean, in case I modify cloud.js to just handle my server authentication system, do I have to give away the whole server code in that case or just the modified cloud.js is enough? Could you give me an example of something that has to be AGPL although it's not written in HTML or JavaScript if possible? Thanks a lot for talking the time to help :smile:.

[bb010g]

No problem.

If you modify cloud.js, those modifications are under GPL. You don't have to put them in a pull request here, but I was thinking it wouldn't hurt. Others who also want to host their own server may improve on that code, so we all benefit. Again, the server-side code is not being an aggregate with Snap!, but rather just an independent program that follows Snap communication conventions and does not require the Snap! code proper to function.

Nothing has to be AGPL, but an example of a non-JS AGPL project is Launchpad. It's written in Python, but it's a web application, so they chose to use AGPL.

[brianharvey]

Jeez, you guys! Make things simple why don't you.

We ourselves use a proprietary back end cloud server, not to serve Snap! itself, but to store and retrieve people's projects. (Miosoft volunteered their services and their disk space!) We're not going to object to anyone connecting Snap! to their own back end.

The reason that we AGPLed Snap! is that we want any improvements to the language to be available to everyone. I'd have to know more about your business to know whether I think you're proposing an improvement to the language, or an unrelated use of the language.

For example, Edgy (http://www.snap-apps.org/edgy.html) is an extension that lets Snap! draw graphs using the D3 library. We'd be upset if its developers wanted to keep their code secret.

Can you be more specific about what you actually intend?

[Alwahsh]

Yes, of course I understand that I should do a PR when I do an improvement to Snap! which I'm planning to do whenever I make an improvement that I find suits you. What I was talking about is if I implement the back end in some way that's not really general so the modifications to cloud.js would most probably not be merged if I make a PR here(because it's very customized to my needs). I was looking for an example where using Snap! can force you to provide source code of something you write in a language other than HTML + JavaScript because I can't find a case like so.

[bb010g]

Again, that's perfectly fine. I've said multiple times that a separate backend that does not require Snap source code to run would not be under AGPL. As for making the source available, just fork Snap and keep it under your account.

[Alwahsh]

@brianharvey That suits me very well I believe but I wonder why is AGPLing necessary for a JavaScript project. I can't think of a way that Edgy could've kept their code secret except if they don't allow anyone to use their application(which I believe the license still allows). What I understand is that AGPL implies that whoever uses the application has the right to see the source code which I believe is always the case if your project is in JavaScript where object code is actually the source code. I was just afraid that the backend itself has to be AGPL if I use Snap! but now things are pretty clear thanks to @bb010g and you. Thanks for your help everyone, I appreciate it :smile:

[brianharvey]

I don't think the programming language used has anything to do with it. If someone hasn't already invented a way to compile JS to machine language, they will sooner or later.

Even frontend vs. backend is only partly determinative, imho. If you implement a back end to extend the capabilities of the language (e.g., your back end implements FFT, and you add an FFT block that works by making an HTTP request to your back end), then I want it. But if your back end does FFT for some reason other than extending the language, and you write a Snap! extension that is one of many ways to interface with it, that's no problem. I'm not a lawyer, but to me the right place to draw the line is this distinction about the purpose of your back end.

[bb010g]

@Alwahsh It's not that they could keep their code secret with JS, but that they could legally go after modifications. Edgy has the right to modify Snap!, and anyone has the right to modify Edgy. If Snap! wasn't FOSS, Jens or Brian could just go sue the authors.

[Alwahsh]

Ah! I understand what you mean. That's totally fine with me. If I introduce any improvements or extensions to Snap! itself I would happily share them(even if the license didn't force me to) :smile:.

@bb010g that makes sense.. So the use of AGPL here prevents Edgy authors from suing someone who makes modifications to Edgy... If no AGPL, although users could see the code, they can't modify it. I missed that part.

[birbilis]

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide.

I find the mention of judges there quite unsettling, but it might be just me of course

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.

from what I understand by this text if your backend part only has a reason of existence when combined with the specific frontend, then you get the same license. I'm not a lawyer but I prefer lawyers and judges stay away from my science field if possible

I understand it's hard to change license now, but one should carefully take that in mind since any third part can ask for the license to be enforced (get handed over your private code - if you have something you do want to keep private that is). Or ask for a separate license for your specific use. Even when a dual license is not permitted for general use, it is permitted to be issued separately (say in GPL v3 from what I've understood from previous discussion on this)

[bb010g]

The complex data structure exchange implies that you couldn't feasibly use the other program without the main GPL'd program. You could feasibly write a Snap! Cloud client independently of the Snap source itself.

Possible enforcement is the whole point of the license, otherwise it has no value.

To commercially dual license Snap! now would be rather infeasible. All contributors would need to give permission to the maintainers to sell commercial licenses, and probably sign a CLA to allow changes after that, as well as have all new contributors sign one. Dolphin Emulator took months to do this for just a transition from GPLv2 to GPLv2 or later. Admittedly, it's a bigger project, but it also didn't need to convince everyone that they should let the maintainers decide who can work on Snap! in a proprietary manner.

[cycomachead]

I'm not a lawyer but I prefer lawyers and judges stay away from my science field if possible

Unfortunately, we've had a lawyer involved with Snap! for the past 6 or so years... So far, it's been pretty good! :grin:

But like Brian says, I think it's all being over thought. We care about improvements to Snap!, but external stuff is your call. Also, no one here wants to stop cool or beneficial projects from happening. If there's specifics it's best to email Brian and Jens directly (if they can't be shared publicly).

---

(Random tidbits, not entirely relevant to the topic at hand.)

I don't think the programming language used has anything to do with it. If someone hasn't already invented a way to compile JS to machine language, they will sooner or later.

Your browser goes through various levels of doing this for every web page.

Even frontend vs. backend is only partly determinative, imho. If you implement a back end to extend the capabilities of the language (e.g., your back end implements FFT, and you add an FFT block that works by making an HTTP request to your back end), then I want it. But if your back end does FFT for some reason other than extending the language, and you write a Snap! extension that is one of many ways to interface with it, that's no problem. I'm not a lawyer, but to me the right place to draw the line is this distinction about the purpose of your back end.

Note that in a case like this, with a "back end" - someone (us or anyone) likely couldn't claim that all of your backend is relevant to Snap!. Even if the FFT example, we'd have little reason to claim that communication over HTTP is Snap!-only since every webapp in existence uses HTTP. The "why" is a little hard to determine. Also, since most software is compoentized, the webserver part of a project is almost certainly not unique and not terribly exciting, but code that webserver runs or the services themselves could be Snap! specific.

I'm trying to come up with a slightly better example of some separation, but let's say you had a new back-end that did static analysis of Snap! XML / ASTs and stored project code. We'd love to see your whole system, but only the actual XML parsing / analysis would apply, since project storage implements an API which is not necessarily Snap!-specific.