4 ms·

Traditional proprietary software is not publicly available in source form. _That's_ the point of the post, and the "third way": make source available, and devel

Traditional proprietary software is not publicly available in source form. _That's_ the point of the post, and the "third way": make source available, and develop it in the open, without giving a permissive public license that defeats your other immediate needs. Transition to a permissive license later, if and only if that meets your needs then. Parity is a radical copyleft license. If "not perfectly clear in every case" means "poorly drafted" to you, welcome to the wonderful world of legal drafting. You might like to review: https://heathermeeker.com/open-source-faq/what-are-the-most-difficult-questions-in-open-source-licensing/ https://heathermeeker.com/open-source-faq/what-are-the-most-... https://mjg59.dreamwidth.org/49370.html https://mjg59.dreamwidth.org/49370.html https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b... Who bears the cost of the uncertainty in rules 1-3 of the Parity license? Does that help or hurt the goals of the license? For more on Parity, and the thought that went into it, see: https://blog.licensezero.com/2018/09/14/free-to-take-freedom.html https://blog.licensezero.com/2018/09/14/free-to-take-freedom... As for "shareware", the definition isn't rigorous. But almost all the shareware I've used was distributed binary- or bytecode-only, and often feature-incomplete, or limited by license-key-based software controls. Which is the point again. Developers can publish source without giving open source licenses.

jmillikin 8y ago
> Traditional proprietary software is not publicly available > in source form. If Microsoft published the Windows kernel publicly on GitHub under the Ms-RSL, it would still be proprietary software even if every line of code is visible to the public. > make source available, and develop it in the open, > without giving a permissive public license that defeats > your other immediate needs. You are describing proprietary code. > Parity is a radical copyleft license. That may be, but it's unlikely to see any adoption if it goes far beyond even the AGPL in terms of non-copyright-enforceable requirements. > As for "shareware", the definition isn't rigorous. But > almost all the shareware I've used was distributed > binary- or bytecode-only, and often feature-incomplete, > or limited by license-key-based software controls. Your lack of experience with proprietary software licensing options does not mean you get to redefine open-source.
- kemitchell 8y ago
  You're defining proprietary to include source-available. That is part of what I mean by "the two-party system" of thinking, forcing options into one camp or the other. Practically speaking, code developed in the open, by a diverse set of contributors, under a noncommercial license permitting redistribution, is far more comparable to open source than to Windows. That distinction is very clearly worth making. Doing otherwise risks forcing developers onto open source licenses when they're suboptimal, and nursing a misconception that the benefits of available source code accrue only to available source code that is also licensed under OSI- or FSF-approved terms. Your conclusion on the enforceability of copyright use restrictions is incorrect. Look at Vernor v. Autodesk and the MAI Trio. Look the CC-NC litigation. I have written far more proprietary than open source licenses, professionally. But practicing this area of law doesn't make my arguments correct. They have to stand on their own, without ad hominem support.
  - jmillikin 8y ago
    > You're defining proprietary to include source-available. > That is part of what I mean by "the two-party system" of > thinking, forcing options into one camp or the other. It's not a two-party system -- there are many possible options for open-source and proprietary licenses. This does not change that the distinction between "open-source" and "proprietary" is inherently binary. A license either meets the OSI definition or it doesn't -- you might argue that a license could be constructed to be right on the border, and that's true, but you'd still have to acknowledge it's on the border of something. > Practically speaking, code developed in the open, by a > diverse set of contributors, under a noncommercial > license permitting redistribution, is far more > comparable to open source than to Windows. Yes, that's true. Many proprietary licenses are closer to open-source than Windows is. > Doing otherwise risks forcing developers onto open source > licenses when they're suboptimal, and nursing a > misconception that the benefits of available source code > accrue only to available source code that is also licensed > under OSI- or FSF-approved terms. The benefits of being open-source ought to accrue only to software that is open-source. If software under a proprietary license would like to publish its source code to encourage community contribution, it's welcome to do so, but should not deceptively claim to be open-source. > Your conclusion on the enforceability of copyright use > restrictions is incorrect. Look at Vernor v. Autodesk > and the MAI Trio. Look the CC-NC litigation. None of those cases are relevant to this discussion. The MAI cases are obsolete (https://www.law.cornell.edu/uscode/text/17/117 https://www.law.cornell.edu/uscode/text/17/117), Vernor v. Autodesk covers whether possession of physical install media implies ownership of a license, and the only hits I could find on litigation related to Creative Commons non-commercial licenses seems to support my interpretation: https://creativecommons.org/2016/08/30/defending-noncommercial-uses-great-minds-v-fedex-office/ https://creativecommons.org/2016/08/30/defending-noncommerci...
detaro 8y ago
The major mistake proponents of these licenses make is IMHO trying to get to close to "Open Source" with their labeling/marketing. We have a quite clear definition of what "Open Source" means, if your license is not compatible to it and you market it as if it is this will dominate discussions of your license and people will assume bad intentions. Don't call people insisting on the meaning names. Find a new term and establish it instead of trying to capitalize on an existing one that means something else. "Source available" is a fine term (if there's a more specific one for a specific license, present that), and gets the entire meaning debate out of the way, so one can discuss the merits of the license as it is, not purely in comparison to something it somewhat pretends to be. (this specific blog post is better at this than other messaging, but this at least partially explains why the climate is so unfriendly)
- deleted 8y ago
  [deleted]
  - deleted 8y ago
    [deleted]
