These are chat archives for ethereum/solidity

10th
Sep 2016
Bob Summerwill
@bobsummerwill
Sep 10 2016 00:23

@kobigurk Which code is AGPL3? The Emscripten-generated code in https://github.com/ethereum/solc-bin?

As per https://github.com/ethereum/solc-bin/blob/gh-pages/LICENSE, which is actually GPL3, not AGPL3.

I have had my head in licensing stuff for the past few months, and would be happy to try to help clarify. Or even if you feel you have a conclusion, I would like to understand the issue you were discussing above.

If we have generated code tagged as GPLv3, that is probably in error. I worked through various of the C++ repos in the last couple of months, correcting incorrect LICENSE files.

Piper Merriam
@pipermerriam
Sep 10 2016 00:24
Is someone working on a brew version of solc>=1.4.x?
Bob Summerwill
@bobsummerwill
Sep 10 2016 00:24

See https://bobsummerwill.com/2016/07/12/ethereum-everywhere/

My understanding is that Ethereum's current licensing is ...

  • go-ethereum – GPLv3 and LGPLv3
  • cpp-ethereum – GPLv3 (re-licensing to Apache 2.0 in-progress)
  • solidity - GPLv3
  • pyethereum/pyethapp – MIT
  • ethereumjs-lib – MPL 2.0 and MIT
  • remix – MIT
  • web3.js – LGPLv3
Yes, @pipermerriam. Me!
But yeah, just build from source or use npm if you need it right now.
Piper Merriam
@pipermerriam
Sep 10 2016 00:26
so npm install solc and use the solcjs cli interface?
fancy
Bob Summerwill
@bobsummerwill
Sep 10 2016 00:27
I can take no credit, but yeah, npm appears to be the "just works" option through our configuration management storms.
Bob Summerwill
@bobsummerwill
Sep 10 2016 00:32

Caveat IANAL ...

On that licensing point, I think that any JS code should really be MIT, Apache 2.0 or MPL 2.0.

LGPL makes "dynamic-linkage as a licensing firewall" assumptions from an early "everything is C" era, which don't make sense for JS or static-linkage native environments like iOS.

MIT is just dumb and simple.

MPL 2.0 has some very nice features for JS, actually, like defining the license boundaries to be source files, not DLL and executable boundaries. Thanks for pointing that out, @wanderer.

And Apache 2.0's main win is its patent clause. ie. if you contribute then you have to promise not to bring patent action based on those contributions.

Piper Merriam
@pipermerriam
Sep 10 2016 00:38
Unfortunately, solcjs doesn’t have the full cli as solc, I’ll wait for the brew version
also doesn’t appear to support feeding it contracts via stdin
anyways, thanks for all the plumbing you do @bobsummerwill
Chevdor
@chevdor
Sep 10 2016 01:00
@pipermerriam I have been working hard on that the whole day :)
@pipermerriam if you cannot wait, you can check out the repo I forked but be aware that things are moving/changing
veonindustries
@veonindustries
Sep 10 2016 01:54
Can somebody explain this line of solidiy to me?
if (!recipient.send(this.balance)) throw;
veonindustries
@veonindustries
Sep 10 2016 02:09

What is the difference between using these, essentially they would both result in sending 100% of the contract funds to the recipient wouldn't they?

function Take() {
if (!recipient.send(this.balance)) throw;
}

function Take() {
uint bal = this.balance;
recipient.send(bal * 100 / 100);
}

Ramesh Nair
@hiddentao
Sep 10 2016 02:50
@tjade273 Thanks!
@Arachnid Because I’m going to observe the tx later on and want to associate some metadata with it to make it easier to work out what it was for.
Piper Merriam
@pipermerriam
Sep 10 2016 03:20
Might be interesting to others. I’ve almost got solc building on travis-ci https://travis-ci.org/pipermerriam/py-solc/jobs/158909305
Best I’ve been able to come up with to test against specific solc versions.
Kobi Gurkan
@kobigurk
Sep 10 2016 06:19
@bobsummerwill sure, let's continue the discussion! do you want to discuss it here?
@axic just using require('solc/wrapper') is not equivalent to fetching, caching and then requiring
do you suggest that the fetching code is not "protected" by MIT?
RJ Catalano
@VoR0220
Sep 10 2016 07:35
@axic I just split up the fixed points into numerous different tasks…sorry if it’s not a bit better organized, let me know what I can do to help out…I really want this thing to get done.
Alex Beregszaszi
@axic
Sep 10 2016 09:25
@bobsummerwill solidity and solc-bin is GPL3, but solc-js, browser-solidity and remix are MIT
@pipermerriam are you writing a pythin c binding for solidity?
@kobigurk fetching/caching?
@VoR0220 thank you! will check it out soon
Kobi Gurkan
@kobigurk
Sep 10 2016 09:43
@axic yeah, the main point of the PR was introducing the way to retrieve the binary code of a specific version of solc
Chevdor
@chevdor
Sep 10 2016 09:52
‘morning
FYI: I am working on a PR that will remove the ./download* script and bring its features inside solcjs. The idea being to have a single tool to build, get compilers, list them, ….
Alex Beregszaszi
@axic
Sep 10 2016 10:28
@kobigurk loadRemoteVersion does that already?
Kobi Gurkan
@kobigurk
Sep 10 2016 10:45
@axic it doesn't give you back the binary code. so, for instance, if I were to use the same remote version continuously, when calling loadRemoteVersion I'd re-download it
Alex Beregszaszi
@axic
Sep 10 2016 10:46
So basically you just want a helper method which downloads the remote and gives you back a string?
(and does the version lookup properly)
Kobi Gurkan
@kobigurk
Sep 10 2016 10:48
@axic that's one option. I do want the solc instance too, but that can also be done by requiring like you suggested
@axic I think it's a good option too
Alex Beregszaszi
@axic
Sep 10 2016 11:00
@kobigurk ethereum/solc-js#54
If you want to add anything to it
Kobi Gurkan
@kobigurk
Sep 10 2016 11:01
@axic thanks
DennisBPeterson
@DennisBPeterson
Sep 10 2016 13:52
@CyberNano it's possible for send() to fail due to a stack overflow attack. See http://www.blunderingcode.com/writing-secure-solidity/
Bob Summerwill
@bobsummerwill
Sep 10 2016 14:39

