Since when should the GPL protect companies?
I always thought of FSF and GPL as way to protect consumer rights and interests.
I always thought of FSF and GPL as way to protect consumer rights and interests.
A lot of companies are very open source friendly these days and consequently are happy to open source parts of their software stack. Using a BSD type license makes this very easy. GPL however, forces companies to open source the whole software stack and that is very often not possible for companies, be it that they need to make money by selling the software, or that some code parts contain trade secrets or that they do have some code parts licensed themselves.
This explain why developers tent to prefer BSD/MIT licences, they can use code without restriction and restrict their users to access it. It's just that GPL focus on protecting users, not developers.
• No copyleft for libraries that implement proprietary standards competing with open standards, to further adoption of the implemented standard among proprietary software developers.
• Weak copyleft for libraries that implement the same features as existing proprietary software, to further adoption of the library among proprietary software developers.
• Strong copyleft for libraries that “do not face entrenched noncopylefted or nonfree competition”.
https://www.gnu.org/licenses/license-recommendations.en.html
Shouldn't that be the other way around?
That is wrong. As a developer you can of course refuse to use any software distributed under the GPL.
Of course, as a consequence many developers refuse to use any software distributed under the GPL (as in using GPLed code in their software). I am not sure how this is a good thing.
Your last wish of "start making their own transistors" is really funny in the context, that some of my proprietary code is actually for making transistors.
Trickle down freedom.
You can open-source any part of your stack under the GPL, just make sure that you get copyright from any open source contributers. Since you own the code, you don't have to adhere to the GPL (similarly the GPL doesn't prevent you to license the code to someone else at different terms).
The real problem is that most people won't use your shiny GPL project, because they can't properly integrate it in their stack without potetially having to open-source it.
"I think GPLv4 should focus on protecting and encouraging companies to contribute"
"It simply shocks the conscience. Companies are people"
"Allow for walled gardens to have an open space"
Also, please note it is from 2014, so there's no need to dignify it with a response.
You would be surprised. There are many developers who rail against the GPL for restricting their ability to turn free software proprietary, and who subsequently call BSD-style licenses "more free", because those allow them to do more things.
That is a misunderstanding of what the FSF is about, but it is a fairly common misunderstanding.
In other words, the code would still be developed in the open, no individual rights would be taken away, you'd just be making it easier for companies to assist with the growth of GPL software. I don't see any major problems with that.
Currently instead of just releasing their software under a GPLv2 or GPLv3 compliant license, thus giving customers the right to change and adjust it however they like, they choose to withhold those rights and put the software under a proprietary license. A company that does this is clearly not interested in empowering their customers and should not be of any consideration when discussing an ideal customer rights issue like the GPL.
IMO GPL is not there to be liked by companies, just like the green party is not liked by industrialists. GPL assigns legal obligations to companies and rights to customers. I fear that if GPLv4 is designed to be more likable to companies, rights for the consumer will suffer.
No, it goes beyond that.
I've heard stories where IT departments have blocked GPL software from being used (as end users, not as an integral part of a software product) due to it being unclear where the GPL starts and ends.
The article gives an example of a legal clarity issue in the 'dynamically linked' section:
"Most of what is in GPLv3 are important, clear improvements. However, they’re clouded and subsumed by one big unknown – the dynamic link.
Apple, for example, was forced to stop contributing to the open-source project Samba, and instead had to build its own SMB file server, based on the final GPLv2 code release of Samba. Now, Samba is deprived of code contributions that Apple would otherwise have been happy to share. Why? Because Apple is afraid that someone might argue that Samba is “dynamically linked” to OS X, and in turn (per rules of GPLv3), force Apple to share the entire source code of OS X.
This is stupid. But some argue even typing a file name into a terminal window constitutes a dynamic link. Others argue you must use some shared library, where code natively interacts in an intended manner, such as a dylib or .dll file to create this scenario.
Vagaries of this degree should not be in the GPL. It should be scrapped, or at least, replaced with clear and concise definitions that most industry experts in engineering (and product management) can explain in human terms."
I have searched for a few minutes and did not find anything.
http://appleinsider.com/articles/11/03/23/inside_mac_os_x_10...
The GPLv3 applies to the Program as the GPL defines it. It has a provision, in Section 5, for aggregate works of many programs and is mentioned in the FAQ [1].
> But some argue even typing a file name into a terminal window constitutes a dynamic link.
Who? The FSF holds the opposite. A terminal emulator and a program that runs within it are two separate programs.
[1] https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
> "Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide."
The types of links should be crystal clear from the licence, rather than relying on judges to determine fair use. Companies are likely to avoid the GPL due to the potential risk derived from this lack of clarity.
A terminal emulator and a child process will have different virtual address spaces, so you may choose that as the discriminating factor. A web browser and a web application will share address space. But a web browser and a web application are clearly two separate programs as well.
It isn't really a problem unique to the GPL. Any interpretation of a non-trivial license with conditions will have an element of "I know it when I see it". Software licenses especially due to the level of abstraction.
Those running those IT department have thus demonstrated their incompetence. The first freedom granted by all free software licenses, including the GPL (any version) is the freedom to run your programs for any purpose. As long as you don't distribute the GPL license code you're using, you're not obligated to anything.
For instance, one is perfectly allowed to use GCC for the purpose of compiling proprietary software and distributing the resulting binaries. Because by doing so, you only only run GCC —you don't distribute it.
HPE now has a "default to GPLv3" policy for new code that they write.
Interesting, I hadn't heard that. When did they institute that policy? Good on them.