Dapps and Ethereum licenses

I've noticed that Ethereum sub-projects use a mix of licenses:

cpp-ethereum GPL v3
eth-go LGPL v2.1
ethereum-dockers MIT
ethereum.js LGPL v3
ethereumj MIT
ethereumjs-lib GPL v3
go-ethereum LGPL v2.1
node-ethereum GPL v2
pyethereum MIT

First question, is there a good reason for this? Dapp developers might find it easier if there was a consistent license for all components.

Second question, does Ethereum intend to accomodate Dapps that are not open-source? The GPL prohibits embedding into non-open-source code, meaning that the core libraries in cpp-ethereum, or the subset in ethereumjs-lib, can not be used by a Dapp that doesn't release its own source code as well. But I expect that many Dapp developers will want to include proprietary code as part of what makes their Dapp worth using and better than the competition.

Comments

  • eaglgenes101eaglgenes101 Member Posts: 43
    Ethereum is more of a protocol than a single project. The separate implementations are in fact well encouraged to make sure that the standard is unambiguous.
    And I'm pretty sure it'll be just fine to make proprietary dapps; GPL software runs on OS X, and proprietary software runs on linux distros.
  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    @mjm When it comes to proprietization, this is always worthy ov reviewing as well: http://en.wikipedia.org/wiki/Tivoization
  • mjmmjm Member Posts: 4
    Well, I'm not sure if any of the replies are relevant to what I have in mind, so let me give some examples:
    • JavaScript. Suppose a developer writes a great JS Dapp to work with, say, a market of oracle data feeds. The oracles and oracle market are open-source contracts on the Ethereum blockchain, and several Dapps may exist to let people interact with the market. Our developer wants to charge people to use his superior product, and needs to keep the superior parts proprietary (as obfuscated JS). But if his Dapp uses ethereumjs-lib the GPL license requires that he publish the source of the entire Dapp.

    • C++. Imagine a desktop app with awesome graphics that lets people play games with other people and uses the Ethereum blockchain for certain functions. Again the publisher might want to keep the app's source code secret for competitive reasons. But the app includes cpp-ethereum, and the GPL prohibits distributing the app without its source.
    In response to @robmyers, here is the GPL text about "System Libraries", which addresses a different issue:

    Less Source to Distribute: New System Libraries Exception

    Both versions of the GPL require you to provide all the source necessary to build the software, including supporting libraries, compilation scripts, and so on. They also draw the line at System Libraries: you're not required to provide the source for certain core components of the operating system, such as the C library.

    GPLv3 has adjusted the definition of System Library to include software that may not come directly with the operating system, but that all users of the software can reasonably be expected to have. For example, it now also includes the standard libraries of common programming languages such as Python and Ruby.

    The new definition also makes it clear that you can combine GPLed software with GPL-incompatible System Libraries, such as OpenSolaris' C library, and distribute them both together. These changes will make life easier for free software distributors who want to provide these combinations to their users.
  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    mjm said:

    Well, I'm not sure if any of the replies are relevant to what I have in mind

    The fvture is 0pen.. but i'm quite certain you can still metallica ur src if thats ur thing.
  • windrushwindrush Member Posts: 2
    @mjm - the biggest reason for different licenses is probably just preferences by different developers, the projects all being developed by different people and that even for core projects (by the core ethereum team(s)) I think there is no general policy/requirement on licensing. I would say it's called organic/decentralized growth :)
    -
    Regarding your examples:
    - if you rely on js obfuscation, you probably have a problem anyway. Apart from that, if you found out that you somebody used your code, you could still sue them.
    - Generally, if your dapp calls to the js lib, that should be fine within the GPL I think, as long as you don't modify the js lib. if you modify it, you would have to distribute those changes. (though it depends) However, what would likely not work in any way is if you build your product on top of another product under f.e. GPL v2 and then improve on that, then your work built on top is so linked to the code from before, it's not feasible to distinguish and then according to the license you would have to distribute the code.

    - For a c++ app, I don't see any problems. You could maybe even distribute alethzero, as long as you don't modify it (or publish modifications under GPL v3) and oblige the other license requirements. Your desktop c++ app could then interface via js rpc calls or so, and you could keep the code of that c++ app closed.

    Disclaimer: This is not legal advice.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    - if you rely on js obfuscation, you probably have a problem anyway. Apart from that, if you found out that you somebody used your code, you could still sue them.
    You are allowed to shortening javascript or even obfuscate. The GPL requires you to distribute the preferred format for editing, but you can also distribute binaries by themselves. Shortening/obfuscating are sort-of equivalent to the binaries.
  • windrushwindrush Member Posts: 2
    I didn't mean that you were not allowed under the license. This was supposed to say that if you are relying on shortening/obfuscation to protect your code or other secrets, you probably have a problem.
  • robmyersrobmyers Member Posts: 65 ✭✭✭
    "Our developer wants to charge people to use his superior product, and needs to keep the superior parts proprietary"

    If they are going to be making that much money, they can afford to pay for proprietary libraries. In fact if proprietary software is the best way of ensuring that superior software is created for people to use, it's not clear why the developer wouldn't want to pay for proprietary software in order to use it to produce their own work. They should be demanding that Ethereum's libraries be placed under a proprietary license and developers charged for their use.

    "Again the publisher might want to keep the app's source code secret for competitive reasons."

    Publisher or developer? Competing with who?

    The effects of proprietary software fall squarely on its users. What if there are bugs in the code? Or the developer doesn't build it for a platform or locale you wish to use it with? Or they are wrong about its viability and stop supporting it? Or in a few years time they abandon it and move on to a more profitable/interesting/fashionable platform? What value does them making the software proprietary give to users?

    And why would they be distributing cpp-Ethereum? What is wrong with their platform's package manager?

    "In response to @robmyers, here is the GPL text about "System Libraries", which addresses a different issue"

    IANAL but I'm familiar with the GPLv3. ;-) That section addresses the issue as described. The relevant part is:

    "GPLv3 has adjusted the definition of System Library to include software that may not come directly with the operating system, but that all users of the software can reasonably be expected to have. For example, it now also includes the standard libraries of common programming languages such as Python and Ruby."

    A level playing field for Ethereum development benefits all users. Free Software is the best way of achieving that.
  • vaXvaX Austin, TXMember Posts: 78 ✭✭✭
    ^^ Very well articulated @robmyers
Sign In or Register to comment.