Right, @axic.

I don't know if solc-bin being GPLv3 was intentional, or if the licensing was just carried over from solidity. @chriseth?

Maybe it was intentional? The rationale for GPLv3 licensing on the tools and applications is that they are unlikely to be aggregated into anything else, and you want the benefit of all contributions coming back (ie. you want everyone working in the same place).

When you are talking native solc that makes sense, but when it comes to the Emscripten generated files, maybe slightly less, because the JS 'compilation model' is not the same. Generated code is conventionally always permissively licensed, though this is quite a special case of generated code, because it isn't generated code based on user-provided input.

I cannot honestly imagine any nefarious actor thinking "Ha ha! Those fools have make the solc-bin permissively licensed, so now I will fork that generated code and make something proprietary and make a squillion dollars". It would be a nightmare to work with, and is effectively "a unit" in itself. Having that generated code be permissively licensed would just remove uncertainty about using that code from within other MIT JS code.

That, I presume, is the concern? That we are now building infrastructure around that generated code, but the fear is that using that GPLv3 will "infect" that wrapping code, and force all JS Solidity stuff to be GPLv3 too?

Funnily enough, I see that browser-solidity is MIT :-)

Alex Beregszaszi
@axic
Sep 10 2016 14:40
@bobsummerwill solc-bin has no wrapping code. It only one has one script, update, which could be considered part of Solidity. It generates the version list files and copies the latest release to soljson.js.
Kobi Gurkan
@kobigurk
Sep 10 2016 14:41
@bobsummerwill, I'd think a required emscriptened file is essentially using it without modification as an external dependency, which to my best understanding, is OK even under GPLv3?
it's not even "dynamic linking"
Alex Beregszaszi
@axic
Sep 10 2016 14:42
And the generated emscripten file cannot be anything else than what Solidity is licensed under, as it is the binary output of the compilation.
Kobi Gurkan
@kobigurk
Sep 10 2016 14:42
which would require LGPL license
although logically, it doesn't really apply to solc-js, but does apply to other software using solc-js
Alex Beregszaszi
@axic
Sep 10 2016 14:53
solc-js is MIT
Kobi Gurkan
@kobigurk
Sep 10 2016 14:54
but to be honest, it's a simple wrapper around emscriptened solc which is GPLv3
should be infected, as far as I understand
Alex Beregszaszi
@axic
Sep 10 2016 14:55
That is the though part, you're right.
Bob Summerwill
@bobsummerwill
Sep 10 2016 14:56

@axic Yes, the value in solc-bin is the generated content in
https://github.com/ethereum/solc-bin/tree/gh-pages/bin, isn't it?
Perhaps the update script should actually be in the solidity repo, so that the line is pretty perfectly drawn?

"And the generated emscripten file cannot be anything else than what Solidity is licensed under, as it is the binary output of the compilation."

^ I think that is untrue, @axic. Generated output is frequently licensed differently than its inputs. Whether or not that is necessary or desirable in this particular case is what we are discussing. Some of will might boil down to what the common understanding of GPLv3 as applied to JS is, and whether require() is interpreted as generating a combined work or not.

Alex Beregszaszi
@axic
Sep 10 2016 14:58
@bobsummerwill if you compile a GPL3 C source to a Linux binary, will the resulting binary not licensed under GPL3?
Kobi Gurkan
@kobigurk
Sep 10 2016 14:59
to be honest, I think an exception to the license could be the easier solution here
similar to what libbitcoin does
that explicitly draws the line
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:02

@axic Yes, it will, because that is the conventional "C" compilation model which the whole of copyleft licensing was built around, and the line between static and dynamic linkage.

Emscripten, and even JS as a whole, doesn't really fit very well into that licensing model, where there is no clean line between source and binary.

