Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Posted Oct 15, 2015 1:27 UTC (Thu) by wolftune (guest, #100179)In reply to: Permissive licenses, community, and copyleft by Cyberax
Parent article: Permissive licenses, community, and copyleft
The earlier poster wasn't talking about internal projects, they were talking about proprietary *published* software. Incidentally, GPL software be used for internal projects too without triggering the requirements for source release. The copyleft requirements only take effect if the software is distributed to outside parties.
> GPL code can not __ever__ be merged back into Apache2/BSD projects (without requiring upfront copyright assignments or dual licensing).
*or* it can be merged back by simply at the time of merging ask the copyright holder to release the relevant code under the permissive license. And obviously the project itself could move entirely to GPL without asking anyone for permission and then merge the other GPL code…
For the record, I *do* think that respecting the existing license of an existing community is a legitimate concern. The choice to stick to copyleft is certainly easier when starting new projects than when forking. But the balance of what makes sense varies case-by-case.
> Because AGPL is so horrible…
…for business models that rely on controlling users and making them dependent. AGPL is the best we have for protecting user freedoms and building a commons that everyone, businesses included, can all contribute to and use on equal terms. If you're a protectionist sort of business that aims to achieve monopoly status in some ways, then the AGPL is indeed horrible for you. So, it's a matter of perspective.
Posted Oct 15, 2015 1:57 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (28 responses)
> Incidentally, GPL software be used for internal projects too without triggering the requirements for source release.
> *or* it can be merged back by simply at the time of merging ask the copyright holder to release the relevant code under the permissive license. And obviously the project itself could move entirely to GPL without asking anyone for permission and then merge the other GPL code…
And the point is, closed-source private code can (and eventually is!) merged into Apache 2 projects while GPLv3 can _never_ be merged back.
> …for business models that rely on controlling users and making them dependent. AGPL is the best we have for protecting user freedoms and building a commons that everyone, businesses included, can all contribute to and use on equal terms.
Posted Oct 15, 2015 4:48 UTC (Thu)
by wolftune (guest, #100179)
[Link] (7 responses)
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.
Posted Oct 15, 2015 4:53 UTC (Thu)
by wolftune (guest, #100179)
[Link] (11 responses)
The only *danger* you are facing, the *only* issue for your safety is releasing your source code — something many people argue should be done for *published* software anyway, and you yourself were even suggesting was inevitable… so, are you saying that it's horribly unsafe to risk the possibility of having to do something that was inevitable anyway??
Posted Oct 15, 2015 5:00 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
It's entirely possible for AGPL to cascade down to pretty much everything. That's why it's so toxic that pretty much no enterprise company deploys it.
Posted Oct 15, 2015 14:49 UTC (Thu)
by k3ninho (subscriber, #50375)
[Link] (6 responses)
>>> The only *danger* you are facing, the *only* issue for your safety is releasing your source code
Hard-coding implementation detail is technically ugly. I'll go so far as to say that your skilled minions are doing it wrong (what's your company called so I can blacklist? :-P lol).
AGPL says that you have to give people the ability to run their own version of the service you're running. Either that's available from your source upstream or you have contributed value to the system and you owe it to upstream to make that available. Your passwords, internal system layout and firewall rules aren't part of anyone else's service within an AGPL ecosystem -- and obviously you would pay your legal team to argue that fact against the charge you were failing to meet your obligations under the the AGPL -- so this line about it being 'toxic' is steaming shenanigans.
Either you're part of the community and ecosystem around GPL and/or AGPL projects or you're not. There are differing requirements for your org with each, but your reasons for reimplementing work other people have done rather than integrating existing solved-problem tools aren't technical or legal, they're cultural and habitual and you can elect to change that.
K3n.
Posted Oct 15, 2015 18:20 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Back in the late oughts a company I worked for wanted to use some AGPL'd software internally (gitorious?), and of course they wanted it to use the corporate single sign-on (F5 maybe?). No problem, a few days effort max. Then came weeks of email with expensive lawyers, and the eventual conclusion that it's probably impossible without AGPLing the entire SSO product. We thought of a number of workarounds (as I'm sure you can) but the language in the license is pretty flimsy... It seems like armchair lawyers have no problem staking their reputations on the AGPL, but reputable ones, who are fine with GPLv2, are just not happy to go there.
So, yes, I came out of that experience feeling like the AGPL is pretty darned toxic. I'd be curious to hear if anyone else has successfully navigated these waters.
Posted Oct 15, 2015 19:59 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
That what people say it says, but not what it says!
Read the actual license text. What you say is not something a copyright license can enforce because running the software is not a reserved right of the copyright holder.
The AGPL is very vague on crucial points, in particular the meaning of 'modifying the software' and
'all users'.
It it the only purportedly free software license that create liability for merely modifying the software,
even if you do not run it.
"modify" is defined in the beginning as
which is still quite ambiguous.
Your best defense to the AGPL is to refuse to accept the license which is explicitly allowed,
pay a third party that will never run it on a public network to do any modification to it,
and then run it behind a transparent proxy that remove any offer of source from the HTML pages
that are served, to cover the third party.
Trust me I am as concerned as anybody about the software as service hijack of the GPL, but the AGPL is
not the solution, it just distracts us from searching for a working solution.
If you are concerned, only write GPL client-side javascript. This way anybody interacting with your code has already received a copy!
Posted Oct 15, 2015 21:41 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
Haha, maybe... Even then, no way you're going to get any reputable lawyer to sign off on that!
Posted Oct 15, 2015 20:09 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 15, 2015 20:58 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yet it's the reality we have to deal with right now.
Posted Oct 16, 2015 0:37 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
As if this stops people doing boneheaded things. In the last place I worked, I gave up trying to persuade people that embedding the credentials required to access our internal Maven repository into our source code repositories was a bad idea, because I also had real work to do! :(
Posted Oct 16, 2015 7:56 UTC (Fri)
by arnout (subscriber, #94240)
[Link] (1 responses)
I never really understood the issue with this. So you have to release the source code of your internal build and deployment system to your employers. Wouldn't it be a good idea to give them access to it anyway?
What I also don't understand is how lawyers are so paranoid about copyleft licenses, but there never seems to be a problem with binary firmware blobs that don't even have an accompanying license text.
Posted Oct 16, 2015 17:58 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And the company will have no legal recourse, other than simply firing employees who give this source to anyone outside the company.
> What I also don't understand is how lawyers are so paranoid about copyleft licenses, but there never seems to be a problem with binary firmware blobs that don't even have an accompanying license text.
Posted Oct 15, 2015 15:10 UTC (Thu)
by krake (guest, #55996)
[Link]
He says that internal code is either published or worthless, so having to always publish would be unsafe because then all that worthless code would be out there as well.
Posted Oct 15, 2015 14:14 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (3 responses)
> 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.
Is that the opinion of a copyright holder, backed up by the finding of a court, or just the 'worst case' opinion of your own lawyers?
Posted Oct 15, 2015 20:05 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Our lawyers said that there are precedents where transfer of music records between two different business units within one company was deemed to be a "distribution".
Posted Oct 16, 2015 0:35 UTC (Fri)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Oct 16, 2015 4:08 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 15, 2015 15:07 UTC (Thu)
by krake (guest, #55996)
[Link]
That's definitely not true.
Posted Oct 17, 2015 0:45 UTC (Sat)
by rahvin (guest, #16953)
[Link] (1 responses)
Posted Oct 17, 2015 4:33 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
The quality of these projects is a huge barrier of entry for proprietary forks. Why would you pay $10000 per license for a "Hadoop With A Big Red Button" unless it can also brew coffee and transmute lead into gold?
This causes companies to contribute small changes to the core, instead of just hoarding patches. It adds up to a surprising amount of contributions. As an example, look at a PostgreSQL commitfest: https://commitfest.postgresql.org/4/ - lots of different companies with small patches.
For vendors that successfully vaulted over the entry barrier and have a compelling proprietary fork there are other incentives to contribute. It's quite likely that such products use some kind of a plugin interface to extend the core functionality, so vendors are interested in making sure that the core works well for them. As a result, quite a lot of LLVM or PostgreSQL developers are employed by companies that make proprietary extensions. Personally, I consider this a very healthy situation.
And as history shows, if there's a competition then eventually some company is going to decide to open source their product and switch to "service" model to outcompete other forks (see: Hadoop, Hortonworks).
Posted Oct 19, 2015 21:02 UTC (Mon)
by vomlehn (guest, #45588)
[Link]
Reality check: I might mention that, even though IANAL, I spent a good deal of time on the Cisco Open Source Review Board, a company that has learned to care deeply, from a practical viewpoint, about what you can and cannot do with open source.
Posted Oct 15, 2015 15:05 UTC (Thu)
by krake (guest, #55996)
[Link] (11 responses)
That is of course also true for any code in a proprietary fork.
Posted Oct 15, 2015 18:26 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (10 responses)
Posted Oct 15, 2015 19:19 UTC (Thu)
by emunson (subscriber, #44357)
[Link] (5 responses)
Posted Oct 15, 2015 20:04 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (4 responses)
Posted Oct 16, 2015 14:41 UTC (Fri)
by emunson (subscriber, #44357)
[Link] (3 responses)
Posted Oct 16, 2015 15:03 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Posted Oct 16, 2015 16:41 UTC (Fri)
by bronson (subscriber, #4806)
[Link]
Speaking as one who's happily assigned my copyrights to the FSF in the past.
Posted Oct 19, 2015 21:49 UTC (Mon)
by rfontana (subscriber, #52677)
[Link]
If someone from the FSF is reading, maybe they can clarify.
Posted Oct 16, 2015 7:02 UTC (Fri)
by krake (guest, #55996)
[Link] (3 responses)
Thanks.
> Do many (non-FSF of course) GPLv3 projects have a single copyright holder?
I don't know, I guess it depends on whether that is deemed important.
Posted Oct 16, 2015 16:28 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (2 responses)
"Relicensing always requires the consent of the copyright holders."
That doesn't sound quite as doable.
> Do many of the non Apache Foundation Apache2 projects have a single copyright holder?
Doesn't really matter? It's easier to integrate into other projects without written consent from the copyright holders.
Posted Oct 16, 2015 16:32 UTC (Fri)
by bronson (subscriber, #4806)
[Link]
I mean: "That doesn't sound quite as easy."
Didn't mean to load the sentence. English isn't easy. :)
Posted Oct 16, 2015 16:50 UTC (Fri)
by krake (guest, #55996)
[Link]
Sure, but that is independent of the choice of license for the fork, no?
It seems some commenters conflate two orthogonal things: the license of the fork and the number of copyright holder of the fork.
Relicensing requires the consent of all copyright holders, whether the fork's license is proprietary or not.
The original comment claimed that relicensing a GPL licenses for was not possible at all, no matter the number of copyright holders.
Permissive licenses, community, and copyleft
This software is either largely irrelevant or it gets opened eventually. Case in point: LLVM.
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.
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.
Incorrect. As a business, I often can NOT use AGPL software safely _even_ _for_ _internal_ _purposes_. It's way, way too horrible to touch for companies.
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.
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
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Software for _internal_ systems. That depend on internal build and deployment systems, that in turn depend on other systems. Which often simply can _not_ be opened because of hard-coded sensitive data or metadata.
Permissive licenses, community, and copyleft
>Software for _internal_ systems. That depend on internal build and deployment systems, that in turn depend on other systems. Which often simply can _not_ be opened because of hard-coded sensitive data or metadata.
Permissive licenses, community, and copyleft
AGPL says that you have to give people the ability to run their own version of the service you're running.
Permissive licenses, community, and copyleft
13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Yes, it is ugly. Yes, we know it and we are working on fixing it eventually.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> Software for _internal_ systems. That depend on internal build and deployment systems, that in turn depend on other systems. Which often simply can _not_ be opened because of hard-coded sensitive data or metadata.
>
> It's entirely possible for AGPL to cascade down to pretty much everything. That's why it's so toxic that pretty much no enterprise company deploys it.
Permissive licenses, community, and copyleft
No, to _everyone_. Every employee will automatically receive an AGPL license to internal source code and will be able to distribute it at will.
Lawyers rarely have problems with GPLv2. Unlicensed blobs are actually far less scary - often there's an implied license in place and in the worst case the company will have to cease using these blobs.
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
Permissive licenses, community, and copyleft
Neither can proprietary code be merged without the consent of the copyright holder, nor does the GPLv3 (or any other version) prohibit the copyright holder to given such consent.
Permissive licenses, community, and copyleft
This software is either largely irrelevant or it gets opened eventually. Case in point: LLVM.
LLVM is really an exception right now IMO. It's working currently because one of it's largest developers is contributing their commercial changes back and most of the other companies working on it are tools and plugin vendors. Apple is doing this because they don't really have a competitor right now and they are an underdog in the game. They are essentially the only major commercial company using a BSD like kernel and Unix like tool chain with a significant commercial presence. There are a limited number of compilation engines on their platform and they don't develop significant revenue from them. Openness helps them sell hardware so it's advantageous for them to hand out their changes. Many of the other companies working on it are selling closed tools and plugins.
But I can guarantee without absolute certainty that just like the bad old days in Unix where everything fractured and become incompatible, the minute that someone can monetize their changes to LLVM and it become a competitive advantage they will stop contributing changes back and the community will begin to come apart at the seams.
I think LLVM works right now because GCC destroyed a bunch of the commercial compiler market with a freely available good compiler (and remains as a check on the market), but the side market, the supplemental tools market which uses LLVM needs a functioning free compiler they can use to offer extensions to. GCC specifically prevented this so as a result LLVM has been thriving but I think it's more the exception that proves the rule. LLVM wouldn't exist if not for GCC IMO. And it's success is more a function of this specific market and how GCC changed it than because LLVM is permissively licensed.
Permissive licenses will work only in situations where revenue isn't dependent on product differentiation. Given time and large dollar figures changing hands a permissive license will eventually fragment into several proprietary forks, just like Unix did. The GPL is the only license that works in these markets because everyone is forced to donate back. Companies who make the choice to use the software understand that the time and development they donate won't be lost to a competitor that grabs it all, improves it and locks it up in a proprietary license. There is no such guarantee with a permissive license and if the $$$ are there it will happen. (you could also argue the implicit patent license in the GPL protects all contributors from other contributors submarining a patent then suing the pants off everyone else)
As an example, BSD was functional enough that it could have supplanted the Unix license after the trial if the large unix vendors would have re-based and contributed their changes back. It didn't because there was large money to be made not working together. It was enough money that continuing to pay ATT buckets of money wasn't a concern when they could have grabbed the free one and used it.
Permissive licenses, community, and copyleft
No, it's not - the dynamics is more complicated. Apache WebServer, Hadoop and PostgreSQL are other great examples.
>> Incidentally, GPL software be used for internal projects too without triggering the requirements for source release.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.
Permissive licenses, community, and copyleft
Relicensing always requires the consent of the copyright holder.
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
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
English is not my primary language, I wasn't aware that the use of the singular was in any kind special.
Do many of the non Apache Foundation Apache2 projects have a single copyright holder?
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Which clearly is wrong.