Maybe the reason there's not much "public-domain" "closed-source" software is the same as there's not much "all rights reserved" "source-available" software:
There was lots of closed-source public domain software in earlier eras. The ethos of most of the non-commercial software on the British micros, for example, was never about the source.
Stuff written in BASIC naturally came with its own sources, but even then people would often obfuscate it to avoid derivative works being made. People wanted reputation, not money, and they didn't want their work ripped off, or for others to profit off their labours.
In the RISC OS community I was a part of, releasing source as a matter of course only became common with the influence of Linux. Before that, binary-only PD with homebrew or completely absent licensing was the norm.
Same on the C64, on the Amiga (where sometimes stuff had sources but no license), and on MS-DOS. Coverdisks often had PD on them and there were PD collections like Fish and later PD CD-ROMs.
Your comment about obfuscated BASIC is very interesting. Thanks for sharing.
Might you be able to mention any particularly important or memorable programs distributed that way? I'd be really interesting to go back and try to find contemporaneous writing about the motivations you mentioned.
Not so much important or memorable: most of the really important stuff on RISC OS was small-scale commercial. There was also a tendency to use BASIC minifiers to make the program fractionally faster and somewhat smaller, so the boundaries with obfuscation weren't that clear.
As for the contemporaneous writing, I'd start with the comp.sys.acorn.* newsgroup archive on Google Groups, because it's searchable (and I definitely remember this stuff being discussed in the late 90s, mainly as a reaction against the rise of Free Software.
Incidentally, the decline of the RISC OS market really brought home to me the value of having sources available (and being allowed to use them). We had two significant breaking architectural changes (StrongARM architecture in 96 and the move from ARM's 26-bit to 32-bit addressing mode in the 00s) which cost us a lot of good software because the authors had moved on and nobody could fix the code.
> There was also a tendency to use BASIC minifiers to make the program fractionally faster and somewhat smaller, so the boundaries with obfuscation weren't that clear.
Interesting!
> comp.sys.acorn.* newsgroup archive
Thanks!
> Incidentally, the decline of the RISC OS market really brought home to me the value of having sources available (and being allowed to use them).
I have a few of these stories, but now I have one more.
Commercial "source-available" software is probably more common than you realize -- it's more common in B2B and B2gov contexts than in B2C contexts though. You can be sure that when the US military buys licenses for software, they want to be able to audit the source code! Similarly, Tarsnap isn't open source but I provide the source code (and actively encourage people to audit it).
Not really. There are three main roles in todays software eco-system. The developer, the administrator and the user. Each have interests that are orthogonal to the interests others.
The developer wants to get paid to develop the source code.
The administrator wants to be able to modify and deploy the source code and be paid for running the resulting program.
The user wants to be able to review the source code and administration logs.
Open source as currently defined covers 100% of the interests of the administrators and none of the interests of the other groups.
The AGPL kind of covers some of the interests of the users.
Closed source protects the interests of the developer.
Being a member of all three groups I would be very interested in a license that manages the trade offs so the admins, in the guise of google and amazon, don't suck up all the money from developers and turn users into a commodity.
The Windows source code is available for some universities and some governmental agencies and some big companies, after signing a DNA and some additional paperwork, so it is somewhat in the "all rights reserved" "source-available" category.
I'm not sure if many webapps like gmail that have a big chunk of the UI in javascript count as "all rights reserved" "source-available". The code is minimized, obfuscated, and perhaps is the result of the transpilation of the real source, and it must talk to the servers that has not public source code.
There is plenty of source-available software, and I'd suggest your perception to the contrary might have more to do with thinking in the limited terms I described. For a recent example, isn't all software using the Commons Clause source-available, as I define it?
The reason there isn't much in the public-domain, closed-source quadrant is that permission without code is completely useless. For example:
I hereby grant you, m1el, an MIT license for the short novelty program I have just fixed in the tangible medium of expression know as my hard drive, project name Caveman. Enjoy!
Compare code without permission, which still has some limited value for others, especially educational and inspection value, as well as for the developers, in the form of access to free services.
I'd also put a number of public-patent-grant programs in that family. That's potentially much more interesting.
The article spends a lot of words to obfuscate the truth that their "third way" is traditional proprietary software. Their online license store offers two products:
* "Parity Public License" is a poorly drafted and extremely aggressive alternative to the AGPL, requiring users to "Contribute all source code for software you develop, deploy, monitor, or run with this software".
* "Prosperity Public License" is a proprietary shareware license with a 32-day free trial.
This license is trying to square the circle of having source code open to individuals who want to tinker with it and at most cover their costs, and those who want to build multi billion dollar empires out of it.
Facebook, Google and Amazon wouldn't be the monopolies they are today if the software cost of spinning up 1 server wasn't the same as the cost of spinning up 1,000,000.
This is a very hard problem where intention matters far more than anything concrete. I can run 50 copies of some IoT code and still have it be non-commerial, I can run one copy of linux and have it as the core of a multi million dollar business.
Today we have the problem of centralized servers far more than of secret source code. The GPL can't deal with this at all, and the AGPL is one small step in the right direction. Spreading the gains of the internet giants is one way of dealing with the problem of monopoly, one that is much less violent than splitting each company into several smaller ones that should compete against each other, as nearly happened to Microsoft.
> This license is trying to square the circle of having source
> code open to individuals who want to tinker with it and at
> most cover their costs, and those who want to build multi
> billion dollar empires out of it.
If the goal is to restrict which people use your software, then the solution is and always has been a proprietary license. Placing your software under a proprietary license allows you to say that specific companies can't use it, or people with specific political beliefs.
Open-source software can't be restricted to non-commercial use because that would violate the Open Source Definition (https://opensource.org/osd).
> Today we have the problem of centralized servers far more
> than of secret source code. The GPL can't deal with this at
> all, and the AGPL is one small step in the right direction.
You're free to choose a license that forbids commercial use of your software, or restricts use by businesses above some size threshold. Your software would then be proprietary software, not open-source, even if the entire source repository was public.
Mayhaps read the article? It covers why this is a very dangerous way of thinking that is destroying the non-corporate open source community.
Here's the relevant part:
<quote>
In the end, license experiments are a threat, but not a threat to open source as defined. They’re a threat to what open source sought, as a movement: recognition and collaboration with business concerns producing proprietary software. Patches to existing licenses and license ideas don’t change how effective unpatched terms remain for other work. Rather, innovation threatens the symbiosis of open source orthodoxy and enterprise-procurement-bound proprietary consumption. Holding permission back reduces what the shepherds of open source can lead back to large company-consumers. Offering a compelling middle way that better balances concerns for smaller players reduces the number of projects that end up under pushover licenses, for lack of better-fitting options, ready for selective assimilation by big-company incumbents. Incumbents that prefer outlast and out-compete to contribute and compensate, when it comes to projects not invented here.
</quote>
>Your software would then be proprietary software, not open-source, even if the entire source repository was public.
This view reminds me of the bad old debate about the fact that GPL was not an open source license. "How can it be open if it forces me to do thing I don't like? The only open license is the MIT license.". A more or less verbatim quote from the 00s on why Linux was doomed and should be classed as proprietary software.
I did read the article, twice. It's the article's job to explain how their proprietary license is compatible with the open-source definition, and it does not do so, because it can't.
If you go by the definition provided by the Open Source Initiative the following section means the GPL isn't an open license because it requires all software linked to it to be provided under the GPL too:
<quote>
9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
</quote>
GPL does not place restrictions on software that is distributed along with a GPL licensed piece of software. It places restrictions on software it is combined with.
I am using the definition you linked to: The OSI's definition.
> If you go by the definition provided by the Open Source
> Initiative the following section means the GPL isn't an
> open license because it requires all software linked to
> it to be provided under the GPL too:
This is not correct, and your own quote from the OSI site does not support your assertion. The GPL does not require that all portions of a derived work come from GPL'd code, and even if it did, that would not violate the OSI definition (which deals with combining works together for storage + transmission).
I don't know why you think the GPL isn't an open-source license, when it's listed prominently on https://opensource.org/licenses as OSI-approved.
License Zero has two public licenses, but the article covers React PATENTS, Commons Clause, Lerna MIT, Fair Source, JSON, HESSLA, and maybe a few others. There are nice diagrams showing "source available" separate from "open source".
I don't claim that any noncommercial license meets the OSD. I have and do argue my strong-copyleft license meets that definition, and acknowledge that's controversial.
Nobody, and crucially no legal right, makes it anybody's job to argue to the OSD. That is purely elective.
> There are nice diagrams showing "source available"
> separate from "open source".
That's good, because it's not open-source and is therefore proprietary. But also confusing, because if you're not claiming your license is open-source, then what exactly is the "third way in open software" from the title?
First way: Highly permissive licenses such as ISC, BSD, and Apache.
Second way: Copyleft licenses such as GPL and AGPL.
> because it's not open-source and is therefore proprietary
For reasons I point out in the post, I consider that implication harmful.
The third way referred to in the post is source-available software. Others may or may not include software under stronger-than-strong copyleft or reciprocal licenses, like my Parity or OSI-approved RPL, in that category.
> If the goal is to restrict which people use your software, then the solution is and always has been a proprietary license.
The goal is never to restrict which people use the software. The goal is to create incentives for individuals to actually make that software, make a living on that software, spend a few decades doing it. Which today requires certain protections from powerful organizations and overall from predatory capitalist incentives. Maybe a license forcing so much opening up, that makes businesses never consider allowing it if they are competing on software in any way, because too much openness makes competing on software automatically unviable, allowing competition to freely enter the market. Parity license seems a bit better at this than AGPL, but still doesn't feel like it's attacking the right issues.
It doesn't work like that. A Facebook employee could be restricted by Facebook's own policies from using the software with that license. But that doesn't mean the license is not open-source.
You're dancing around the issue. An open-source license is not allowed to distinguish between use by a hobbyist, a small business, and a multinational megacorp. If your license restricts commercial use then it's not an open-source license.
The Prosperity Public License restricts commercial use, therefore it is not an open-source license. You can't wordsmith your way out of this.
If you want to get picky with words, open source is actually a subset of free software, a rather inconsequential part of it since all GPL licensed software is free software first and foremost.
It started as a way to sell Linux to companies that didn't like Stallman. That you're trying to define away that history to people, such as myself, who were there when it happened and are still deeply ambivalent about the choices made is extremely disingenuous.
I think you're talking past another here. What is or isn't open source isn't the matter. OSI haven't prevented oligopoles from forming and locking people in to "the cloud" by making software a commodity, nor have they prevented GPL'd software (Linux) to become giant spyware in the form of Android, nor have they prevented software to be weaponized for other forms of monopolization (eg. Webkit based on KHTML). All the while original developers don't see any financial benefit to sustain further development. I doubt those outcomes are what the developers had in mind, or are in fact in the public interest. You can pontificate all day about OSS ideals dogmatically; just don't think that makes the world a better place. There is very much a need to express acceptable licensing and nuance beyond the current copyleft/non-copyleft dichotomy. And as discussed elsewhere in the thread, AGPL might not be the answer since it hasn't stood in court (and there are good reasons it won't), and anyway doesn't express whether you care more about receiving patches/PRs, or licensing royalties for commercial/unrestricted use when that is obviously something that many want to see expressed.
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:
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:
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.
> 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.
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.
> 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.
My post argues that a binary distinction between proprietary and open source is harmful. Those terms are both political and contested within the community. I am contesting them, and I'm not alone.
You might like to argue that your binary distinction is best. That's fine. But you're going to have to argue.
> The benefits of being open-source ought to accrue only to software that is open-source.
I would say that benefits ought to accrue to software according the benefit it brings. There is a lot of value in publishing source, even without an OSI- or FSF-approved license. That value ought to be recognized, not lumped in with software without public source. As I wrote in the post: "Publishing code alone brings many of the benefits currently imputed exclusively to open source under licenses like MIT and BSD."
> None of those cases are relevant to this discussion.
Vernor was decided _after_ enactment of 17 USC 117, addresses it directly, and cites the MAI Trio extensively. If you don't want to read the opinion, here's the EFF writeup:
They quote the holding, where the court uses the exact phrase "use restrictions".
If you want to argue that public licenses can't enforce use restrictions because they aren't written directly to the 17 USC 106 rights, and that incidental, inevitable exercise of at least the exclusive reproduction right doesn't count under 17 USC 117, you have to deal with the "owner" language there, and the clear deviation from the CONTU Report. And Vernor.
As for the CC-NC licenses, the parties in Great Minds didn't dispute that the use was noncommercial. IIRC, they clashed on another part of the license, namely whether the noncommercial user could have a third party exercise its license on its behalf.
Here's English coverage of a German court enforcing a CC-NC license in a pretty far reaching way:
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)
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:
I'm still confused about the paranoia around AGPL.
If MongoDB is AGPL, why does everyone else throw a shit fit? Despite its faults, MongoDB is still massively popular, so I assume it's used at many enterprises.
Also, side note: can anyone point a blog post (preferably from a lawyer) that explains why AGPL is so problematic?
Most open-source licenses are anchored in copyright law, which is "default deny": you don't have the right to copy other people's works unless they grant you permission. This is good because copyright law is well understood, but means the license itself can only be used to restrict behavior that require copyright permission.
The AGPL attempts to restrict behavior that does _not_ require copyright permission. If I have MongoDB running on my server and it serves as a datastore to my website, then no part of MongoDB is copied off my machine. Copyright doesn't apply. So the only way the AGPL can exist is if it's _not_ a copyright license.
But if the AGPL isn't a copyright license, what _is_ it? Is it a contract with no consideration? Is it a copyright license _combined with_ a contract? Is it like a EULA, and if so, how does it apply when the apparent end-user (the person visiting my site) hasn't accepted the terms?
Lawyers don't like these sort of pseudo-contract legal constructs, they're the law equivalent of a flaky hour-long integration test.
It's an interesting point, but I think you are looking at it from the wrong point of view. As far as I understand, the AGPL kicks in on "propagation" -- which in the important case means "making available to the public". The license is with the operator of the service, not with the end user of the software.
The consideration is the software itself. In exchange, you are granted a license. The license requires (in part) that you offer the source code to any user that uses the software. As the service provider, it is copyright infringement to make available the AGPL licensed software unless you agree to the license.
The problem with MongoDB is that they are using the AGPL in a way in which it wasn't intended to be used. This confuses the issue about what you are and are not allowed to do.
> As far as I understand, the AGPL kicks in on "propagation"
> -- which in the important case means "making available to
> the public".
That's the GPL, and more broadly, all copyright-based licenses. The AGPL was invented to handle software that didn't need to be downloaded to be interacted with. Think of an HTTP server -- the end user interacts with it, but doesn't download the server binary itself. The AGPL is designed to let the end user have access to the server's source code in that situation.
You're confusing propagation with conveyance (which is admittedly very easy to do). From the license:
- To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
- To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
They make the distinction in the AGPL (which I think they don't in the GPL) for exactly the reason you state.
It's exactly the same with any proprietary server software. You can have a copy of the software, but without a license to allow others to run it, then you can't make it available on a network. These days most server software explicitly allows unlimited use in their license, but in the old days it was always per seat licencing.
If the AGPL is invalid, then so are all extant proprietary server licenses.
> If the AGPL is invalid, then so are all extant proprietary server licenses.
I didn't say the AGPL is invalid, I only said it's not a copyright license. Proprietary software sold by the seat uses a contract -- I pay money for permission to have X concurrent sessions or Y unique users.
The GPLv3 does distinguish propagation and conveyance. This allows the license to put fewer restrictions on certain types of copying that are relevant to large organizations.
OK. I see where you are coming from now. I disagree with you that the AGPL and prorietary software licenses are not copyright licenses. You only need a license because otherwise you are not allowed to use the software in that way -- because of copyright.
If I'm a server software producer and I sell you a copy of a piece of software, you can't actually use it unless I also give you a license to use it. This is unlike any other kind of machine that I might make and sell to you. If I sell you my fancy coffee roaster, I literally can not force you to use it in a specific way. This is actually why printer manufacturers put software in the ink cartridges -- so that they can force you to agree to a usage license.
The reasoning behind being able to extend copyright to running programs (which I think is BS, personally, but I don't make up the laws) is that the computer that runs the software must load, and therefore copy, the software. You only have permission to do that if the copyright holder gives you permission to do that.
This is where the license comes in. I give you a license to load the software into running memory (and hence run it), on the provision that you follow the rules I state. You don't have to agree to the license, but if you don't agree, then you don't have a license, and you are forbidden by copyright law from running the software.
With the AGPL, the license is given provided that you agree to give the users a compatible license to the software. Again, the contract consideration is: ability to run the software in exchange for agreeing to the terms.
You are right that the GPLv3 does reference propagation. I should have looked. It mentions it specifically to state that the GPL does not come into effect on propagation, only conveyance (which is the main difference between it and the AGPL).
I know some lawyers who would prefer and argue for your reading of copyright law's limitations, as a matter of policy. But that is not the reading that I see in court decisions or professionally drafted copyright licenses, which impose blanket use and purpose restrictions all the time.
I read both those blog posts, which manage to be both over-long and free of concrete content. Which particular part of them do you feel is relevant to this thread?
> But that is not the reading that I see in court decisions
> or professionally drafted copyright licenses, which impose
> blanket use and purpose restrictions all the time.
Please link to an American, Canadian, or EU court decision holding that restrictions on use are enforceable via copyright law. I'll also accept a recent ruling that execution of a copyrighted program does not automatically qualify as fair use.
You can see a response I've just posted on Vernor and Deutschlandradio. You may also wish to peruse common proprietary license forms, as I mention in Free to Take Freedom Post.
I won't be providing you any further comments. If you have need of specific guidance in this legal area, please seek your own legal counsel.
This is a better summary of the key issue than any I've read from a lawyer.
The root of it is that the copyleft licensing scheme was from the beginning merely a clever hack. Ideally (from a free software perspective) copyright law would not protect functional software, and we would have another law that requires all published software to be free software.
The GPL was a speculative attempt to bend problematic copyright laws to the purposes of free software. Over time the GPL has proven to work, sort of. But it was not clear at the beginning that it would. Years, decades, have gone by and we now see that there are ways for companies to restrict user freedoms with software that technically complies with the GPL. The GPL was pretty successful for the 1990s concerns, why not make an updated license that addresses 21st Century business models. It is still not clear whether the AGPL will work as well vs SaaS as GPL did against the "selling copies" model.
I can only give you my opinion as I'm not involved with MongoDB, I'm not a lawyer and I'm not an expert on AGPL. However, I spend a fair bit of my spare time reading licenses and thinking about them.
There are really 2 issues you need to keep in mind: 1) there is a difference of opinion about whether linking to an unmodified, GPL or AGPL licensed library is considered to be a "modification" of that library; 2) GPL and AGPL are different in terms of software that is only accessed via a network (i.e., the user does not receive a copy of the executable code).
In the first point, the FSF (who maintains these licenses) believes that linking to a GPL or AGPL license creates a "combined work" that requires a license that is compatible with the GPL or AGPL. In other words, you can't "convey" (distribute) the combined program unless the overall license has compatible terms. Other people disagree. To my knowledge, this point has not been tested in court. While the GPL itself is well tested in court now, that is for applications that are clearly based on a GPL licensed piece of code. Whether or not a library that is providing a utility function has that same legal protection is still untested (as far as I know).
However, there are a couple of things that I think are important about this. First, the intent of the licenses is clear. It's a completely jerk move to use a GPL or AGPL licensed library without considering the intent of the authors that chose that license. You might get away with it legally, but why be a jerk just to save a few bucks? (Not that it stops people...) Secondly, the intent of the license is clear, if you want people to use the software in a different way, please pick a different license! There are many appropriate licenses (and probably the LGPL is what a project like MongoDB should be licensed as). I'll talk a bit about that at the end.
With the second point, it's important to understand the difference in use cases for the GPL and AGPL. The GPL is intended for applications that are meant to be "conveyed" (distributed) to the user. The user then runs the program themselves. With a GPL or similar license, they enjoy the 4 freedoms of being able to run the software for any purpose, inspect the source code, modify the source code, and to distribute their modifications if they wish (as long as they grant the 4 freedoms to their users).
The AGPL is designed to give similar freedoms to people who do not receive an executable -- their only interact with the software is through the network. The only reason for choosing the AGPL is to ensure that users can receive the source code to: run the code for any purpose (rather than just the purpose the service provider allows), inspect the source code, modify the source code, and distribute their changes.
I don't know the history of MongoDB, so I don't know why they chose the AGPL. It is frankly a bizarre choice, IMHO. My only guess is that they intended that users of an online service be given access to the MongoDB source code. Why they thought that was important, I really don't know. The MongoDB developers are pretty adamant that the license does not restrict people from building services that are not AGPL.
In practical terms, for the moment anyway, it's not a big deal. Even if the AGPL applies to the combined software (and FWIW, I believe that it does), the only people who have standing to sue are the copyright holders of MongoDB. They have clearly said that they are happy with people not offering the 4 freedoms when making services using MongoDB. In other words, you can be relatively sure they aren't going to sue you -- and nobody else has standing to do so.
On the other hand, it's still a legal liability. If MongoDB changes hands some day and the new copyright holder has a different opinion, will you end up getting sued? Although I think it is incredibly unlikely,...
One obvious possibility is that MongoDB's choice of license is a strategic attempt at price discrimination. Since it's available under an accepted open source license, individual developers and small startups won't shy away from it, but large enterprises that are afraid of AGPL have to pay for a commercial license.
As an active maintainer of a popular 8.8K+ starred Open Source project, I can attest to how hard and difficult it is to run, fund, finance, etc.
But, at the end of the day, there is no excuse - we cannot sacrifice our ideals/values just because Open Source can be rough.
True Open Source is worth making the sacrifice for, but there are a lot of new/old licenses trying to evangelize themselves as "Open Source" but are secretly masked proprietary/cripple-ware. This needs to be stopped.
A noncommercial license like Prosperity differs from a permissive license like MIT only in withholding permission for unlimited, free commercial use. If that delta holds your value system, then your value system amounts to business welfare, financed largely by individual sacrifices. That's a strange kind of martyrdom.
There's no question that useful software that costs for commercial use produces less economy-wide benefit than useful software that's always free of charge. But the question isn't how much potential benefit open source can pump out, but rather how much benefit open source can pump out for the cost, and how that cost gets allocated.
I've never held Prosperity, or its predecessor, out as open source licenses in the traditional sense. Others have called them so, even after I pointed out my own opinion.
I have and do hold Parity out as an open source license. If copyleft licenses don't meet your definition of open source, or only copyleft licenses with known, practical software-freedom vulnerabilities, I can certainly square that with your view of open source's purpose. But I can't square it with open source's history, or with most stacks we call "open source".
Commercial freedom is an important part of the "free" in free software, no? The values you're calling strange are basically the ethics of RMS. Perhaps there is a bit of a martyrdom to RMS' lifestyle, but I would hardly say that his ethics are strange at this point.
I think it would work better to argue, open source is about leaving aside the ethical considerations (which are highly charged topics) to focus on how effective is code sharing as a development methodology, and within that, what licensing regime under current law works best from a business perspective. And the question is different for an academic talking about larger society, vs. an individual business or developer who is choosing his/her/its own license. Obviously your duty as an attorney is to grapple with the latter question.
Thus, while I personally am more or less with RMS on the ethical inquiry, I see no reason why your L0 ideas should not be discussed within the context of open source. I personally would not choose to use your license, but that is irrelevant.
One point of errata in your essay: free software (I hope) does not depend on copyright protection. Far from it. Free software viewpoint is that copyright protection should not extend to software. Rather, the law should require published software to be free software.
However, given that the law is not going to change anytime soon, the GPL was written as a clever hack to use copyright to promote the values of software freedom. This has been successful to some degree, so it is a perfectly fair question to ask what we would do for software freedom if copyright protection as we know it today did not extend to functional software. But this is probably not a question that would be asked within the context of "open source" I guess...
I can't speak for RMS. He can speak plenty well for himself! I do try to understand him. On use restrictions and the limits of copyleft, I haven't always been able to find answers:
I can speak about APGL. They limit commercial freedom, specifically the right to commercialize software incorporating AGPL code, and either distribute it or provide it as a network service without source or a similar license. In other words: the freedom to make and market software in the usual commercial way. A limitation on Freedom 3 (to share changes)? The FSF says so. A limitation on Freedom 0 (to run the software)? They don't say, but I think so.
I also think you're right that software freedom doesn't depend on copyright. Copyright is merely a means to it, via copyleft. But if the law required freeing of software, that would restrict commercial freedom publicly in the same way AGPL does by private ordering. Unfortunately, that law would also have to require disclosure or publication of source code, and conformance on all the other fronts where AGPL fights: patent law and DRM, for example.
That's a far more expansive legislative program than abolishing copyright. Abolish copyright, and I can keep my code secret. And lock others' code down with patents. And so on. Many laws affect software freedom!
> I see no reason why your L0 ideas should not be discussed within the context of open source.
If making software in the open made sense to more people, we'd get more of it. Many of those projects might start as source-available, and end up copyleft or permissive open source. But instead of paving that path, we shame it as proprietary, and lump it in with Windows.
Open source orthodoxy is right about transaction costs and efficiency on the consumer side, but totally abdicates the supply side of software production. I've read on their mailing list that if you have to ask how you're going to make money making open source, you're the wrong person to be making open source, and that OSI doesn't owe any cycles on any business model.
> And the question is different for an academic talking about larger society, vs. an individual business or developer who is choosing his/her/its own license. Obviously your duty as an attorney is to grapple with the latter question.
I can't tell you how much it means to read that. Thank you for acknowledging. It gets lost.
Thank you for this thoughtful response! I have been following your work with interest for awhile. These are all hard questions, and I don't see many people coming up with new ideas here, not to mention implementing them in elegant software.
I have no problem with somebody deciding that a shareware or dual-licensing model are the best choice for their business. But it's incredibly toxic for the people pursuing those models to muddy and contort the accepted definition of "open" in order to misrepresent what they are doing.
It's deeply disingenuous for this blog post to use the word "bullying" to describe the community's rejection of software distributed under undesirable or ill-considered terms. You can ship your code under whatever terms you want, but don't act like users and contributors have an obligation to support you when you make choices that don't serve their interests.
If you mean the Open Source Definition, I once shared your view. I can't any longer. Most times I bring it up, my conversation partner has never heard of it. When I explain, most times they don't care.
As for "bullying", that very adequately describes behavior on GitHub, Twitter, mailing lists, and news sites toward those behind React, Commons Clause projects, and Lerna. "Failure to support" is a straw man.
> Most times I bring [Open Source Definition] up, my conversation partner has never heard of it.
That really doesn't matter. All they know about open source is based on this definition. There millions of articles about open source on the internet that use it. You are trying to invalidate all of them for no good reason. As a consequence every opinion about open source they ever read prior to your efforts would be outdated. Most people understand danger of these actions which leads to behavior you described as "bullying".
> All they know about open source is based on this definition.
The Open Source Definition says nothing about source control, patch submission, bug tracking, releases, versioning, dependencies, package repositories, continuous integration, test coverage, style guides, codes of conduct, and so on. There are also articles on the Internet that talk about a "post-Open Source" GitHub generation, and articles that affirmatively reject definitions of open source in terms of license conditions, rather than community. OSI has been controversial since inception, and there's plenty about that, too.
If the OSD were merely a descriptive framework, that would be one thing. "Here is a class of licenses we can describe, and here are benefits we can correlate with them." But OSD gets used far beyond that. It's used prescriptively. It's used to sanction. Those are social functions of a movement, and the crux of a movement is participation, not definition. It matters that people making open source haven't heard of OSD, because they neither participated in its adoption nor consented to its authority. It has no sway over them. The idea that a mailing list could define their community rankles.
I don't consider debate about OSD, DFSG, or "What is free software?" bullying. I do consider peer pressure on maintainers to adopt terms that don't advance their goals, against their stated interests, bullying. I consider unfounded legal FUD to the same effect bullying. Have a look at the Lerna GitHub issues, or Twitter conversation about Commons Clause.
> The Open Source Definition says nothing about [very long list]
There is nothing in your list that is different for open-source and proprietary software development. You could as well add countless articles about OOP and functional programming because they mention some open-source tools.
OSD is about answering three simple questions. Should I use some program or library? Should I contribute to its development? Should I release my new program or lib as open-source? OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff. He doesn't need to know OSD and read full texts of licenses as long as he uses most adopted like MTI, BSD, GPL. Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I can't sell some project based on Lerna to [list of companies] ? OK. How am I supposed to check that the company didn't change name? What if I am selling my work to subcontractor? I would probably have to include this list in every contract. What if every open-source project started banning some arbitrary list of companies? Am I supposed to review the last commit to license every time to make sure that my company wasn't included? All that looks, sounds and smells like a lot of headache and any reasonable person would drop the project with first sign of it.
Commons Clause was even worse. It was advertised as "MTI+CC", but nobody would be able to figure out what "CC" part meant for them without a lawyer. And any lawyer would advise to find something else.
> There is nothing in your list that is different for open-source and proprietary software development.
That's not right, even assuming full "Innersource".
My point was that OSD is a set of criteria for licenses, plus a source-availability requirement. Those criteria don't predetermine all the practices that make up open source development right now. Those practices have changed! The OSD largely hasn't.
> OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff.
If you've managed to avoid all weird legal stuff so far, I'm glad for you. A good portion of my legal career is addressing weird legal stuff, which crops up even with MIT, BSD, and GPL, to use your list. The GPLs and other copyleft licenses are chock full of weird legal stuff.
> Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I wrote one of the more popular guides to MIT in layman's terms:
The License Zero licenses are far easier to read, besides. That was part of the point of writing them from scratch.
> What if every open-source project started banning some arbitrary list of companies?
Highly unlikely. And that is not the approach of the License Zero licenses, React, Commons Clause, or most others that I mention.
If somehow this did become popular---again, very hypothetical---I'd go into npm and RubyGems and other package managers, and propose a package metadata field for excluded entities, and perhaps standardized categorical exclusions. This still sounds inconvenient, and I agree that it would be. But to give you a sense of near current practice, some large companies prohibit use of open source from specific competitors, even under permissive licenses, especially when the patent terms of the license are weak or nonexistent. That would include MIT, BSD, and GPLv2.
> And any lawyer would advise to find something else.
Or do a deal with Redis Labs. Which was the point, I think.
Would we have this discussion if the authors of powerful software powering multi billion dollar enterprises benefited more?
I wonder what happens when these peolle are given financial security?
As an investment in the future, the returns could be amazing! Many, if not all, authors really care and it shows.
Would making sure they are free to care, live well, maybe create more be such a bad thing?
Secondly, with that on the table, I wonder about the quality, and drive to create like that. We may see amazing tools.
Re: Open Source
Being able to see the source is high value. Being able to build on others work is high value.
Arguably, high enough value to trigger this kind of mess.
Pay them. Seriously.
Is the problem one of ego? AwesomeSauce.com wants to be recognized and get value from their work. Is recognizing CantLiveWithout DB or Language, Toolkit, etc... taking away from all that somehow?
Is it one of confusion?
AwesomeSauce.com paid, only to see AlsoAwesomeSauce.com not pay?
Does that matter, if bazillions are being made?
Seems to me this all can be litigated to our mutual detriment, or it can be handled as a family struggle, or worse.
Have to say, I do not blsme people looking hard at billion dollar enterprises, and their many big fix, support requests with a jaded eye, maybe a hungry one.
Fixing that scenario may well be ultra cheap compared to the mess and opportunity costs to come.
I put this here to stimulate some discussion, not as judgement, or anything aimed at anyone.
Really open licenses are a good thing. Really, really good thing. Many of us know the story. Pick up some code, any computer we can find and just build.
Breaking that seems extreme. Maybe it just does not need to be that way.
Maybe it should not.
What is worth what here?
Perhaps those conversations go far easier than the current ones will, and it is not like tech as a whole can't afford a solution.
Again, not a negative, or statement against anyone. Just thinking out loud here.
There is some resistance in these discussions though. Some people don't seem to like the idea of not being able to commercially benefit from free software for free, while working at organizations abusively dominating markets. Sort of oxymoron, restricting freedoms using unrestricted freedoms. The supply of unrestricted will dry out of course, as somebody has to pay for all of this. Either way changes are inevitable.
70 comments
[ 2.3 ms ] story [ 148 ms ] threadhttps://i.imgur.com/bSdusjH.png
It's not about "two-party system", it's about the "natural" distribution of software distribution models.
Stuff written in BASIC naturally came with its own sources, but even then people would often obfuscate it to avoid derivative works being made. People wanted reputation, not money, and they didn't want their work ripped off, or for others to profit off their labours.
In the RISC OS community I was a part of, releasing source as a matter of course only became common with the influence of Linux. Before that, binary-only PD with homebrew or completely absent licensing was the norm.
https://en.wikipedia.org/wiki/Fred_Fish
Might you be able to mention any particularly important or memorable programs distributed that way? I'd be really interesting to go back and try to find contemporaneous writing about the motivations you mentioned.
As for the contemporaneous writing, I'd start with the comp.sys.acorn.* newsgroup archive on Google Groups, because it's searchable (and I definitely remember this stuff being discussed in the late 90s, mainly as a reaction against the rise of Free Software.
Incidentally, the decline of the RISC OS market really brought home to me the value of having sources available (and being allowed to use them). We had two significant breaking architectural changes (StrongARM architecture in 96 and the move from ARM's 26-bit to 32-bit addressing mode in the 00s) which cost us a lot of good software because the authors had moved on and nobody could fix the code.
Interesting!
> comp.sys.acorn.* newsgroup archive
Thanks!
> Incidentally, the decline of the RISC OS market really brought home to me the value of having sources available (and being allowed to use them).
I have a few of these stories, but now I have one more.
The developer wants to get paid to develop the source code.
The administrator wants to be able to modify and deploy the source code and be paid for running the resulting program.
The user wants to be able to review the source code and administration logs.
Open source as currently defined covers 100% of the interests of the administrators and none of the interests of the other groups.
The AGPL kind of covers some of the interests of the users.
Closed source protects the interests of the developer.
Being a member of all three groups I would be very interested in a license that manages the trade offs so the admins, in the guise of google and amazon, don't suck up all the money from developers and turn users into a commodity.
https://www.microsoft.com/en-us/sharedsource/
I'm not sure if many webapps like gmail that have a big chunk of the UI in javascript count as "all rights reserved" "source-available". The code is minimized, obfuscated, and perhaps is the result of the transpilation of the real source, and it must talk to the servers that has not public source code.
The reason there isn't much in the public-domain, closed-source quadrant is that permission without code is completely useless. For example:
I hereby grant you, m1el, an MIT license for the short novelty program I have just fixed in the tangible medium of expression know as my hard drive, project name Caveman. Enjoy!
Compare code without permission, which still has some limited value for others, especially educational and inspection value, as well as for the developers, in the form of access to free services.
I'd also put a number of public-patent-grant programs in that family. That's potentially much more interesting.
* "Parity Public License" is a poorly drafted and extremely aggressive alternative to the AGPL, requiring users to "Contribute all source code for software you develop, deploy, monitor, or run with this software".
* "Prosperity Public License" is a proprietary shareware license with a 32-day free trial.
This license is trying to square the circle of having source code open to individuals who want to tinker with it and at most cover their costs, and those who want to build multi billion dollar empires out of it.
Facebook, Google and Amazon wouldn't be the monopolies they are today if the software cost of spinning up 1 server wasn't the same as the cost of spinning up 1,000,000.
This is a very hard problem where intention matters far more than anything concrete. I can run 50 copies of some IoT code and still have it be non-commerial, I can run one copy of linux and have it as the core of a multi million dollar business.
Today we have the problem of centralized servers far more than of secret source code. The GPL can't deal with this at all, and the AGPL is one small step in the right direction. Spreading the gains of the internet giants is one way of dealing with the problem of monopoly, one that is much less violent than splitting each company into several smaller ones that should compete against each other, as nearly happened to Microsoft.
Open-source software can't be restricted to non-commercial use because that would violate the Open Source Definition (https://opensource.org/osd).
You're free to choose a license that forbids commercial use of your software, or restricts use by businesses above some size threshold. Your software would then be proprietary software, not open-source, even if the entire source repository was public.Here's the relevant part:
<quote> In the end, license experiments are a threat, but not a threat to open source as defined. They’re a threat to what open source sought, as a movement: recognition and collaboration with business concerns producing proprietary software. Patches to existing licenses and license ideas don’t change how effective unpatched terms remain for other work. Rather, innovation threatens the symbiosis of open source orthodoxy and enterprise-procurement-bound proprietary consumption. Holding permission back reduces what the shepherds of open source can lead back to large company-consumers. Offering a compelling middle way that better balances concerns for smaller players reduces the number of projects that end up under pushover licenses, for lack of better-fitting options, ready for selective assimilation by big-company incumbents. Incumbents that prefer outlast and out-compete to contribute and compensate, when it comes to projects not invented here. </quote>
>Your software would then be proprietary software, not open-source, even if the entire source repository was public.
This view reminds me of the bad old debate about the fact that GPL was not an open source license. "How can it be open if it forces me to do thing I don't like? The only open license is the MIT license.". A more or less verbatim quote from the 00s on why Linux was doomed and should be classed as proprietary software.
What is your definition of open source?
If you go by the definition provided by the Open Source Initiative the following section means the GPL isn't an open license because it requires all software linked to it to be provided under the GPL too:
<quote> 9. License Must Not Restrict Other Software
The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software. </quote>
https://opensource.org/osd
I don't know why you think the GPL isn't an open-source license, when it's listed prominently on https://opensource.org/licenses as OSI-approved.
I don't claim that any noncommercial license meets the OSD. I have and do argue my strong-copyleft license meets that definition, and acknowledge that's controversial.
Nobody, and crucially no legal right, makes it anybody's job to argue to the OSD. That is purely elective.
First way: Highly permissive licenses such as ISC, BSD, and Apache.
Second way: Copyleft licenses such as GPL and AGPL.
Third way: ?
For reasons I point out in the post, I consider that implication harmful.
The third way referred to in the post is source-available software. Others may or may not include software under stronger-than-strong copyleft or reciprocal licenses, like my Parity or OSI-approved RPL, in that category.
The goal is never to restrict which people use the software. The goal is to create incentives for individuals to actually make that software, make a living on that software, spend a few decades doing it. Which today requires certain protections from powerful organizations and overall from predatory capitalist incentives. Maybe a license forcing so much opening up, that makes businesses never consider allowing it if they are competing on software in any way, because too much openness makes competing on software automatically unviable, allowing competition to freely enter the market. Parity license seems a bit better at this than AGPL, but still doesn't feel like it's attacking the right issues.
To qualify as an open-source license, the answer must be "yes". Otherwise the license is restricting who can use your software.
The Prosperity Public License restricts commercial use, therefore it is not an open-source license. You can't wordsmith your way out of this.
It started as a way to sell Linux to companies that didn't like Stallman. That you're trying to define away that history to people, such as myself, who were there when it happened and are still deeply ambivalent about the choices made is extremely disingenuous.
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-...
https://mjg59.dreamwidth.org/49370.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...
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.
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.
You might like to argue that your binary distinction is best. That's fine. But you're going to have to argue.
> The benefits of being open-source ought to accrue only to software that is open-source.
I would say that benefits ought to accrue to software according the benefit it brings. There is a lot of value in publishing source, even without an OSI- or FSF-approved license. That value ought to be recognized, not lumped in with software without public source. As I wrote in the post: "Publishing code alone brings many of the benefits currently imputed exclusively to open source under licenses like MIT and BSD."
> None of those cases are relevant to this discussion.
Vernor was decided _after_ enactment of 17 USC 117, addresses it directly, and cites the MAI Trio extensively. If you don't want to read the opinion, here's the EFF writeup:
https://www.eff.org/cases/vernor-v-autodesk
They quote the holding, where the court uses the exact phrase "use restrictions".
If you want to argue that public licenses can't enforce use restrictions because they aren't written directly to the 17 USC 106 rights, and that incidental, inevitable exercise of at least the exclusive reproduction right doesn't count under 17 USC 117, you have to deal with the "owner" language there, and the clear deviation from the CONTU Report. And Vernor.
As for the CC-NC licenses, the parties in Great Minds didn't dispute that the use was noncommercial. IIRC, they clashed on another part of the license, namely whether the noncommercial user could have a third party exercise its license on its behalf.
Here's English coverage of a German court enforcing a CC-NC license in a pretty far reaching way:
https://www.techdirt.com/articles/20140326/11405526695/germa...
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)
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
If MongoDB is AGPL, why does everyone else throw a shit fit? Despite its faults, MongoDB is still massively popular, so I assume it's used at many enterprises.
Also, side note: can anyone point a blog post (preferably from a lawyer) that explains why AGPL is so problematic?
The AGPL attempts to restrict behavior that does _not_ require copyright permission. If I have MongoDB running on my server and it serves as a datastore to my website, then no part of MongoDB is copied off my machine. Copyright doesn't apply. So the only way the AGPL can exist is if it's _not_ a copyright license.
But if the AGPL isn't a copyright license, what _is_ it? Is it a contract with no consideration? Is it a copyright license _combined with_ a contract? Is it like a EULA, and if so, how does it apply when the apparent end-user (the person visiting my site) hasn't accepted the terms?
Lawyers don't like these sort of pseudo-contract legal constructs, they're the law equivalent of a flaky hour-long integration test.
The consideration is the software itself. In exchange, you are granted a license. The license requires (in part) that you offer the source code to any user that uses the software. As the service provider, it is copyright infringement to make available the AGPL licensed software unless you agree to the license.
The problem with MongoDB is that they are using the AGPL in a way in which it wasn't intended to be used. This confuses the issue about what you are and are not allowed to do.
- To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
- To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
They make the distinction in the AGPL (which I think they don't in the GPL) for exactly the reason you state.
It's exactly the same with any proprietary server software. You can have a copy of the software, but without a license to allow others to run it, then you can't make it available on a network. These days most server software explicitly allows unlimited use in their license, but in the old days it was always per seat licencing.
If the AGPL is invalid, then so are all extant proprietary server licenses.
The GPLv3 does distinguish propagation and conveyance. This allows the license to put fewer restrictions on certain types of copying that are relevant to large organizations.
If I'm a server software producer and I sell you a copy of a piece of software, you can't actually use it unless I also give you a license to use it. This is unlike any other kind of machine that I might make and sell to you. If I sell you my fancy coffee roaster, I literally can not force you to use it in a specific way. This is actually why printer manufacturers put software in the ink cartridges -- so that they can force you to agree to a usage license.
The reasoning behind being able to extend copyright to running programs (which I think is BS, personally, but I don't make up the laws) is that the computer that runs the software must load, and therefore copy, the software. You only have permission to do that if the copyright holder gives you permission to do that.
This is where the license comes in. I give you a license to load the software into running memory (and hence run it), on the provision that you follow the rules I state. You don't have to agree to the license, but if you don't agree, then you don't have a license, and you are forbidden by copyright law from running the software.
With the AGPL, the license is given provided that you agree to give the users a compatible license to the software. Again, the contract consideration is: ability to run the software in exchange for agreeing to the terms.
You are right that the GPLv3 does reference propagation. I should have looked. It mentions it specifically to state that the GPL does not come into effect on propagation, only conveyance (which is the main difference between it and the AGPL).
Edit: spelling
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
Especially this section:
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
I know some lawyers who would prefer and argue for your reading of copyright law's limitations, as a matter of policy. But that is not the reading that I see in court decisions or professionally drafted copyright licenses, which impose blanket use and purpose restrictions all the time.
To your point, copyright law is "default deny". (See also: https://oss.kemitchell.com/#defaults-and-overrides) Take as given that the uncertainty you describe is as serious as you present it. Who does that uncertainty benefit, in context? Consider: https://opensource.google.com/docs/using/agpl-policy/
I won't be providing you any further comments. If you have need of specific guidance in this legal area, please seek your own legal counsel.
The root of it is that the copyleft licensing scheme was from the beginning merely a clever hack. Ideally (from a free software perspective) copyright law would not protect functional software, and we would have another law that requires all published software to be free software.
The GPL was a speculative attempt to bend problematic copyright laws to the purposes of free software. Over time the GPL has proven to work, sort of. But it was not clear at the beginning that it would. Years, decades, have gone by and we now see that there are ways for companies to restrict user freedoms with software that technically complies with the GPL. The GPL was pretty successful for the 1990s concerns, why not make an updated license that addresses 21st Century business models. It is still not clear whether the AGPL will work as well vs SaaS as GPL did against the "selling copies" model.
There are really 2 issues you need to keep in mind: 1) there is a difference of opinion about whether linking to an unmodified, GPL or AGPL licensed library is considered to be a "modification" of that library; 2) GPL and AGPL are different in terms of software that is only accessed via a network (i.e., the user does not receive a copy of the executable code).
In the first point, the FSF (who maintains these licenses) believes that linking to a GPL or AGPL license creates a "combined work" that requires a license that is compatible with the GPL or AGPL. In other words, you can't "convey" (distribute) the combined program unless the overall license has compatible terms. Other people disagree. To my knowledge, this point has not been tested in court. While the GPL itself is well tested in court now, that is for applications that are clearly based on a GPL licensed piece of code. Whether or not a library that is providing a utility function has that same legal protection is still untested (as far as I know).
However, there are a couple of things that I think are important about this. First, the intent of the licenses is clear. It's a completely jerk move to use a GPL or AGPL licensed library without considering the intent of the authors that chose that license. You might get away with it legally, but why be a jerk just to save a few bucks? (Not that it stops people...) Secondly, the intent of the license is clear, if you want people to use the software in a different way, please pick a different license! There are many appropriate licenses (and probably the LGPL is what a project like MongoDB should be licensed as). I'll talk a bit about that at the end.
With the second point, it's important to understand the difference in use cases for the GPL and AGPL. The GPL is intended for applications that are meant to be "conveyed" (distributed) to the user. The user then runs the program themselves. With a GPL or similar license, they enjoy the 4 freedoms of being able to run the software for any purpose, inspect the source code, modify the source code, and to distribute their modifications if they wish (as long as they grant the 4 freedoms to their users).
The AGPL is designed to give similar freedoms to people who do not receive an executable -- their only interact with the software is through the network. The only reason for choosing the AGPL is to ensure that users can receive the source code to: run the code for any purpose (rather than just the purpose the service provider allows), inspect the source code, modify the source code, and distribute their changes.
I don't know the history of MongoDB, so I don't know why they chose the AGPL. It is frankly a bizarre choice, IMHO. My only guess is that they intended that users of an online service be given access to the MongoDB source code. Why they thought that was important, I really don't know. The MongoDB developers are pretty adamant that the license does not restrict people from building services that are not AGPL.
In practical terms, for the moment anyway, it's not a big deal. Even if the AGPL applies to the combined software (and FWIW, I believe that it does), the only people who have standing to sue are the copyright holders of MongoDB. They have clearly said that they are happy with people not offering the 4 freedoms when making services using MongoDB. In other words, you can be relatively sure they aren't going to sue you -- and nobody else has standing to do so.
On the other hand, it's still a legal liability. If MongoDB changes hands some day and the new copyright holder has a different opinion, will you end up getting sued? Although I think it is incredibly unlikely,...
But, at the end of the day, there is no excuse - we cannot sacrifice our ideals/values just because Open Source can be rough.
True Open Source is worth making the sacrifice for, but there are a lot of new/old licenses trying to evangelize themselves as "Open Source" but are secretly masked proprietary/cripple-ware. This needs to be stopped.
We had a good discussion about this on Twitter the other day: https://twitter.com/marknadal/status/1032763711008559104
There's no question that useful software that costs for commercial use produces less economy-wide benefit than useful software that's always free of charge. But the question isn't how much potential benefit open source can pump out, but rather how much benefit open source can pump out for the cost, and how that cost gets allocated.
I've never held Prosperity, or its predecessor, out as open source licenses in the traditional sense. Others have called them so, even after I pointed out my own opinion.
I have and do hold Parity out as an open source license. If copyleft licenses don't meet your definition of open source, or only copyleft licenses with known, practical software-freedom vulnerabilities, I can certainly square that with your view of open source's purpose. But I can't square it with open source's history, or with most stacks we call "open source".
I think it would work better to argue, open source is about leaving aside the ethical considerations (which are highly charged topics) to focus on how effective is code sharing as a development methodology, and within that, what licensing regime under current law works best from a business perspective. And the question is different for an academic talking about larger society, vs. an individual business or developer who is choosing his/her/its own license. Obviously your duty as an attorney is to grapple with the latter question.
Thus, while I personally am more or less with RMS on the ethical inquiry, I see no reason why your L0 ideas should not be discussed within the context of open source. I personally would not choose to use your license, but that is irrelevant.
One point of errata in your essay: free software (I hope) does not depend on copyright protection. Far from it. Free software viewpoint is that copyright protection should not extend to software. Rather, the law should require published software to be free software.
However, given that the law is not going to change anytime soon, the GPL was written as a clever hack to use copyright to promote the values of software freedom. This has been successful to some degree, so it is a perfectly fair question to ask what we would do for software freedom if copyright protection as we know it today did not extend to functional software. But this is probably not a question that would be asked within the context of "open source" I guess...
https://blog.licensezero.com/2018/09/14/free-to-take-freedom...
I can speak about APGL. They limit commercial freedom, specifically the right to commercialize software incorporating AGPL code, and either distribute it or provide it as a network service without source or a similar license. In other words: the freedom to make and market software in the usual commercial way. A limitation on Freedom 3 (to share changes)? The FSF says so. A limitation on Freedom 0 (to run the software)? They don't say, but I think so.
I also think you're right that software freedom doesn't depend on copyright. Copyright is merely a means to it, via copyleft. But if the law required freeing of software, that would restrict commercial freedom publicly in the same way AGPL does by private ordering. Unfortunately, that law would also have to require disclosure or publication of source code, and conformance on all the other fronts where AGPL fights: patent law and DRM, for example.
That's a far more expansive legislative program than abolishing copyright. Abolish copyright, and I can keep my code secret. And lock others' code down with patents. And so on. Many laws affect software freedom!
> I see no reason why your L0 ideas should not be discussed within the context of open source.
I agree.
In terms of open development as a production system, my point is largely here: https://blog.licensezero.com/2018/09/16/two-party.html#swing...
If making software in the open made sense to more people, we'd get more of it. Many of those projects might start as source-available, and end up copyleft or permissive open source. But instead of paving that path, we shame it as proprietary, and lump it in with Windows.
Open source orthodoxy is right about transaction costs and efficiency on the consumer side, but totally abdicates the supply side of software production. I've read on their mailing list that if you have to ask how you're going to make money making open source, you're the wrong person to be making open source, and that OSI doesn't owe any cycles on any business model.
> And the question is different for an academic talking about larger society, vs. an individual business or developer who is choosing his/her/its own license. Obviously your duty as an attorney is to grapple with the latter question.
I can't tell you how much it means to read that. Thank you for acknowledging. It gets lost.
* Heather Meeker (Fair Source, Commons Clause) * Tidelift (Luis Villa)
It's deeply disingenuous for this blog post to use the word "bullying" to describe the community's rejection of software distributed under undesirable or ill-considered terms. You can ship your code under whatever terms you want, but don't act like users and contributors have an obligation to support you when you make choices that don't serve their interests.
As for "bullying", that very adequately describes behavior on GitHub, Twitter, mailing lists, and news sites toward those behind React, Commons Clause projects, and Lerna. "Failure to support" is a straw man.
That really doesn't matter. All they know about open source is based on this definition. There millions of articles about open source on the internet that use it. You are trying to invalidate all of them for no good reason. As a consequence every opinion about open source they ever read prior to your efforts would be outdated. Most people understand danger of these actions which leads to behavior you described as "bullying".
The Open Source Definition says nothing about source control, patch submission, bug tracking, releases, versioning, dependencies, package repositories, continuous integration, test coverage, style guides, codes of conduct, and so on. There are also articles on the Internet that talk about a "post-Open Source" GitHub generation, and articles that affirmatively reject definitions of open source in terms of license conditions, rather than community. OSI has been controversial since inception, and there's plenty about that, too.
If the OSD were merely a descriptive framework, that would be one thing. "Here is a class of licenses we can describe, and here are benefits we can correlate with them." But OSD gets used far beyond that. It's used prescriptively. It's used to sanction. Those are social functions of a movement, and the crux of a movement is participation, not definition. It matters that people making open source haven't heard of OSD, because they neither participated in its adoption nor consented to its authority. It has no sway over them. The idea that a mailing list could define their community rankles.
I don't consider debate about OSD, DFSG, or "What is free software?" bullying. I do consider peer pressure on maintainers to adopt terms that don't advance their goals, against their stated interests, bullying. I consider unfounded legal FUD to the same effect bullying. Have a look at the Lerna GitHub issues, or Twitter conversation about Commons Clause.
There is nothing in your list that is different for open-source and proprietary software development. You could as well add countless articles about OOP and functional programming because they mention some open-source tools.
OSD is about answering three simple questions. Should I use some program or library? Should I contribute to its development? Should I release my new program or lib as open-source? OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff. He doesn't need to know OSD and read full texts of licenses as long as he uses most adopted like MTI, BSD, GPL. Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I can't sell some project based on Lerna to [list of companies] ? OK. How am I supposed to check that the company didn't change name? What if I am selling my work to subcontractor? I would probably have to include this list in every contract. What if every open-source project started banning some arbitrary list of companies? Am I supposed to review the last commit to license every time to make sure that my company wasn't included? All that looks, sounds and smells like a lot of headache and any reasonable person would drop the project with first sign of it.
Commons Clause was even worse. It was advertised as "MTI+CC", but nobody would be able to figure out what "CC" part meant for them without a lawyer. And any lawyer would advise to find something else.
That's not right, even assuming full "Innersource".
My point was that OSD is a set of criteria for licenses, plus a source-availability requirement. Those criteria don't predetermine all the practices that make up open source development right now. Those practices have changed! The OSD largely hasn't.
> OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff.
If you've managed to avoid all weird legal stuff so far, I'm glad for you. A good portion of my legal career is addressing weird legal stuff, which crops up even with MIT, BSD, and GPL, to use your list. The GPLs and other copyleft licenses are chock full of weird legal stuff.
> Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I wrote one of the more popular guides to MIT in layman's terms:
https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
I've also summarized the License Zero public licenses:
https://guide.licensezero.com/#public-licenses
The License Zero licenses are far easier to read, besides. That was part of the point of writing them from scratch.
> What if every open-source project started banning some arbitrary list of companies?
Highly unlikely. And that is not the approach of the License Zero licenses, React, Commons Clause, or most others that I mention.
If somehow this did become popular---again, very hypothetical---I'd go into npm and RubyGems and other package managers, and propose a package metadata field for excluded entities, and perhaps standardized categorical exclusions. This still sounds inconvenient, and I agree that it would be. But to give you a sense of near current practice, some large companies prohibit use of open source from specific competitors, even under permissive licenses, especially when the patent terms of the license are weak or nonexistent. That would include MIT, BSD, and GPLv2.
> And any lawyer would advise to find something else.
Or do a deal with Redis Labs. Which was the point, I think.
I would never put such a license in the same category as the MIT or Apache licence.
I wonder what happens when these peolle are given financial security?
As an investment in the future, the returns could be amazing! Many, if not all, authors really care and it shows.
Would making sure they are free to care, live well, maybe create more be such a bad thing?
Secondly, with that on the table, I wonder about the quality, and drive to create like that. We may see amazing tools.
Re: Open Source
Being able to see the source is high value. Being able to build on others work is high value.
Arguably, high enough value to trigger this kind of mess.
Pay them. Seriously.
Is the problem one of ego? AwesomeSauce.com wants to be recognized and get value from their work. Is recognizing CantLiveWithout DB or Language, Toolkit, etc... taking away from all that somehow?
Is it one of confusion?
AwesomeSauce.com paid, only to see AlsoAwesomeSauce.com not pay?
Does that matter, if bazillions are being made?
Seems to me this all can be litigated to our mutual detriment, or it can be handled as a family struggle, or worse.
Have to say, I do not blsme people looking hard at billion dollar enterprises, and their many big fix, support requests with a jaded eye, maybe a hungry one.
Fixing that scenario may well be ultra cheap compared to the mess and opportunity costs to come.
I put this here to stimulate some discussion, not as judgement, or anything aimed at anyone.
Really open licenses are a good thing. Really, really good thing. Many of us know the story. Pick up some code, any computer we can find and just build.
Breaking that seems extreme. Maybe it just does not need to be that way.
Maybe it should not.
What is worth what here?
Perhaps those conversations go far easier than the current ones will, and it is not like tech as a whole can't afford a solution.
Again, not a negative, or statement against anyone. Just thinking out loud here.
Still, opportunity costs on this are likely huge relative to settling financials on a merit basis.