Alex Beregszaszi
@axic
Sep 10 2016 15:03
Emscripten is a compiler, which outputs a restricted set of javascript (asm.js) from an input written in C or C++.
So the emscripten output has the same license.
require is then like dynamic linking:
1) loading the library and either using code,
2) or modifying code through prototypes. (solc-js doesn't do this)
Also in addition, the exported methods in emscripten are the ones defined in solc/jsonCompiler (aka. libsoljson). I think the best for Solidity would be LGPL3.
Alternatively, if you want more restrictions, you could say that libsoljson is LGPL3 and have a license exception for the rest of Solidity saying that it can be used as LGPL3 if-and-only used through libsoljson.
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:13

LGPLv3 provided a middle ground of saying "You can use this GPL thing unmodified in a non-GPL licensed software as long as you use dynamic linkage, and then that binary is the licensing firewall".

So yeah, I would agree that require acts like dynamic libraries, but I don't know if that is something which there is consensus on from a legal perspective. I don't see much/any GPL or LGPL in JS land.

Have a quick read of https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2), which @wanderer pointed out to me. That's another interesting variant.

So I don't know exactly what is required here, but I do think that we aren't quite in the right place.

@axic Yes, I know that Emscripten is a compiler, though an unusual one, but we can certainly choose to have its output licensed differently than its input if we want. We just need to declare that to be the case.

That would make no sense for a normal C++ application. Saying that the binaries produced from a GPLv3 C++ application were permissively licensed wouldn't really help anybody, because there was had been so much information-loss. But it would be something which has practical value for Emscripten.
Kobi Gurkan
@kobigurk
Sep 10 2016 15:15
@bobsummerwill to be fair, I don't think there's a definite legal perspective on anything in OSS licenses... it's all speculation anyway.
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:16
Indeed. But what I think we can definitely say is the current situation does have a legal grey area, which it would be good to resolve.
Kobi Gurkan
@kobigurk
Sep 10 2016 15:16
:+1:
Alex Beregszaszi
@axic
Sep 10 2016 15:17
@bobsummerwill why is better saying that the emscripten output is licensed under entirely different terms than Solidity as opposed to licensing Solidity so that it allows dynamic linking?
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:20
Because I suspect that require() is actually more like #include than dlopen(). In JS land there is no clear line between source and binaries.
The whole of LGPL, from what I can determine, assumes that the whole world of software operates on a C/C++ model, and that just isn't true anymore.
Alex Beregszaszi
@axic
Sep 10 2016 15:25
well there's also a node-ffi which definitely solves this :)
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:26

Even within "C world", not all platforms support dynamic libraries. Take iOS, for example. No support for DLLs there are all, which means that LGPL just doesn't work. Ditto on many embedded platforms.

That quirk alone let Novell and then Xamarin build a business for a decade or more in selling Mono for iOS, because there was no means for dynamically loading a .so containing the Mono runtime. Instead, a .s file needed to be static linked.

Alex Beregszaszi
@axic
Sep 10 2016 15:26
dylib?
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:26
No dylibs on iOS, no.
Yes for OS X. No for iOS.
Alex Beregszaszi
@axic
Sep 10 2016 15:26
right
what license do you propose for the emscripten output?
Bob Summerwill
@bobsummerwill
Sep 10 2016 15:28
Everything else has been licensed as MIT, so that would be simplest, but I think there are certainly merits in considering MPL 2.0 and Apache 2.0. Just paging @wanderer again, who has thought about this a lot :-)
wanderer
@wanderer
Sep 10 2016 15:34
hi :)
yeah I was liscening everything under GPL, but that makes things really hard JS libs
MPL-2.0 had the qualities that I was looking for, protecting the source code that I wrote and giving me a guarantee that anyone how modified would contribute back by open sourcing their modification (copyleft). While still being super easy to use in websites with proprietary code.
wanderer
@wanderer
Sep 10 2016 15:39
and lastly its the langauge is easy to understand
Piper Merriam
@pipermerriam
Sep 10 2016 16:18
+1 to MIT. Simple and permissive. I am admittedly ambivalent about copyleft
jambtt
@jambtt
Sep 10 2016 23:13
hi guys, if i were to save an ETH value into mysql, what data type is best?
as in, need to accomodate min>max values
Alex Beregszaszi
@axic
Sep 10 2016 23:14
The protocol doesn't have a limit, but the EVM sets it at 256 bits. So a 256 bit number should be a safe fit.
jambtt
@jambtt
Sep 10 2016 23:14
thank you
:)
how many digits to the right of the decimal, is it 18?
Alex Beregszaszi
@axic
Sep 10 2016 23:18
to the right?
jambtt
@jambtt
Sep 10 2016 23:18
0.1xxx
i have to use DECIMAL in mysql
Alex Beregszaszi
@axic
Sep 10 2016 23:18
I think you're better off counting in wei as that is the standard (i.e. 0 decimal points)
jambtt
@jambtt
Sep 10 2016 23:19
ahhh ok
ty
yes