[HN Gopher] Toward Copyleft Equality for All
___________________________________________________________________
Toward Copyleft Equality for All
Author : pabs3
Score : 39 points
Date : 2020-01-20 02:07 UTC (20 hours ago)
(HTM) web link (sfconservancy.org)
(TXT) w3m dump (sfconservancy.org)
| v7x wrote:
| I see a few comments in here, and have seen similar comments in
| similar topics in other threads, saying that they dont understand
| why anyone would choose this over other FOSS licenses. These
| questions are asked from a developer-centric perspective. FOSS
| never has been, and never will be, developer-centric. Free as in
| freedom software was created to be USER-centric. The whole point
| is to take power AWAY from the developer, because otherwise the
| balance is always in the developer's favor. The benefit for the
| developer is that developers are also users, so they in turn
| benefit from others releasing the software as FOSS, both as
| libraries to write better software with and as programs used in
| day to day computing.
|
| Any issues companies have with FOSS licenses is entirely on them,
| assuming they arent one of the few who actively contributes to
| and fights for FOSS. MongoDB doesn't like competition from
| Amazon? Understandable. But don't play the victim and then turn
| around and screw everyone who isn't Amazon over with a license
| change. Maybe instead you could take some of your shake-down
| money and put it to good use by lobbying against these
| monopolistic conglomarates in the valley so that they can't use
| their overreaching power to screw you with your own code. Maybe
| instead, you could encourage ALL developers to start using
| copyleft licenses, instead of the weaker licenses everyone loves
| to throw on their project these days. Because those weaker
| licenses are somewhat to blame for this too. What good is a FOSS
| program if its just going to lead to more proprietary software?
| How does that help anyone? There's a reason most of the big tech
| monopolies release most of the open source code they do produce
| under non-copyleft licenses. Its not because they love FOSS, its
| so that they can pay lip service to the community and then use it
| with their the proprietary programs we're so concerned about them
| surveiling us with. Of course, the retort to all of this is
| "developers need to eat to, how can we make money off of
| copyleft?" I have two answers, one thats snarky but possibly
| helpful and one that's honest but possibly rude, and hopefully
| enlightening. The first answer is "Ask Qt." "Ask Blender." "Ask
| Redhat." Ask one of the many companies that do buisiness while
| still releasing their main software under a FOSS license. They
| all seem to be doing pretty well. The second answer is that I
| don't care how or even if you make money. Thats not the reason
| you release something as FOSS. Never has been, never will be. If
| you release software as FOSS, its because you believe that there
| should be a balance of power between developers and users. Its
| because you believe that sharing information and knowledge is the
| best way we can improve quality of life for ourselves and those
| around us. If you can't make those ideals your biggest priority
| even in the face of financial loss, frankly don't even bother
| releasing your software as FOSS. I'd rather your software be
| proprietary. That way I'll know to avoid it and we won't have to
| waste eachothers time.
| dredmorbius wrote:
| Two standout points from this essay:
|
| 1. I've long heard that various SaaS companies _really didn 't
| like_ the Affero General Public License. Kuhn makes a case for
| why this is a validly justified concern, something I'd not
| previously considered.
|
| 2. The copyleft restriction termination is a _really_ interesting
| concept, though not without its own set of consequences which
| should be closely examined. Historically, the advantage of
| copyleft has been that it applies equally to all. The abuse of it
| (by firms also marketing properietary solutions) is a problem,
| but removing copyleft obligations entirely might not go as
| intended.
|
| 3. Copyright assignments to copylefted codebases without an
| explicit restriction of those to require copyleft-only usage, a
| distinction which differentiates strongly between the uses at,
| say, FSF vs. MySQL AG / Oracle, clearly also present issues, as
| has long been argued.
| kazinator wrote:
| That Affero license doesn't seem very useful, because if you
| depend on code running on someone else's server, it doesn't
| help you if you have an honest copy of the source code that is
| actually running on it. You still don't control it. You can't
| make changes and deploy it to that server, or update it
| yourself, etc..
|
| Free, open-source software is about control: controlling what
| code manipulates your data.
|
| In short, it seems that the license really doesn't really do
| much of substance for the user, and just saddles the operator
| with extra burdens.
| dredmorbius wrote:
| The Affero license gives you _precisely_ the rights to the
| _code_. No, it doesn 't give you rights to the _server_ the
| code runs on, but you can spin up your own server (often
| little more than a RaPi box, possibly more at scale),
| avoiding lock-in based on software alone.
|
| But it obliges you to provide or make available those changes
| if the use will "propogate" the work.
|
| https://www.gnu.org/licenses/agpl-3.0.en.html
| kazinator wrote:
| If I spin my own server, why would I care what anyone else
| has done with their server, code-wise? Does everyone in the
| world who has publicly installed that server owe me a copy
| of their source code, even if what I run and use is
| strictly my own server built from the upstream code?
|
| By the way, the AGPL3 definition of "propagate" looks
| exactly the same as that of the the regular GPL3. Operating
| software as a server doesn't fall under "propagate".
| tuukkah wrote:
| Isn't the point that you can modify and deploy a copy on your
| own infrastructure?
| pabs3 wrote:
| This reminded me of the agreement between Qt and KDE, where if Qt
| is ever made proprietary, KDE can publish Qt under the BSD
| license:
|
| http://www.olafsw.de/a-better-qt-because-of-open-source-and-...
| https://old.reddit.com/r/QtFramework/comments/e9376a/trouble...
| https://news.ycombinator.com/item?id=21755337
| kazinator wrote:
| > _The essence in non-legalese is this: If you offer a license
| that isn 't a copyleft license, the copyleft provisions collapse
| and the software is now available to all under a non-copyleft,
| hyper-permissive FOSS license._
|
| Why would anyone choose this?
|
| It must be for the sake of giving the downstream users some sort
| of assurance that a Bad Thing won't happen to them, as a sort of
| promise.
|
| "If we ever commercialize this, we will give all of you the
| opportunity to do the same."
|
| It seems that the only authors for whom it would make sense to
| choosing this license would be authors who have no intention of
| going mixed proprietary licensing now, or in the future.
| Moreover, authors who believe in copyleft FOSS licenses and want
| to keep the project that way.
|
| Someone who chooses that license knowing they will likely issue
| proprietary versions might as well skip straight to a simpler
| BSD-style license that is implied in that action.
|
| Someone who doesn't believe in copyleft FOSS would also just skip
| this sort of thing and give the users the "hyper-permissive"
| license.
|
| No matter what promises a copyright holder makes, they can
| retract them. However, at least this will be in force for users
| who hold existing copies. So that is to say, if the authors
| decide to commercialize and switch to Affero GPL, then only the
| new issues of the software going forward will be bound by that
| AGPL; the existing users will have the "hyper-permissive" license
| for the code up to that point.
| yarrel wrote:
| > The toxicity of this business model has only become apparent in
| hindsight.
|
| I'm glad that Bradley is drawing critical attention to this
| issue.
|
| > efforts to draft even more restrictive software copyleft
| licenses
|
| A non-free "copyleft" license is not worthy of the name and is a
| problem because it is non-free, not because of "copyleft".
|
| > The clause still needs work
|
| The _license_ needs work,it seems to treat copyleft as a form of
| punishment for authors to be tolerated for a while rather than as
| a strategy to permanently protect the freedom of all software
| users.
|
| > a basic approach to incorporating similar copyleft equality
| clauses into written exceptions for existing copyleft licenses,
| such as the Affero GPL
|
| These clauses can and will be removed by downstream users for any
| alterations or additions they make to the software in order to
| provide it to their cloud-based users. This will redouble the
| downstream use dynamics that VC-funded "open source" projects,
| some of the heaviest users of abusive CLAs, whine about.
| kazinator wrote:
| Downstream users cannot remove clauses put in place by the
| copyright holder, even for alterations that they make, because
| those are derived works. A pure addition that you make to a
| copylefted program is your copyright; you have to license it in
| a way which is compatible with that program, but otherwise it
| can be anything. E.g. you can add 2-Clause-BSD-licensed code to
| a GPL-ed program and then redistribute that to your own
| downstream users. The GPL still applies to the thing as a
| whole; users can use just your portion alone under its BSD
| license (like borrow the code into another program).
| zeveb wrote:
| I believe that this is arguing from a false premise: the reason
| that companies despise the AGPL is not, I think, that they fear
| that they fear accidentally violating copyleft and thus being
| forced to buy a proprietary license but rather than they simply
| want to have their cake and eat it too: copyleft for thee but not
| for me. They want to use software for free but not grant the
| rights they received to their own users.
|
| Thus a provision reverting to a BSD-style license in case of
| proprietary licensing would, I believe, do nothing to encourage
| them to use it in the first place.
| _frkl wrote:
| I'm torn. On one side I do like this idea, on the other hand I
| don't see a practical way to work on exploratory open source
| software in some areas where your effort (even if it actually
| ends up delivering value to somebody) will be rewarded
| adequately. The existing models (open core, support contracts,
| donations, ...) may work here and there (although some of those
| would be invalidated by this suggestion), but compared to a
| traditional strategy just writing proprietary code it's quite a
| bit more difficult to make money. And I reckon that is difficult
| enough as it is...
| shmerl wrote:
| I don't think anyone suggested that it should be easy to make
| money that way. It was and likely will always be more
| difficult. Which doesn't mean it shouldn't be done.
| tptacek wrote:
| The premise of this post is that dual-licensing --- offering a
| piece of serverside or on-prem commercial software under (A)GPL
| terms, with a proprietary license available for firms that want
| unrestricted usage --- is "seedy". It's not clear to me how that
| premise is justified, and Kuhn's claim that the model has failed
| to increase software freedom seems totally unjustified.
|
| At the heart of Kuhn's argument about "seediness" seems to be
| CLAs, which is where a third-party developer using software under
| FOSS terms is asked to sign the rights to their modifications
| over to the original vendor. If CLAs were coercive, this would
| indeed be seedy: FOSS developers would be getting baited into
| contributing to commercial products. But CLAs aren't coercive;
| the AGPL requires only that you meet the requirements of the
| license itself, not that you sign away your rights to your own
| modifications. People sign CLAs because they want their
| modifications upstreamed, and to avoid maintaining forks, not
| because they're legally required to do so.
|
| Meanwhile, the kinds of software we talk about when we talk about
| the AGPL are overwhelmingly things that used to be (and in some
| cases in large part still are) closed source proprietary
| products. It's a little hard to imagine a closed source
| distributed database taking off in 2020; 20-30 years ago, to use
| Kuhn's framing, the opposite statement would have been more
| valid.
|
| Fundamentally, software offered under the AGPL is almost always
| developed under the model of a single commercial vendor doing
| most of the heavy lifting, and, usually, all of the initial lift
| in getting a piece of software to the point of viability. It's
| hard to see how these vendors are taking something from the
| community by releasing their products under the AGPL when their
| alternatives would certainly be either a fully closed-source
| proprietary release, or no release at all. Kuhn writes as if
| licensing and advocacy decisions determine the economics of
| software development, but if the last 30 years has been an
| experiment conclusively demonstrating anything, it's that --- at
| least for the kinds of serverside code we're talking about --- no
| matter how you license it, companies paying software developers
| are what gets software built.
|
| I have strong opinions only about the AGPL; I don't pretend to
| fully understand the ramifications of MongoDB's SS GPL, nor do I
| support the SS GPL unreservedly.
| [deleted]
| Tyr42 wrote:
| If you wish for a dissenting opinion on the MongoDB, I enjoy
| the writing of Kyle Mitchel at /dev/lawyer
|
| https://writing.kemitchell.com/series/SSPL.html
|
| Kyle is a advocate of dual licensing ("selling exceptions") and
| has even created License Zero [1] which is attempting to allow
| the creation of npm libraries which are dual licensed and an
| automatic command line tool to pay developers.
|
| [1]: https://licensezero.com/ see also
| https://writing.kemitchell.com/2017/09/12/The-License-Zero-M...
| rocqua wrote:
| > People sign CLAs because they want their modifications
| upstreamed, and to avoid maintaining forks, not because they're
| legally required to do so.
|
| This is still coercive though. It is the big party using their
| power to get developers to give up their rights.
|
| Notably, by giving up these rights, it becomes possible for the
| party to go against the FOSS principles that were the reason
| copy-left was invented.
| int_19h wrote:
| If this story is true, it definitely sounds shady to me:
|
| "This problem became clear to me in mid-2003 when MySQL AB
| attempted to hire me as a consultant. I was financially in need
| of supplementary income so I seriously considered taking the
| work, but the initial conference call felt surreal and
| convinced me that MySQL AB was engaging in problematic behavior
| . Specifically, their goal was to develop scare tactics
| regarding the GPLv2."
| vorpalhex wrote:
| > But CLAs aren't coercive
|
| CLAs are frequently coercive, rights depriving and generally a
| bad move, and I as a FOSS contributor won't sign them.
|
| Yes, occasionally they are used correctly - but more often than
| not they're used to crowdsource work on what is really a
| proprietary codebase with crazy potential restrictions if the
| owning company decides to call them in.
| tptacek wrote:
| I want to be clear that I think CLAs can be a bad idea for
| contributors and people should think carefully before signing
| them. But since the AGPL doesn't obligate you to sign a CLA,
| I don't see how the existence of CLAs is an indictment of the
| AGPL or of dual-licensed business models. It's my belief that
| most dual-licensed software wouldn't be open sourced at all
| (and a lot of it wouldn't exist at all) without the dual-
| license model that Kuhn opposes.
| dredmorbius wrote:
| I've reread Kuhn's piece several times. It's that unfortunate
| mix of tantalising and unclear.
|
| My understanding is that it's not the dual-licensing per se
| that's toxic, but the _goal of copyleft-noncompliance legal
| actions_. Rather than, as the FSF and SFC seek: "Our primary
| goal in GPL enforcement is to bring about GPL compliance."
| (https://sfconservancy.org/copyleft-
| compliance/principles.htm...) The businesses of which Kuhn is
| critical seek instead "to 'convert' those FOSS users into
| paying customers for proprietary licensing for the same
| codebase."
|
| Arguably, the failure here might be of the GPL failing to
| specify what is an acceptable remedy, though if that were
| defanged to _only_ be "release affected code as <copyleft
| license>", it might afford too great a latitude to _other_
| forms of black-hat actors.
|
| I'm not sure if I agree with Kuhn's assessments or remedies. I
| think the discussion's worth having, and appreciate your input.
___________________________________________________________________
(page generated 2020-01-20 23:00 UTC)