Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It is almost as if JavaScript/WebAssembly need a sandboxing feature that allows a library to be LGPL (or GPL?) compatible - legally callable from your own JavaScript source code.

I wonder if a legal sandboxing feature could be designed, perhaps even misusing the technical words to munge the sandbox to be compatible? Misuse words like header file, Library, link, object code etcetera to make the sandbox legally compatible?



What does “need” mean? I think it would be pretty messed up for browsers to ship a way to legally embed GPL code within closed-source binaries.

In a sense, though, that feature does exist — it’s called an HTTP request.


Or IPC? Does WebAssembly have something like Web Workers?


Not a lawyer but I’m pretty sure you can’t circumvent the GPL just by running the code in a different thread.


It would be a different process, not a different thread. For example executing GCC from a proprietary IDE doesn't seem to be a problem.


It's a problem if your IDE is designed to work only with gcc. It's not a problem, if it could work with any compiler and gcc is just one of the options.


My understanding is that it matters whether the GPL software is distributed with your program. If your IDE installed gcc, you would have to license it as GPL — even if it also installed other compilers. (It would be fine for your IDE to use a preexisting gcc installation obtained in some other fashion, though).


If I was a copyright lawyer, I would probably take a dim view of a defense that amounts to "it's not using your client's code, it's using code that directly uses your client's code."


With WebAssembly, it's running in a separate virtual machine. If that didn't insulate it, there would be no reason for the AGPL.


My understanding of the AGPL and its history is that it was meant to close a perceived loophole with SaaS: companies selling you access to services built on GPL'd code were not compelled to distribute their changes.

The is significantly different a local virtual machine, of which the JVM is one: the code is still fundamentally being distributed to the client, which triggers the release clause in the original GPL. To the best of my knowledge, nobody has ever (successfully) claimed that executing JVM bytecode releases them from their obligations under the GPL.


What about GitHub Enterprise? Isn't that running it as a service, which happens to be located inside your machine?


That's a really good question!

Has anyone here used the self-hosted version of GitHub Enterprise? Did they really reimplement git?

Edit: Apparently GitHub uses https://libgit2.org/ which is "GPLv2 with a Linking Exception" (equivalent to LGPL)


My understanding of GHE is that it uses libgit2 internally, which in turn has a linking exception in its license (just like GCC and glibc). It’s unlikely that they’re violating GPL in that particular way.


GitHub Enterprise is proprietary software. To the best of my (external observer's) knowledge, it has no GPL code in it. If it does, then that's probably a licensing violation, but IANAL.


As I (not a lawyer) understand it, the spectrum here is tight/loose binding on a conceptual level, rather than the specific technology used to achieve it.

The static/dynamic linking concern seems like a red herring, as it reflects a specific technological instance of such a distinction, but in architectures that do linking differently than traditional Unix systems, it makes less and less sense.


Meh, you don't need any special features to use LGPL libs. As long as the user can recompile and swap out that library with their new version, you're done. This either means dynamic linking the library or making object files for your proprietary code available so that the user can link it.

Oh and this will never work for GPL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: