Here's an attempt, although before I start, I don't hate the GPL at all. I think it's a clever hack, and a good license for some situations. Sometimes, as a practical matter, it is annoying:
Sometimes, you work on proprietary code (as to why this is, here's one thing I wrote a few years back: http://journal.dedasys.com/2007/02/03/in-thrall-to-scarcity/ but it's a long, involved discussion in and of itself!) and would like to integrate some small library that would make your life easier. If you can't use it, it's not really that big a deal, but if you can, great. Someone like myself, who greatly enjoys open source software will also be sure to be a 'good citizen', giving back any changes to that little library, even if we're not forced to.
But if it's GPL, you just can't use it. If this is the genuine intent of the author, fair is fair and you move on. Sometimes though, people just slap the GPL on stuff without particularly considering the consequences.
In some circumstances, BSD licensed code can attract more users, because they are able to use it in proprietary applications. If they 'get' open source, they'll still contribute back, causing the code to actually be more used and useful than if it were GPL and excluded from use by a company creating something it wants to make money with. (Ok, yes, you can make money with GPL stuff, but it's a lot more difficult than making money by simply selling something directly, and even that is not easy, as anyone who has tried to start a software business knows).
If you're not using a more modern license with an explicit patent grant you should at least have some agreement from contributors to make any of their own patents required for their contributions available to all other users of the software and its derivatives. Otherwise you may find that your permissive licensing isn't.
> If you or your employer own the rights to a patent and would like to contribute code to LLVM that relies on it, we require that the copyright owner sign an agreement that allows any other user of LLVM to freely use your patent.
And frequently they won't, leading to fragmentation. This happened a lot before the GPL became de rigeur.
> And frequently they won't, leading to fragmentation. This happened a lot before the GPL became de rigeur.
What time frame are we talking about? My experience was that the GPL probably was at its most popular in the late 90ies, but has gradually declined since then. Most things these days - Rails, Node, Android, Go off the top of my head - seem to have more permissive license.
People are a lot more connected now than even 20 years ago, so contributing back is also much easier. Also, more people get open source, at least for infrastructure type projects.
And Keith Packard frequently regretted X11 being under a permissive license, given how much company forked work the home project never saw code from.
It is easier to give back now, this does help.
Try now. Mac OS X is based off BSD and contributes little back (and what it contributes is patent-encumbered enough to be unusable). And that's only a high-profile example which is obvious: there are tons of examples we'll never hear about because we'll never see the code.
It's not that hard these days, particularly if you are a big company with plenty resources, Apple chose to fork Clang/LLVM so that they could keep their Swift implementation proprietary.
>Rails, Node, Android, Go
Haven't open source frameworks pretty much always been permissively licensed ?
My experience is that applications are typically GPL licensed, meanwhile frameworks and libraries are typically permissively licensed.
- Let people do whatever they want with it (BSD).
- Let people use it as a library, but force them to release changes to the library itself (LGPL).
- Let people use the software, but force them to release all modifications (GPL).
Neither is good or bad, but depends on the intention of the developer. Also, as a matter of etiquette, contributing changes back even for BSD code should be the norm, whenever there is no reason not to do so. But (L)GPL puts some enforcement power behind that rule of etiquette (and arguably created the norm).
Doesn't sound like a restriction to me.
It depends on the size of the contribution. If they only fix a small bug then there is no real reason not to contribute the fix.
The trouble comes when a company makes any kind of nontrivial improvement at all. In that case the proprietary version is significantly better than the BSD licensed version and any improvements made to the BSD licensed version can still be incorporated into the proprietary version but not vice versa, so the proprietary version will always be better and continue to gain users at the expense of the BSD licensed version.
Probably the most extreme example of this is iOS. Apple put a slick UI on BSD and now it runs on a billion zero-freedom devices while BSD is slowly dying. Compare this with Linux, which is much more popular in its own right and even more so if you include Android, which itself is much freer than iOS in no small part because the kernel is GPL'd.
The same thing can happen with any BSD licensed software. Anyone can do 25% of the work to create a proprietary version which is 25% better than the original and use it to cart off with most of the original's user base.
Ironically this is one of the things the BSD people complain about: Anyone can take software released under a GPL-compatible version of the BSD license, make some nontrivial improvements to it and release it under the GPL.
I'd actually use Sun and BSD as an example, but yeah, it is a possibility, which is why I am not some kind of anti-GPL zealot. I think it's less likely these days, because the effort required to really run away with a big project is considerable.
Is it? Obviously the proprietary version has to be enough better to make a difference, but it still actually happens. Look at Konquerer. KHTML was LGPL, so Apple and Google have to release their changes to the engine itself, but not GPL, so Safari and Chrome are proprietary and nobody has even heard of Konquerer.
You're making a baseless assertion. Apple ships an enormous amount of GPL software with OS X. It makes no sense for them to write an entire browser from scratch just to avoid the GPL when they're perfectly happy shipping bash, emacs, samba, etc.
Is it? The Android userland isn't GPL'd at all -- I think the last GPL bit left when they switched from BlueZ to BlueDroid. I don't see any evidence as to why the GPL code in the kernel compels Google to release the Android userland in the Apache license, rather than keeping it closed-source.
This is a very incorrect association to make, as the existence of iOS has very little effect on the relevance of BSD. (Besides, Netcraft confirmed *BSD was dying long before iOS came out. :)
Sure, from the perspective of 20-30 years ago, there were dozens of proprietary forks of BSD Unix (including NextStep), and BSD looked like a lousy choice for open source distribution.
However that doesn't acknowledge the profound change internet distribution has had on how developers consume open source code. There is now a massive ecosystem of BSD/MIT/Apache licensed code and very few evil corporations sucking it up and turning it proprietary. (Much of this 'framework' code which was always problematic under GPL.) So we should acknowledge that BSD-style licenses are successful in their own right, and not keep relying on outdated FUD about Microsoft or Apple "stealing" code twenty-five years ago, because it largely is no longer happening.
The license is a success in the sense that the code is being used, but it's failed to protect the project/brand from a situation where their code is being used worldwide without anybody realizing it.
(In fact the biggest misconception seem to be that Apple is using vanilla BSD or FreeBSD, when it's actually based on CMU Mach/BSD.)
> Darwin 1.4.1 is the UNIX-based, open-source foundation of Mac OS X. It is based on FreeBSD and Mach 3.0 technologies and provides protected memory and pre-emptive multitasking. This release corresponds to the release of Mac OS X 10.1. https://support.apple.com/kb/TA25634?locale=en_US
.
> The BSD portion of the OS X kernel is derived primarily from FreeBSD, a version of 4.4BSD that offers advanced networking, performance, security, and compatibility features. https://developer.apple.com/library/mac/documentation/Darwin...
I don't agree that 'the people that matter know' is necessarily accurate, I also don't think it's sufficient. FreeBSD depends on donations and people donate for a mix of reasons. For example you can successfully brag about donating to "Linux" because even in non-tech circles people know Linux is cool. But even in tech circles people don't know much about FreeBSD.
Not that donations as a from of conspicuous social responsibility makes sense from a rational point of view, but we're humans and there are many situations where we spend money just so people see us do it.
Keep in mind that both BSD Unix and CMU/Mach were funded by the government in order to advance the state of the domestic computer industry. In terms of successful government research projects, these two would have near top of the list!
That being said, it would be great if "FreeBSD" had a bigger brand (and perhaps wasn't seen as Apple's vassal.) But I think that has more to do with the fact that Linux effectively beat them to market versus any license logic.
Not that I care, as I don't have any issues with commercial code, but it is a good example of basing work on BSD licenses without giving it back.
Certainly Mac OS X has more relevance to the traditional BSD userbase than iOS, but that's because iOS preempted the existence of a mobile BSD userbase. Linux has not only Android but also a slew of smaller players like FirefoxOS and Tizen. BSD has nothing. It's hard to have less relevance than non-existence.
> (Besides, Netcraft confirmed * BSD was dying long before iOS came out. :)
Of course it was -- it has been under the BSD license the whole time and before Apple it was Sun et al as you note.
> However that doesn't acknowledge the profound change internet distribution has had on how developers consume open source code. There is now a massive ecosystem of BSD/MIT/Apache licensed code and very few evil corporations sucking it up and turning it proprietary.
That is almost a self-refuting statement. The primary reason to want a permissive license over the GPL is to use the code in proprietary software. In some cases that does result in the proprietary software dominating the open source equivalent in the market (as with OS X or Safari/Chrome), and the remaining cases (the framework code you mentioned) are the exact use case for the LGPL, which allows the framework to be used in proprietary software without allowing the framework itself to be supplanted by a proprietary fork.
It's completely ridiculous to claim there anything like a "mobile BSD userbase", and zero arguments beyond that were given. There's no real reason why Android or any other mobile OS couldn't be based on a BSD. Given the IP constraints of mobile phones, it probably would be a better choice than a bastardized Linux.
Oh, and "*BSD is dying" is a troll. HAND.
> The primary reason to want a permissive license over the GPL is to use the code in proprietary software.
The facts are that other than primordial forks of BSD Unix (e.g. iOS), 99% of the permissive ecosystem remains non-proprietary.
It's not like people are coding against "Ruby on Rails Professional" or "Angular.js Enterprise-Edition", all of this software is open and commoditized and free, and always will be.
> exact use case for the LGPL
I don't understand why BSD-style is much more popular than LGPL for 'frameworks'. Perhaps because it's because it's the "Lesser" GPL and the first link on the page is "Why you shouldn't use [this]".[1]
In the software industry, the FSF actually has a lot of moral authority. My guess is that if it doesn't look like they'll stand behind the LGPL, why bother?
To strictly play devil's advocate for a moment; why do developers think it is appropriate to benefit from the free/open source library, yet not provide that same benefit back to others (in the form of using it in the proprietary software)? To me, this was the exact type of situation in which the GPL was crafted to avoid, and part of why rms didn't just declare his software to be in the public domain. I'd also imagine rms' response to this complaint would be along the lines of, informing the developer in question to work on a free, non-proprietary version of the software, so they could in fact, use the library (totally disregarding the fact it is due to external pressures, such as the employer, that they're developing proprietary software in the first place).
This is, of course, assuming the original developer licensed the library under GPL on purpose and knowing the resulting implications, as you eluded to.
In the case I'm talking about, the developer uses the BSD licensed library and contributes back to it because they do not want to maintain a bunch of diffs and because they're a developer who gets open source.
Sure, the overall program is closed, but the existence or not of one small part of it was never going to fundamentally alter that.
Can we rely on a proprietary software vendor to push even minor fixes upstream? From the companies perspective, this is giving away the developers time to competitors for free, basically paying for every competitor to be an a level playing field with you. A companies responsibility is to appease shareholders by making money, not to make good software or help software ecosystems.
I'd say that most likely, yes, developers would like to push all their changes back upstream. Also I think that companies/managers not understanding of OSS would definitely NOT want to.
There are clearly people who pay Red Hat even though RHEL can be gotten for free from CentOS. Mostly what they're paying for isn't the software, clearly, because the software can be given away for free. What they're really buying is a lot of testing to make sure that, for instance, their enterprise copy of Oracle runs correctly, and someone to yell at if that enterprise copy of Oracle ISN'T running correctly.
Which swings round to what I think you were adressing in your essay -- most software is written by a programmer in exchange for compensation, paid for by people who want to use the software. This is even true, in roundabout ways, for most open source software. (I think it even holds true for Free Software.) Now, the most straightforward way to do this is to have the person who wants to use the software pay for the software. But the GPL makes this more difficult.
A lot of open source and Free Software gets written and paid for in spite of this. How? Because the money-maker is something else. As you say, "In one way or the other, to make money at something in the long run, you are going to have to find and sell a product that people cannot effortlessly get for free." The Linux kernel gets a lot of code paid for by Intel, because it's worth money to Intel to sell x86 processors that people run Linux on rather than buying a SPARC or Alpha or POWER chip (running some proprietary UNIX or Linux, to Intel there's little difference). Red Hat pays for a lot of development on Linux, both because Linux needs to be as good as or better competing *IX operating systems and Windows for its clients to buy it and because having people who write a lot of Linux code helps them when a customer comes to them and needs a custom patch for some part of the operating system. Google pays for open source development because it uses it to run services that it serves ads from and on.
And this has conspired to give the world a lot of software for free (and Free) where the developer still gets paid for their effort. But there are some problems:
1) Sometimes products can suffer from lack of attention until something goes NOTICEABLY wrong. I'm thinking of you, OpenSSL.
2) More broadly, this works better for some things than others. Low-level infrastructure? Plumbing that you can build a service on top of? This seems to work rather well in an open/Free model. As you get closer to user-facing stuff, especially user-facing stuff where your users are individuals and not enterprises, the model starts to work less well. (The notable exception here seems to be web browsers, which seem to be able to produce very good Free and open implementations for end users, so long as they're tied into a larger overall plan of selling those users laptops and smartphones or making money off the default search engine choice for the browser.)
3) There's perverse incentives when the people who use your software and the people who pay for your software aren't the same people. Some of these are actively malicious. Some of them are passive and harder to notice. Free to play mobile games are not open OR Free-as-in-libre, but they are an easy-to-understand example of the problem where your users and your customers are not the same people. In a more relevant example, Google, Facebook and Twitter are all examples of companies who use open software to build closed services, and then revenue is made off selling the users to advertisers. In those cases, there is a tension between doing what's best for the user and doing what's best for the client. Sometimes this is overstated, and I think the overstatement helps some brush off the concern -- you can't let the client win every time, because the client is paying for users and you need to cater to users enough to actually keep them around. But there are times when the tension between who uses your product and who pays for it causes you to make decisions that aren't in your users' best interests.
I think the GPL is useful. Hell, I think it's important. But I also think that there are some significant downsides to the GPL, that it's not a one-size-fits-all solution, that even open source isn't a one-side-fits-all solution, and that making Free versus open or Free versus proprietary into an ideological question has some very real harms associated with it.
1) http://www.theverge.com/2015/1/8/7514457/apple-app-store-rev... 2) http://variety.com/2015/digital/features/google-play-apple-i...
The ESA, which has an incentive to play up the importance of the video game industry, puts the total number of people (not just developers) employed "directly or indirectly" in the US by the video game industry at 146,000[1].
There are around 1.4 million people actually writing code professionally in the US[2][3], even if you limit yourself to the BLS's "computer programmer" and "software developer" categories.
[1] http://www.theesa.com/article/u-s-video-game-industrys-econo...
[2] http://www.bls.gov/ooh/computer-and-information-technology/c...
[3] http://www.bls.gov/ooh/computer-and-information-technology/s...
I'd estimate no more than 1/3rd of the ESA's estimate could possibly be developers[0]. I would certainly consider less than 50,000 out of 1.4 million to be "almost nobody" for the purposes of this conversation.
[0] And I think that's a very, very high estimate, it's probably closer to 1/5th, or even lower. There are a lot of art, QA, and support people involved in the industry, before you even make it to usual corporate overhead of management, HR, payroll, etc..
But that's really a definitional argument, and those are dull. The larger point is that plenty of people still sell software to other people.
When we explain to the employer that it is illegal to distribute the improved version except as free software, the employer usually decides to release it as free software rather than throw it away.
Our hapless employer wrote some amazing software, but then found out that they had to give it away! Hah, joke's on them!
A hobby is not a substitute for a job.
I would never characterize copyleft software as "bad:" the author has donated time and energy, and I am grateful. But it is less useful than it could have been. If you're going to write some software and give it away, man, just give it away!
It takes away people's ability to say "what's mine is mine, and what's yours is mine." That's enough reason for those who care about freedom for themselves, but aren't really all that interested in freedom for others.
These people were deeply upset when the GPL consistently won every time it went to court.
I believe that there are many benefits from GPL, and the entire idea of Free software. I don't really feel compelled by the idea that all the bits I write should be that way, or that I should restrict the bits I use to Free ones -- partly because I really like good graphics card drivers in linux. (I realize it's selfish, but it also feels pragmatic.)
I am profoundly grateful for RMS' insight and creations, even though I don't always agree with his opinions.
The problem is that these corporations feel that providing insight to their competitors on how they're doing things is a bigger issue, and they keep them closed.
Anyway, I read "Free Software, Free Society," a collection of essays by Richard Stallman, and it completely changed my mind on the matter. (The book is available free in PDF form from GNU.)
We all build on the work of others' before us, and limiting those who come after, taking away the freedom of the end user and future developers who play by the same rules, is shitty.
This is the simple premise of the GPL: if those who develop proprietary software won't let end users and other developers benefit from their code, we don't let them benefit from our Free code. GPL is all about protecting the end user's freedom to use and modify the software.
Suppose the government sponsors a numerical software library. If that library is GPL licensed, that means that proprietary software like Matlab, cannot use it. Is this a good thing? If we think that there should be strong encouragement for all software to become open source, maybe yes. But I believe there is no reason to want most software to be open source. So releasing things like this under the GPL just means that less people can use it than otherwise, and so the effort has been less efficient.
I would choose a permissive license for everything except operating systems (which I think should be open source, for security reasons), and end user products (like emacs), which need to have the community protected from proprietary forks. Libraries should mostly be licensed with permissive licenses, because that maximizes the number of people who can use it.
Eventually the only version containing the desired numerical algorithms with better performance will the be commercial version.
That's the part I don't agree with. I like actually free software.
Also if you speak about "a piece of software" as in one piece of software, then the GPL doesn't maximize the freedoms.
What the GPL does, is set a few (people from the BSD crowd would say restricted) freedoms and try to spread them as far as possible by making people license their own source code they wrote under GPL if they want to work with a GPL licensed codebase.
Not entirely true. You are only subject to GPL if you distribute the code you modify. If you keep it inside your company, or for yourself, or you run it on your servers, there nothing GPL will do to you.
If I give my modified-GPL code to my coworker bob is that distribution?
If I upload to an EC2, is that distribution?
http://www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePos...
Put another way, if you take your GPLed code, burn it into a cd and mail it to yourself through DHL or Fedex, you are not "distributing" the code to Fedex.
It might not be distribution, but the GPLv3 terms are mostly triggered by "conveying", and it is clearly "conveying" as defined in the GPLv3.
> You are not giving your program to Amazon to use
The GPLv3 definition of conveying keys on whether you enable another party to "make or receive copies" of the work, not whether it is for that other party's use. Even if the copies are for your use, if you enable another party to make or receive copies, you are conveying, and are covered by the GPLv3 provisions applicable to the form (verbatim, modified source, or non-source) you are conveying the copy in.
> Put another way, if you take your GPLed code, burn it into a cd and mail it to yourself through DHL or Fedex, you are not "distributing" the code to Fedex.
Mailing your GPLed code through DHL or FedEx does transfers physical media through their hands, it does not enable or require them to make or receive copies of the code. So, true, it is not conveying, and it is also unlike uploading to a third party, which always enables that third party to make or receive copies.
By the plain language of the GPLv3, that would seem to be conveying as well. I agree that that is an undesirable thing in a Free/Open license, and quite possibly not the drafters' intent (but the drafters' intent matters little, especially for GPLv3 licensed software where the FSF isn't the licensor.)
The copy is not Amazon's, Dropbox's, or Google's, it is yours. It never legally left your control.
What you are missing is that the uploading to those services absolutely is a "kind of propagation that enables other parties to make or receive copies." [0] You are, in fact, sending the work to Amazon, Dropbox, or Google, and you are explicitly representing to them that you have, and are exercising, the right to give them permission to make copies of it (and, for some of those services, also to allow third parties to do so.) [1]
> You are no more propagating (another important term defined in GPLv3, which conveying is defined in terms of) a work to those companies than you would be if you put a copy of the work in a storage locker, apartment, rented office space, or even a rented car.
Propagating work is defined as "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." [0]
Copyright law (at least, in the US) does not make it an infringement to store physical objects containing a copy of the work in space controlled by a third party without permission of the copyright holder. It does, however, make making a copy (including, e.g., by uploading) without such permission, generally, an infringement [2]
So, no, from a legal perspective, the analogy you draw is not valid.
[0] GPLv3, Sec. 0
[1] Consider, e.g., the Dropbox terms of service [3], under "Your Stuff and Permissions": When you use our Services, you provide us with things like your files, content, email messages, contacts and so on ("Your Stuff"). [...] We need your permission to do things like hosting Your Stuff, backing it up, and sharing it when you ask us to. [...] You give us permission to do those things, and this permission extends to trusted third parties we work with.
[2] See 17 USC Sec. 106
But you forgot to keep reading GPLv3.
2. Basic Permissions.
[...]
You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
You might still argue about dropbox, since it's neither modifying nor running the works, but certainly using the work on EC2 falls under this provision.
Are you talking about search warrants? I think any interpretation that makes one liable for copyright infringement for the government forcibly making a copy is likely to be laughed out of court.
> a service of the general type of Drive/Dropbox is still problematic
There is an exceedingly easy workaround if it is a problem: Encrypt it. That way you do not "enable" them to make copies (in any sense a court would care about).
If it is yours (and not your common employers, which then brings into some question as you being agents of the same actor) it would seem to be "conveying", which is the more relevant term under the GPLv3 (see below).
> If I upload to an EC2, is that distribution?
More relevant is probably that it is "conveying" as defined by the GPLv3:
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.
(Uploading to EC2 enables -- requires, in fact, for normal operation -- Amazon to make or receive at least one copy of the software.)
Sure you can. If you release a animal to run freely in the wild, I can take away its freedom by shooting it. The only way to maintain its freedom is by also restricting my and others freedom to hunt it down. The way we describe this is liberty, ie everyone can live in freedom under common restrictions; restrictions which purpose is to maintain the freedom of everyone.
And that's the crux there. It's not always malicious (I want to make a proprietary extension and sell it), sometimes it's a fact of the environment (I have to link this against a proprietary library in order to deploy to this hardware). Some will say "find a new environment that isn't developer-hostile", and others will say "find code that doesn't impose those restrictions." It's not black-and-white.
I have the greatest respect for RMS and the FSF. I compromise on my freedom as a developer all the time; I know that. But thanks to the ideals that RMS puts forth, I know that I'm compromising. I know what the risks are to using BSD instead of GPL, and so I weigh those risks.
You say its not malicious, but then I see the misery and harm proprietary copyright licenses do. People use it to sue 7-year old girls, send people to jail for years, and put others into debt for millions, all for the simple act of someone helping an other fellow human.
We could make a copyright license which only condition is that you can not sue someone, or that you can only sue companies and not people, or some other from of harm reduction. I doubt companies would prefer it, as without the threat and punishment from copyright lawsuits many argue that you can not earn money on making software. They argue that you must have the malicious aspects, or its not free enough to be useful.
Abuse of a tool is not an argument against the non-abusive uses of a tool. I was going to say more here, but this really distills everything down.
People are going to find a way to be bastards to each other, and the FSF pipe dream of everything being Free does not change that.
Repeated and egregious abuse of a tool - the thing being discussed in the comment you are replying to - is in fact an argument against the tool.
Can you give an example how such threat can be non-abusive?
Considering that copyright applies to your work automatically unless you take positive action otherwise, it is no such thing. Someone's work belongs to them, under whatever terms they wish, until they wish to modify those terms.
Works that do not have a license is normally refereed as orphan works. While you could call it proprietary, it is by definition not proprietary licensed.
No, that's just a copyrighted work with no published license (e.g., most dead tree books), for which you must contact the copyright holder if you want any kind of license.
An orphan work is a copyrighted work for which the rightsholders are unknown are uncontactable, and which it is therefore impossible to even attempt to negotiate a license.
Technically possible, unlikely in practice, and I doubt anyone could find a proprietary product being sold in a store that does not have a license. For all practical purposes, where would you find proprietary work used in a proprietary setting but without a proprietary license?
As an example, there are any number of projects on github without any explicit license. That does not make them orphaned, nor make them freely available for use. We've come across a couple that we wanted to use and our first step was to work with the authors to get them licensed under some clear terms.
Just because it's "hard to contact the copyright holder" doesn't make it legal (or in my opinion, moral) to take their work and use it however you judge best.
A project on github without a license is not proprietary licensed, but they are copyrighted. If such work ends up in the hand of someone which is not the author, then one would have to ask under what permission (license) that happened.
The content of a project on Github that is publicly viewable arguably also is minimally licensed as required by the Github terms of service, to wit, the Github project owner "agrees to allow others to view and fork" the project repository (see Github Terms of Service [0], F.3).
[0] https://help.github.com/articles/github-terms-of-service/
Karunamon said no such thing (at least that I could find). I believe you're disagreeing with something they never said.
For an example of a copyright protected work that is usually distributed with a copyright notice but no license, consider most hardcopy books.
It's clear from the conduct of the parties to the transaction that a limited license for reading is intended, and the parties just never bothered to make an explicit license to memorialize that agreement.
One might be able to craft a colorable argument that an implied license to some right that is exclusive under copyright is created in the usual sale of a hardcopy book -- but you certainly haven't yet done so.
> It's clear from the conduct of the parties to the transaction that a limited license for reading is intended,
"Reading" isn't -- in the US, at any rate -- an exclusive right under copyright [0], so no license is necessary.
[0] See 17 USC Sec. 106: https://www.law.cornell.edu/uscode/text/17/106
No, its not.
A proprietary copyright license is a explicit statement of intent, sure, just as a free software license is -- but any license, proprietary or free, is an explicit statement of intent not to prevent certain uses. It may also be an implicit statement of intent to take action, including lawsuits, against those who make use not permitted by the license to the extent that is within the licensors right -- and, again, this is just as true of free software licenses as proprietary licenses.
Every company in the world will get around this.
"We could make a copyright license which only condition is that you can not sue someone"
So what would you do in the case of a copyright violation? If you can't sue to enforce the license, what's to stop anyone from violating it? And that includes the GPL and its provision on opening the source of things using it.
" They argue that you must have the malicious aspects, or its not free enough to be useful."
There needs to be some way of enforcing the contract. And that's how contracts are usually enforced: In the court system.
It would of course not provide the benefits of GPL which has requirements on distributors to provide source code. It would be a completely different license, and if I made it, likely based on MIT just so it would be the least company friendly permissive license ever. I only bring it up as an example of a license requirement whose intent would align with many who uses GPL in order to prevent copyright abuse.
Contrubutions would be quite messy however.
* (1st-order capitalists) People who want to make a buck
* (2nd-order capitalists) People who don't mind if 1st-order capitalists use their work
* (3rd-order capitalists) People who don't mind if 2nd-order capitalists use their work
* (Etc., nth-order capitalists for all n)
That makes me an ωth-order capitalist. Unfortunately, GPL is anti-ωth-order capitalist (Proof: Induction). I can't ever use it unless I'm willing to kick people under the bus who I'd rather allow to use my code.
1. Take the GPL project you want
2. Add a comment somewhere, publish the resulting derivative under MIT
3. Use it however you want, while flipping off Gnu
Sure, I can (and do) use GPL software, personally. But I can't use GPL sourcecode in projects I publicly release. If I did, that part of my sourcecode would have to be GPLed.
* Which means it couldn't be used by anyone (set A) who can't use GPL.
* Which means it couldn't be used by anyone (set B) who wants to share with people in set A.
* Which means it couldn't be used by anyone (set C) who wants to share with people in set B.
* So on forever.
He never said that, he said you can you can combine your permissively licensed code with GPL licensed code and _your_ code will still be available as permissive.
You stated that you wanted to share _your_ code with 'everyone', nothing prevents you from doing that.
Someone else's GPL licensed code is NOT _your_ code just because you decide to use it.
Who exactly are you kicking under the bus? The developers, or the end users?
The GPL optimizes for end-users, "kicking developers under the bus", and the BSD/MIT licenses optimize for developers and "kick the users under the bus".
Which group do you optimize for? Arguably, if you want "maximum freedom" in the world, you'd optimize for the end users, since there are going to be more of them than the developers.
Not to mention the developers are 1) normally end users and 2) couldn't be developers of said software if you didn't release your software the way you did.
Freedom is a loaded word, and I think most people don't share the FSF's definition of freedom. I would rephrase your statement as "the GPL is designed to globally maximise the ability to use, modify and distribute a piece of software. The only ability the GPL does not provide is the ability to take these abilities from future uses."
I personally think that this ability to modify software (and scrutinize its source code) is very important when it comes to the operating system. For javascript code sandboxed in the browser, it is much less important (sure, javascript can still do unexpected things, like tracking users, but this is still much much less than what could be done with full user level access, and these are things that can be fixed). So I support GPL for operating systems, encourage open source for other software, but don't object to closed source when the danger is low.
"the GPL is designed to globally maximise the ability to
use, modify and distribute a piece of software. The only
ability the GPL does not provide is the ability to take
these abilities from future uses."
The part about forcing published forks to release their source code is a consequence of that purpose: hiding the source would reduce the amount of knowledge, and thus it is forbidden.