3 ms·

The encumbrances that this license places on the downstream modification and redistribution of code largely eliminate any of the material advantages that come f

The encumbrances that this license places on the downstream modification and redistribution of code largely eliminate any of the material advantages that come from the code being open in the first place. You should explain this. As far as I can tell from a 1st reading, so long as I'm non-commercial, I can just treat it as BSD 2 clause.

chungy 9y ago
That's the point, it violates the open source definition. See https://opensource.org/definition https://opensource.org/definition : "6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research." "Non-commercial" clauses by definition make something not open source.
- ghostly_s 9y ago
  Your parent asked about encumbrances, not definitions. What is the encumbrance here beyond requiring application of different terminology?
  - rspeer 9y ago
    You can't release your code in a way that it can be used as a dependency, except by requiring your downstream users to use the License Zero payment platform. That's an encumbrance. You also can't distribute it along with GPL code, at all, whereas combining BSD and GPL code is totally fine (the result is GPL).
- colejohnson66 9y ago
  How does Qt get around that?
  - mappu 9y ago
    Qt can be used commercially under the terms of the LGPL at no cost. When used appropriately (i.e. dynamic linking to unmodified Qt, or, offering source for a modified dynamically-linked Qt), the commercial company is not forced to open source anything. Qt has an optional alternative license with a cost attached, that gives you (A) a support contract, and (B) additional rights (static linking without invoking GPL virality, private modifications, ...).
- cyphar 9y ago
  They also violate freedom #0 making them proprietary.
dragonwriter 9y ago
> so long as I'm non-commercial, I can just treat it as BSD 2 clause. No, you can't, because if it was BSD 2-clause, you could relicense it rather freely. But you can't with this, because the commercial use limitation makes it incompatible with many licenses with which BSD 2-clause is compatible. (Including GPLv3) Also, because you have to include the full license terms (including the requirement to secure a commercial license from the agent of the original licensor) with derived versions, well, if AD ever gets competition as a licensing agent (even from someone using a compatible pseudo-open license), downstream commercial users of software which has modules with different licensing agents face the prospect of having to secure multiple commercial license from different licensing agents to see the software. For a non-commercial end user of only the “root” software, it similar to BSD 2-clause. For developers (even non-commercial), it's much more restrictive.
- ballenf 9y ago
  It also would allow for unsavory gamesmanship due to the "license available" trigger. Wait for widespread adoption, then release a commercial license. Suddenly you have a lot of scrambling to either replace the product or buy a license. Alternatively, license cost could be inflated greatly after adoption. I just see the terms as creating too many unknowns about the future. Maybe I missed it, but do you have to constantly monitor all your dependencies for whether they may have just released a commercial license? The effects of the license shouldn't vary depending on some outside input (the existence or not of a commercial license). And the 90-day "trial" period seems both too long and too short at the same time. It's long enough to make tracking a little more difficult and too short to even make it into production from testing for many uses. (I assume the 90-days starts as soon as an org begins testing the product, not necessarily starting upon shipping.)

chungy 9y ago

That's the point, it violates the open source definition. See https://opensource.org/definition https://opensource.org/definition : "6. No Discrimination Against Fields of Endeavor The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research." "Non-commercial" clauses by definition make something not open source.

ghostly_s 9y ago
Your parent asked about encumbrances, not definitions. What is the encumbrance here beyond requiring application of different terminology?
- rspeer 9y ago
  You can't release your code in a way that it can be used as a dependency, except by requiring your downstream users to use the License Zero payment platform. That's an encumbrance. You also can't distribute it along with GPL code, at all, whereas combining BSD and GPL code is totally fine (the result is GPL).
colejohnson66 9y ago
How does Qt get around that?
- mappu 9y ago
  Qt can be used commercially under the terms of the LGPL at no cost. When used appropriately (i.e. dynamic linking to unmodified Qt, or, offering source for a modified dynamically-linked Qt), the commercial company is not forced to open source anything. Qt has an optional alternative license with a cost attached, that gives you (A) a support contract, and (B) additional rights (static linking without invoking GPL virality, private modifications, ...).
cyphar 9y ago
They also violate freedom #0 making them proprietary.

dragonwriter 9y ago

> so long as I'm non-commercial, I can just treat it as BSD 2 clause. No, you can't, because if it was BSD 2-clause, you could relicense it rather freely. But you can't with this, because the commercial use limitation makes it incompatible with many licenses with which BSD 2-clause is compatible. (Including GPLv3) Also, because you have to include the full license terms (including the requirement to secure a commercial license from the agent of the original licensor) with derived versions, well, if AD ever gets competition as a licensing agent (even from someone using a compatible pseudo-open license), downstream commercial users of software which has modules with different licensing agents face the prospect of having to secure multiple commercial license from different licensing agents to see the software. For a non-commercial end user of only the “root” software, it similar to BSD 2-clause. For developers (even non-commercial), it's much more restrictive.

ballenf 9y ago
It also would allow for unsavory gamesmanship due to the "license available" trigger. Wait for widespread adoption, then release a commercial license. Suddenly you have a lot of scrambling to either replace the product or buy a license. Alternatively, license cost could be inflated greatly after adoption. I just see the terms as creating too many unknowns about the future. Maybe I missed it, but do you have to constantly monitor all your dependencies for whether they may have just released a commercial license? The effects of the license shouldn't vary depending on some outside input (the existence or not of a commercial license). And the 90-day "trial" period seems both too long and too short at the same time. It's long enough to make tracking a little more difficult and too short to even make it into production from testing for many uses. (I assume the 90-days starts as soon as an org begins testing the product, not necessarily starting upon shipping.)