edit: I'm well aware that some people don't want industry using their code. Great! But that's really limiting the scope of who's going to get involved, and it's probably going to make it harder to get a sufficient community involved to help your project achieve liftoff.
When I write software in my own free time, I purposely use the GPL, because I don't want BigCorp using my work without being a good neighbor and sharing their changes.
Why can't the corporations negotiate separate licensing deals?
Why do the corporations keep building the same tooling over and over instead?
If you hate working for such a corporation (and I know it may seem trite) but put your resume out there and try to find a better job.
Is software freedom doomed simply because we, the developers, can't negotiate sane licensing agreements and better jobs?
Is your current employer willing to contribute code to something like a foundation and assign copyright to them with the code licensed under AGPL?
If not, is your current employer willing to pay a certain amount to the aforementioned foundation get a proprietary perpetual, non-revocable, transferable blah blah license for a one time payment of... let's say $50k?
What I'm asking essentially is:
Is your company willing to help develop something like Ghostscript either by a. writing code for ghostscript to make it better or b. giving them money to make ghostscript better?
Even if both the answers are no, perhaps this module can act on its own and you can just never modify the source code. I believe as long as you don't modify the source code and just use binaries provided by upstream, all you'd have to do is to provide the binaries and the source files that you got from upstream.
I don't see why corporations have to be anti-GPL.
It would probably be immensely helpful if the GPL software developers who were open to alternate licensing schemes explicitly said so on their web pages. Otherwise the only licensing option listed for their software is GPL.
It's a minor point, granted, but I think it would make a difference.
EDIT: e.g., a statement like, This software is licensed to the public under GPLv3. If you would like to use this software under different licensing terms, please email us / review our price sheet / etc.
It very well could work both ways; some proprietary software developer would likely be willing to release their software as GPL if paid enough money, since, ostensibly, the proprietary license was chosen to help make money in the first place. I can imagine that some proprietary software developers choose proprietary licensing for some other reason, but I suspect it's mostly the default for anyone looking to charge for copies.
Your employer refuses to use an external tool. Their legal policy is simply incompatible with the licensing terms of the external product. Just as their purchasing policy would be incompatible with a $1B tool. So you're hired to make an internal version of an external tool.
Why not try to change your employer's policy? If they say they'd rather re-invent the wheel, aren't you just complaining about your job? Not external licensing choices?
I'm tired of doing the same shit over and over again.
Then why do you keep taking jobs to do exactly that?
You aren't. But you're not paying me enough to care about supporting you.
You find something I've been working on useful, and you want me to relicense it for you? I'm willing to sell you a copy under whatever license you want.
> forbidden... from using
The GPL doesn't apply when you are using Free Software, because the GPL is not an EULA.
The only time the GPL becomes relevant is when you want a licence to redistribute that software (or your derivative version). There are several options: you can choose to face the consequences of a copyright violation, you negotiate a specific licence with the authors of the software, or you can use the automatic licence granted by the GPL (provided you abide by the restrictions it imposes).
For someone in operations, if you're just using the software and not making your own changes, there is nothing stopping you from using Free Software tools anywhere you want. If you want to incorporate Free source code into your own tool, the GPL only increases your options, as you can still negotiate with the authors, just like you would have to if you wanted to include other proprietary code.
The only way the GPL could be seen as "punishing" anybody are the people that want to redistribute GPL code in their own product or tool without paying for it. If they don't like the price - recursively granting others the same freedom - then they are free to choose another vendor (or write their own version).
> forbidden by legal
Of course, if your legal department makes bad decisions because they do not understand the GPL, you may want to educate them (or refer them to the FSF)... or perhaps find a new legal department... or job.
Legal departments understand that using GPL code in proprietary services violates the "spirit" of the GPL, which is why they want to shy away from it.
It's especially thorny because if say, a contractor logs into the server that's running your SaaS, and your SaaS is linked against a GPL library, technically that's a distribution event (because the contractor works for another company, and now you distributed it to him), and now your SaaS has to be licensed under the GPL too. Oops.
When you consider all this, there's no wonder large companies just make blanket policies of no GPL, ever. And the GPLed works out there suffer, because those same large companies are happy to use permissively-licensed libraries, make fixes, and push those fixes upstream. But they can't do that with the GPL, because they don't want to touch it to begin with. It's ironically preventing the exact thing the GPL was meant to encourage.
Thankfully, the AGPL is working exactly as designed, because too many people want to try to fence off the commons. Again, if you don't want to pay the price for Free Software, find another vendor.
The rest of us don't have any problem at all understanding what a "distribution event" is. The AGPL is only a problem if you base your business on limiting other people's freedom. Stop doing that.
http://www.gnu.org/philosophy/who-does-that-server-really-se...
Are you defending AGPL and saying that proprietary SaaS software shouldn't use GPL code? Then I think you and I are 100% in agreement.
My post was in response to the grandparent who seemed to be saying that the GPL is A-OK to use in proprietary web services because it's only relevant "when you want a licence to redistribute that software (or your derivative version)". I was explaining that that's more of a loophole in the GPL than it is "not relevant".
I'm not basing a business on limiting others' freedom, I just want to write a dumb rails app for adding users to LDAP, or any other myriad of dumb reasons you'd want to make a dumb internal service. And I basically can't touch the GPL unless I can also convince our legal department to let me GPL the dumb tool and distribute the source code. Since things we distribute have a bit of brand identity to them, it would make my company look bad if the tool sucks, or it's not general-purpose enough to be useful outside my company, etc. So it's just not worth the hassle to go through all that for some dumb internal LDAP tool.
So instead I stick with MIT/apache/etc permissively-licensed libraries in my dumb internal tools, find bugs in those libraries, and submit fixes upstream. Ironically this is the exact same thing that GPL proponents say would never happen if everyone used permissive licenses.
I don't want to GPL my code and distribute it because I don't want anybody to see how bad it is, not because it's some "secret sauce" for my company. It's just a bunch of glue on existing libraries anyway (basically a variety of ruby gems.) The GPL is far too difficult for me to use in this case, so as a result I just don't touch it.
But I think people who choose either of those licenses are already releasing their code. It's just that the BSD has a wider contributor base, as businesses could be more likely to contribute back.
What I mean is, if the code is available then the quantity of people benefiting from it is separate from the idea of user freedom. User freedom, in the GPL sense, is freedom to read, copy, modify and redistribute the code and to do the same for anyone else's modifications to that code.
It's not about maximizing short run happiness, but ensuring that the user is in control. This is important in the long run.
> Is the role of FOSS developers merely to provide software that people in the "industry" can use to more rapidly develop their proprietary SaaS applications?
I don't understand why you're asking this question given the parent. The parent just said that BigCorp can't use GPL. This in no way means that the "role of FOSS developers" it to serve at the altar of industry. All it means is if you want people in industry to be able to use your code, then don't GPL it. There's nothing more to it.
It gets a bit more difficult of course where there are different contributors or the project itself relies on GPL code from elsewhere, which is not unlikely for large projects - it might not be possible (or at least practical) for the maintainer to even consider entering negotiations. This is by design how the GPL is intended to work. And again: this is no different to dealing with code from other commercial entities. If BigCorp doesn't like the choice that SomeOtherDeveloper has made license wise, they can of course take their interest elsewhere - nobody is forcing them to use GPL licensed code (as some people imply by use of terms like "viral").
Personally I prefer more permissive licenses when looking to use things in my own projects, especially in my day job where like you the GPL would generally be difficult to consider, but just like BigCorp this is my choice. It isn't something I would expect others to change their ways to accommodate.
Your bank can't open source it's banking system. Probably in a literal we-lost-the-source-code-in-1993 way.
Wait, what?
The Linux kernel is GPL and is used in countless proprietary applications.
Actually, you can make changes to GPL software without releasing those changes. The main restriction of the GPL is that if you distribute the software, you have to distribute the source too. But you have the freedom to do any changes and keep them to yourself without distributing anything.
> As I said, I am not only pro-copyleft, I am also pro-permissive licensing. The difference between these is tactics: the first tactic is towards guaranteeing user freedom, the second tactic is toward pushing adoption. I am generally pro-freedom, but sometimes pushing adoption is important, especially if you're pushing standards and the like.
Outside of that situation: because they might give back changes to your software, even if they don't free the rest of the code. Of course, this might be a good argument for the LGPL.
Maybe at some. I work at Google (in fact, i ran open source licensing :P). GPL is just fine for whatever. If you want to use it in server stuff, whatever. If you want to use it in client stuff, great, you ship source code to the right parts. As long as your product group/etc is willing to do what the license asks, we don't care.
I've met about ~130 of my counterparts at large corps. I'd say about 40% have policies like yours. The other 60% though, are closer to us.
Google et al want that loophole, so are ardently anti-AGPL
We aren't "ardently anti AGPL", we just don't use it or care. Certainly, I personally think it's a bad license for a bunch of reasons (related to my response, etc). But Google as whole simply doesn't publicly care one way or the other (IE isn't strongly AGPL). If you want to use it, great. We are fine not using it, and we tend not to contribute to AGPL software.
Certainly you realize that with the amount of AGPL source code being so small and not really growing at any real rate, Google simply doesn't have to care?
Why would we run around trying to stop the AGPL?
AGPL is very easy to control for the external facing stuff, but not the internal stuff.
For example, based on how it defines remote network interaction, it doesn't differentiate internal or external users. So if we used AGPL in internal systems that Temps, vendors, and contractors had access to, we'd end up owing all the temps, vendors, and contractors source code to the internal system, regardless of what other NDA's or anything else were in place (it's well settled that you can't contract around or NDA folks into giving up GPL/AGPL rights)
We aren't willing to take this risk (and i'd bet most companies that are doing it don't realize this is an issue :P)
But I can't use it internally if it's GPL, period. The GPL means that I have to GPL my (for example) internal SaaS if I use any GPL code in it. (Yeah yeah, SaaS isn't technically "distribution" of the software, and wouldn't technically trigger me to have to release my source code, but that's still violating the spirit of the GPL if not the letter, and lawyers hate that. And AGPL codifies that "loophole" by listing "as a service" as a distribution event.)
Whereas if the code was permissively licensed, I could actually use it internally in my SaaS, find bugs, fix them, make improvements, and pass the fixes upstream without someone getting pissy that I'm not releasing the code for the SaaS tool too.
GPL really stifles participation in a project if potential contributors can't even use your software because they can't GPL their own derived code.
So you're complaining that there's lovely software but bad corporate policies are a problem for your company. That's not a problem for the GPLed software.
The fact that you're technically allowed to use GPL code in a proprietary SaaS is a loophole, not something to be used in defense of the GPL. What you're basically saying is "GPL is great because you can get around it", which isn't really a case for the GPL but against it.
The legal departments in big corporations are aware of this, and they don't really like the idea of allowing loopholes in licenses to decide what software to use, so they discourage using the GPL.
If you're a software developer who's choosing an OSS license to use for their library, this is a huge factor. If you really do want companies to use your library even for proprietary SaaS applications (like in my example), choose a license that's explicitly ok with it, don't choose one that relies on a loophole to permit people to use it.
And if you don't want companies using your software in proprietary services, by all means use the GPL! That's great! But don't blame my legal department or corporate policies for me not using your library, it was your decision to choose the GPL, and I don't want to go against your decision.
"If the GPL software in question didn't exist you'd be in the same situation."
"So you're complaining that there's lovely software but bad corporate policies are a problem for your company. That's not a problem for the GPLed software."
I seriously do not understand how you got that from what I wrote.
It sounds like you were claiming that the problem isn't with the GPL but with my company having bad policies. So I attempted to defend my company's policies (as I explained in the post.)
The overall point is that I can't help contribute to GPL code because the GPL license prevents me from using it in the first place. (My company's policies are a red herring, they're merely there to make sure I use software properly.) I am theorizing that perhaps a developer may want my contributions, which is why they may want to consider that before they choose the GPL.
Edit: Ah, I think I understand now... when you said my company has bad policies you meant not open sourcing our SaaS is the bad policy, not don't use GPL as a policy. It's an entirely different conversation if that's the case, sorry I misread.
Whether this makes sense, or is a case of failure to understand the GPL, it does exist.
I think that's by far the most common use case for avoiding GPL though.
...so? The point is that the GPL makes it illegal to lock down, while MIT and the like enable it. Yes, some companies will play nice, but they are doing so voluntarily.
Sorry for the hyperbole, but the concern was very real, even if poorly defined.
I guess it's just easier to say 'GPL bad' than actually explain copyright to every developer.
And http://www.cnet.com/news/microsoft-embraces-gpl-opens-hyper-... from 2009 says "Microsoft embraces GPL, opens Hyper-V to Linux with LinuxIC: Redmond is proving that it can compete with open source on open source's terms by licensing LinuxIC under the GPLv2 license."
That said, the concern is indeed real, as http://www.zdnet.com/article/microsoft-admits-its-gpl-violat... from 2009 shows ("Microsoft admits its GPL violation; will reissue Windows 7 tool under open-source license").
Today, Microsoft ships even more cross-platform tools (Visual Studio Code) where again, it's required to use GPL tools, and we contribute to others. (I hack on GPL code as part of my job at Microsoft.)
Now, of course, you're right that this was much harder within Microsoft five years ago. And one's risk exposure is different depending on the product portfolio you own (with something like Windows being less risk averse than something like Microsoft Bob). But some very key lawyers with their heads screwed on straight have overhauled our system and it's much, much easier to deal with OSS than it was five years ago. But even then it was certainly _possible_ and actively happening in parts of the company.
The amount of FUD from rank-and-file employees was shocking though. Based on ignorance, but they just weren't part of the GPL world, and didn't care to understand it deeply. So I don't doubt that you may have asked someone and been told "Oh god, don't even look at that stuff". But it wasn't any kind of company wide policy.
I did end up talking to folks that were trying to make such a company wide policy, but even then what they were pushing for was some kind of GPL registry, where if you installed any open source software, you had to register it with the powers that be. I don't think that went anywhere though.
It's true, but it is 'open source', and many of my coworkers were not particularly discriminating among the different interpretations of OSS.
However, I have to imagine someone else tried or will try that same trick. It's why I strongly account for licenses of code added to any proprietary, code base. It's also why license management software is a real market rather than a concept. Better to avoid GPL source than try to explain to FOSS types in court later why it was accidentally distributed and you didn't really mean to exploit their work without following the license. Who would believe that given how most companies are about giving back?
I'm not really interested in arguing, except to point out that the kind of ignorance you're showing about how the GPL actually works has far more to do with "corporate acceptance" in "industry" than the actual details do.
Consider that perhaps I'm not an idiot.
Regardless of pedantry, a GPL OS does not raise the same kinds of issues for a typical corporation that a GPL library or application does.
Yes, it doesn't say "linking" exactly. It talks about "derivative works". Then, the FSF, separately, says that linking to a GPL library (or integrating into a GPL program) is a derivative work.
See:
https://en.wikipedia.org/wiki/GNU_General_Public_License (Check the "Linking and Derived Works" section)
Or, have a look at the LGPL, created specifically to address this problem. Note that the FSF isn't thrilled about the LGPL.
That's the big driver behind why a GPL OS doesn't create the kind of stir in a corporation that a GPL app or library does. Not saying it's right or wrong, just pointing out the difference.
(Now if you had said AGPL...)
There is an argument that companies should prefer the GPL for their own software that they open-source. It goes like this. If you are the copyright holder you own the software anyway and can change licenses at anytime so you are not bound by the GPL. However, your competitors (and future competitors) are. Therefore the GPL protects your company from someone else forking and closing the source for their improvements in the future.
Are you strictly talking about incorporating GPL code into proprietary products that you sell? That is a different thing, but thankfully there is a cross industry standard that you must pay the author in order to incorporate other peoples work into products of your own. If you add music, you got to pay the musician. If you have a photo in a commercial, you pay the photographer. BigCorp knows how to pay people for their work and why should it be any different in the software industry if BigCorp want to prevent others from using BigCorp products for free?
How do you folks get away without Linux (including Android)? It seems like you're in industry, but you're probably not in very successful industry if you don't have a mobile strategy that includes running on Android.
And if you do have an Android app, then you do GPL. You just do it without any sort of sensible policy around it. Again, not all industry is that stupid.
I hope you're open to LGPL though. I don't think there's much reason to avoid linking, and a number of free software libraries allow that via LGPL. I've always view that version of the license as a terrific compromise.
zlib etc: go nuts.
New BSD/MIT/Apache etc: sigh, fine, but you'll need to get it properly registered with legal so that don't forget to add it to that document nobody reads.
Old BSD: you're kidding me, right?
Stupid/joke license: come back when it has a real license.
LGPL: no.
GPL: hell no.
AGPL: aaargh! Get that off your machine RIGHT NOW! We can't even have that on the premises!
The reason for not allowing LGPL is that it's not well-enough defined what linking means, which means it's not worth the risk. The reason for not allowing AGPL is that if your company does anything via the internet, then if any software which is AGPLd gets anywhere near the serving stack, suddenly you're infected. (My current company would rather I didn't use AGPL software at home, even.)
The resolution is damages in both cases, not any kind of "infection" spreading.
If your lawyers think otherwise, they're idiots.
For some other people it means that here, I wrote it and you use it as you want to use it aka BSDL.
I am more likely to side with BSDL guys on this one, I do not want to do anything other than use a free software as free software if it is branded as free software. :)