Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Posted Oct 15, 2015 4:48 UTC (Thu) by wolftune (guest, #100179)In reply to: Permissive licenses, community, and copyleft by Cyberax
Parent article: Permissive licenses, community, and copyleft
> No, it cannot be. Even asking a contractor to work on your software counts as a "distribution", so in practice no sane company would try to do it.
That depends on the specifics. If a contractor works on the software on your premises or otherwise basically on your terms, that's still internal. The legal details here are complex, and I'm not qualified to go into super depth, and I suspect the same is true for you. I'm sure that it *does* in fact happen already that companies make internal modifications of GPL software that they use internally. It's barely any sort of risk because it's easy enough to keep things internal, and if you end up publishing it in some ways, the only ramifications are having to do so under the GPL. There's no risk of anything worse, so it's not a big deal.
> The article here is about taking existing projects and forking them as GPLv3 projects. It kinda presumes that the forked project won't cross-license new contributions, since its goal is to spread GPLv3.
Yes, but that doesn't preclude the idea of deciding later to contribute anyway or of the other project asking about it.
> And the point is, closed-source private code can (and eventually is!) merged into Apache 2 projects while GPLv3 can _never_ be merged back.
I don't share your blind faith that all code gets freed eventually as you seem to suggest. I think that's not true at all, it's a small minority of cases that end up that way. And my point remains: the copyright holders of GPLv3 forks have 100% identical ability to permit merging their changes back as do the copyright holders of proprietary forks.
Posted Oct 15, 2015 5:23 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
Large companies usually do have some customized GPL software, but the patches rarely are sensitive.
> Yes, but that doesn't preclude the idea of deciding later to contribute anyway or of the other project asking about it.
> I don't share your blind faith that all code gets freed eventually as you seem to suggest.
> I think that's not true at all, it's a small minority of cases that end up that way. And my point remains: the copyright holders of GPLv3 forks have 100% identical ability to permit merging their changes back as do the copyright holders of proprietary forks.
Posted Oct 15, 2015 17:28 UTC (Thu)
by qubes (guest, #2562)
[Link] (1 responses)
How can your own work be "tainted" when you control the copyright on all your own work (and can contribute it under every license you like?)
Posted Oct 15, 2015 17:55 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
Unfortunately, that isn't a given when you consider "derivative" works. The mere fact that you wrote the code yourself does not guarantee that you have sole control over the copyright.
The issue would be whether the code you wrote for the GPL project might be considered a derivative work of other code in the same project. If so, you might not be able to release it under a more permissive license, because that would amount to relicensing the code is was derived from, and not just the part you wrote.
The problem, as usual, is endemic to copyright: there is no clear, obvious guideline for what constitutes a derivative work, especially in the realm of software.
Posted Oct 15, 2015 22:16 UTC (Thu)
by ehiggs (subscriber, #90713)
[Link] (1 responses)
This is not true. There are swathes of extensions to Hadoop that don't provide sources and aren't merged upstream. Examples include Intel's Hadoop on Lustre, IBM's GPFS support, and OSU's Hadoop over RDMA. Outside of Hadoop, there's the whole freemium model based on BSD and Apache licenses. e.g. Continuum Analytics have open source and proprietary forks of projects like Numba. There are a lot of proprietary forks for Postgres which are valuable but will almost certainly never be merged.
Posted Oct 16, 2015 4:20 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
That'll also happen with Hadoop.
Posted Oct 16, 2015 11:57 UTC (Fri)
by robbe (guest, #16131)
[Link] (1 responses)
Posted Oct 16, 2015 17:55 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
For example, you give a contractor an email account in internal AGPL-based webmail and this contractor accesses it from home.
Whoops. AGPL has just kicked-in in force.
Permissive licenses, community, and copyleft
Yet this still counts as a "distribution" - I've asked our lawyers about it. And it's also the position of FSF.
Actually, it does. If you first contribute to a GPL-ed project and then switch back to Apache 2, then there's an argument that you might be "contaminated" and that your new Apache 2 contributions are tainted. Of course, it's highly unlikely that anybody is going to be sued for that (though you never know with FSF).
Yet it seems to be true. Proprietary Apache-forked code is either worthless or it gets eventually merged.
True but misleading. With closed-source software there is usually one owner, so relicensing is easy. With GPL you might have to get permission from hundreds of developers.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Not really. You linked http://www.gnu.org/licenses/gpl-faq.en.html#InternalDistr...
in another post, and it explicitly does not see the "contractor on your premises" case as distribution triggering the GPL.
Permissive licenses, community, and copyleft