- kemitchell 8y ago
  Thanks for this. Very well taken. I agree with you on the need for a new coinage, in the middle, so to speak. Without meaning to overshadow that positivity, I'd offer two tiny quibbles: The OSD is pretty clear ... if you ask easy questions. I tried and failed to find the strongest copyleft license that OSI would approve. The main upshot of that laborious process was that OSI wouldn't likely approve such a license, even if it met the OSD. As for creating confusion with an established "brand", I tried to address this in the post, by analogy to vote splitting. That may have got buried too deep, in the final edit. My point there is basically one I've made here on HN before: https://news.ycombinator.com/item?id=17823328 https://news.ycombinator.com/item?id=17823328

jmillikin 8y ago

> Traditional proprietary software is not publicly available > in source form. If Microsoft published the Windows kernel publicly on GitHub under the Ms-RSL, it would still be proprietary software even if every line of code is visible to the public. > make source available, and develop it in the open, > without giving a permissive public license that defeats > your other immediate needs. You are describing proprietary code. > Parity is a radical copyleft license. That may be, but it's unlikely to see any adoption if it goes far beyond even the AGPL in terms of non-copyright-enforceable requirements. > As for "shareware", the definition isn't rigorous. But > almost all the shareware I've used was distributed > binary- or bytecode-only, and often feature-incomplete, > or limited by license-key-based software controls. Your lack of experience with proprietary software licensing options does not mean you get to redefine open-source.

kemitchell 8y ago
You're defining proprietary to include source-available. That is part of what I mean by "the two-party system" of thinking, forcing options into one camp or the other. Practically speaking, code developed in the open, by a diverse set of contributors, under a noncommercial license permitting redistribution, is far more comparable to open source than to Windows. That distinction is very clearly worth making. Doing otherwise risks forcing developers onto open source licenses when they're suboptimal, and nursing a misconception that the benefits of available source code accrue only to available source code that is also licensed under OSI- or FSF-approved terms. Your conclusion on the enforceability of copyright use restrictions is incorrect. Look at Vernor v. Autodesk and the MAI Trio. Look the CC-NC litigation. I have written far more proprietary than open source licenses, professionally. But practicing this area of law doesn't make my arguments correct. They have to stand on their own, without ad hominem support.
- jmillikin 8y ago
  > You're defining proprietary to include source-available. > That is part of what I mean by "the two-party system" of > thinking, forcing options into one camp or the other. It's not a two-party system -- there are many possible options for open-source and proprietary licenses. This does not change that the distinction between "open-source" and "proprietary" is inherently binary. A license either meets the OSI definition or it doesn't -- you might argue that a license could be constructed to be right on the border, and that's true, but you'd still have to acknowledge it's on the border of something. > Practically speaking, code developed in the open, by a > diverse set of contributors, under a noncommercial > license permitting redistribution, is far more > comparable to open source than to Windows. Yes, that's true. Many proprietary licenses are closer to open-source than Windows is. > Doing otherwise risks forcing developers onto open source > licenses when they're suboptimal, and nursing a > misconception that the benefits of available source code > accrue only to available source code that is also licensed > under OSI- or FSF-approved terms. The benefits of being open-source ought to accrue only to software that is open-source. If software under a proprietary license would like to publish its source code to encourage community contribution, it's welcome to do so, but should not deceptively claim to be open-source. > Your conclusion on the enforceability of copyright use > restrictions is incorrect. Look at Vernor v. Autodesk > and the MAI Trio. Look the CC-NC litigation. None of those cases are relevant to this discussion. The MAI cases are obsolete (https://www.law.cornell.edu/uscode/text/17/117 https://www.law.cornell.edu/uscode/text/17/117), Vernor v. Autodesk covers whether possession of physical install media implies ownership of a license, and the only hits I could find on litigation related to Creative Commons non-commercial licenses seems to support my interpretation: https://creativecommons.org/2016/08/30/defending-noncommercial-uses-great-minds-v-fedex-office/ https://creativecommons.org/2016/08/30/defending-noncommerci...

detaro 8y ago

The major mistake proponents of these licenses make is IMHO trying to get to close to "Open Source" with their labeling/marketing. We have a quite clear definition of what "Open Source" means, if your license is not compatible to it and you market it as if it is this will dominate discussions of your license and people will assume bad intentions. Don't call people insisting on the meaning names. Find a new term and establish it instead of trying to capitalize on an existing one that means something else. "Source available" is a fine term (if there's a more specific one for a specific license, present that), and gets the entire meaning debate out of the way, so one can discuss the merits of the license as it is, not purely in comparison to something it somewhat pretends to be. (this specific blog post is better at this than other messaging, but this at least partially explains why the climate is so unfriendly)

deleted 8y ago
[deleted]
- deleted 8y ago
  [deleted]
kemitchell 8y ago
Thanks for this. Very well taken. I agree with you on the need for a new coinage, in the middle, so to speak. Without meaning to overshadow that positivity, I'd offer two tiny quibbles: The OSD is pretty clear ... if you ask easy questions. I tried and failed to find the strongest copyleft license that OSI would approve. The main upshot of that laborious process was that OSI wouldn't likely approve such a license, even if it met the OSD. As for creating confusion with an established "brand", I tried to address this in the post, by analogy to vote splitting. That may have got buried too deep, in the final edit. My point there is basically one I've made here on HN before: https://news.ycombinator.com/item?id=17823328 https://news.ycombinator.com/item?id=17823328