Permissive licenses, community, and copyleft
On the final day of LinuxCon Europe 2015, HP's Chief Technology Officer Martin Fink delivered a bold keynote about software licensing. Fink recapped the negative effects of license proliferation and addressed projects that use their choice of license as hostile act against the competition. He then ended the session with an extended appeal to move the open-source software industry away from permissive licenses like Apache 2.0 and toward copyleft licenses like the GPL. Not doing so, he said, puts the FOSS community at just as much risk of collapse as license proliferation threatened to in years past.
![[Martin Fink]](https://static.lwn.net/images/2015/10-linuxcon-fink-sm.jpg "Martin Fink")
Fink started out by addressing HP's just-announced launch of the OpenSwitch project, a new "network operating system." HP is doing the project because it believes open source has "won"—at least in general—but that there are a few isolated hold-outs, including high-end network operations. OpenSwitch code is released under the Apache 2.0 license, he said, because the other partner companies viewed that as a requirement. That was a decision that he promised to return to in a few minutes.
Looking back to 20 years ago, though, Linus Torvalds chose to release the kernel under the GPL, rather than under a "permissive" license. That was a really big deal, he said, in light of the many alternatives. Fink asked the audience to guess, by a show of hands, how many "open source licenses" they believed there are. The correct answer is about 70, he said—depending on how one counts. One curse of the term "open source" is that it can gloss over all of the critical complexities involved, such as license details. But, he added, it was almost much worse.
The proliferation problem averted—mostly
License proliferation was so rampant ten years ago that Fink made a public plea at Linux World 2005 for the Open Source Initiative (OSI) to stop adding new licenses to its approved list. The problem, of course, is that each additional license increases the complexity of the ecosystem and, thus, creates a legal maze that makes it hard to participate. "If I had been Steve Ballmer, trying to kill Linux, I would have just encouraged people to make more licenses."
To its credit, Fink said, IBM responded to his call by stopping its practice of crafting new licenses. But not everyone did, he added. Oracle, in fact, is still creating new licenses: in 2014 it unveiled the Universal Permissive License (UPL). But the UPL does nothing new, Fink said. "If Oracle asks you to use it, tell them you will as soon as they license their own stuff under it. You'll find that conversation coming to a stop."
Another license used by Oracle, the Common Development and Distribution License (CDDL) originally written by Sun, is intentionally incompatible with the GPL, Fink said. So there are CDDL-licensed projects like ZFS and DTrace that "are great, but they can't be used" by the community.
The GPL incompatibility of the license demonstrates that some people have a residual fear of copyleft, he said, which is left over from the Steve Ballmer days. "So now I'm trying to get people over that. Copyleft is a simple, good thing: share and share alike." People who gravitate toward "permissive" licenses do so because "it feels safe." But what "safe" means in this case is that it allows them to go produce proprietary software. "So, in a way, we're enabling the very thing that we are trying to undo."
Permissiveness and community building
The Apache 2.0 license is currently the most widely used "permissive" license. But the thing that developers overlook when adopting it, he said, is that by using Apache they are also making a choice about how much work they will have to put into building any sort of community around the project. If you look at Apache-licensed projects, he noted, "you'll find that they are very top-heavy with 'governance' structures." Technical committees, working groups, and various boards, he said, are needed to make such projects function. But if you look at copyleft projects, he added, you find that those structures simply are not needed.
The difference stems from the fact that in Apache-licensed projects, "you've always got people who are trying to go off and do their own proprietary thing." That makes their contributions to the open-source project difficult to integrate and often at odds with other participants. In a copyleft project, such as the kernel, "there is no incentive to try and carve out your own little area." As a result, contributors just do their work and the project advances.
In the past few years, Fink said, the industry's default option has swung toward permissive licenses. "I'm calling out that you should change your default to a copyleft license like the GPL." Copyleft is good, he added; copyleft is what enables community. Fink did not distinguish between the different versions of the GPL in his comments; presumably because they are both strong copyleft licenses. The audience responded to the call for a copyleft default with a lengthy round of applause.
That brought his talk back to the OpenSwitch release. HP wanted to get networking companies and hardware suppliers on board. In order to get all of the legal departments at all of the partners to sign on to the project, he said, HP was forced to go with a permissive license. "But I hope that with some more education, people will see the self-governing, overhead-avoiding nature of copyleft, and we can get the pendulum to swing back to copyleft as the industry default."
Fink ended by making a charge directly to the audience. "Do everything you can to avoid license proliferation. When someone proposes a new license, resist it. If you need help, there are people like Eben Moglen who will engage them directly to change their minds." As for existing licenses, he had another charge to deliver. "All of you are enabled to change things. You can take an Apache-licensed project and go make a GPL version of it. Some of you will start new projects. When you do that, start them with the GPL."
Fink's comments, no doubt, will draw some ire from people who reside on the "permissive" side of the fence—either on the particulars of Fink's assessment of the Apache license or on the directness with which he encouraged attendees to take action in promoting copyleft licenses.
Regardless of where one falls on the spectrum, though, it was certainly refreshing to hear sharp critique of licensing issues, and to hear it from the main stage of a large open-source conference. Keynotes at industry conferences can easily lapse into cautious or bland territory that focuses on promoting one's new product line. Whatever else it did, Fink's keynote raised hard questions and challenged the listeners to take action; surely keeping licensing questions at the forefront of the FOSS community's conversation can only be good.
[The author would like the thank the Linux Foundation for
travel assistance to attend LinuxCon Europe.]
| Index entries for this article | |
|---|---|
| Conference | LinuxCon Europe/2015 |
Posted Oct 14, 2015 19:40 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (147 responses)
And people are asking why GPL projects are on the wane. Here you have an answer.
Posted Oct 14, 2015 19:54 UTC (Wed)
by klbrun (subscriber, #45083)
[Link]
Posted Oct 14, 2015 20:25 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Oct 15, 2015 1:13 UTC (Thu)
by wolftune (guest, #100179)
[Link]
Posted Oct 14, 2015 21:15 UTC (Wed)
by spaetz (guest, #32870)
[Link]
How would that be any worse than taking the code and making a proprietary version of it. Apache license explicitely allow that and it's the reason people chose it? Serious question.
Posted Oct 14, 2015 22:09 UTC (Wed)
by robert_s (subscriber, #42402)
[Link] (4 responses)
Seems to be working out for LibreOffice.
Posted Oct 14, 2015 22:48 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Oct 15, 2015 6:46 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (2 responses)
Posted Oct 15, 2015 6:49 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Oct 22, 2015 8:03 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
You haven't been reading my comments on LO for, oh, ages then :-) LibreOffice (and Go-OO before it, to the best of my knowledge) have ALWAYS required a licence of MPL. (Which is compatible with (L)GPL, but discourages the use of anything else. If contributors want to use eg Apache or MIT, the project won't stop them but doesn't approve of it.)
Before my time, but the choice of licence, as I understood it, was a weak copyleft so companies (especially IBM) could add proprietary extensions if they wished (short precis of MPL - MPL code itself is copyleft, but allows linking to SEPARATE non-copyleft modules, bit like LGPL).
That's actually why, I gather, so many old Go-OO hands felt absolutely cheated by the Apache fiasco - having made the project MPL specially so's IBM in particular could add proprietary bits, IBM's defection to Oracle's side (and RW's anti-LO campaign) was a kick in the teeth.
Cheers,
Posted Oct 14, 2015 22:17 UTC (Wed)
by debacle (subscriber, #7114)
[Link] (137 responses)
If I understand you correctly, you critizise people who create a copyleft fork of a permissive license project, right? But what about somebody (say, a company) creating a closed-source fork of a permissive license project? Isnt' this worse? If so, why not use copyleft in the first place? But maybe I got you wrong.
> And people are asking why GPL projects are on the wane.
I don't share the impression, that GPL projects are on the wane. I see even more AGPL software now. But I have only "anecdata". What is your evidence?
Posted Oct 14, 2015 23:06 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (136 responses)
> But what about somebody (say, a company) creating a closed-source fork of a permissive license project? Isnt' this worse?
GPL branch creates a _permanent_ branch. GPL code can not __ever__ be merged back into Apache2/BSD projects (without requiring upfront copyright assignments or dual licensing).
> I don't share the impression, that GPL projects are on the wane.
> I see even more AGPL software now. But I have only "anecdata". What is your evidence?
Posted Oct 14, 2015 23:46 UTC (Wed)
by jra (subscriber, #55261)
[Link] (81 responses)
You may not personally like them, but those who write the code get to chose the license. People who release Apache2 code are explicitly allowing it to be incorporated into GPL projects under GPL licenses. You might not like that either, but then that's what Apache2 allows - lobby the Apache foundation to change their license if you don't like it.
As Martin points out, large successful projects with healthy communities prefer copyleft.
Posted Oct 14, 2015 23:56 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (80 responses)
>People who release Apache2 code are explicitly allowing it to be incorporated into GPL projects under GPL licenses. You might not like that either, but then that's what Apache2 allows - lobby the Apache foundation to change their license if you don't like it.
A GPL fork of Apache2 project creates a permanent split in the community, driven only by ideology. This. Is. Not. Nice.
PS: I'm not talking about simply using Apache2 projects in GPL projects.
PPS: OpenOffice vs. LibreOffice situation is special.
PPPS: It's also perfectly OK to take over dead projects and move them to GPL. If there's no community then there can't be any problems with splitting it.
Posted Oct 15, 2015 1:04 UTC (Thu)
by jra (subscriber, #55261)
[Link] (27 responses)
If you dislike GPL so much I don't understand why you aren't discussing this on *BSD weekly news instead (if such a thing exists :-).
Posted Oct 15, 2015 1:47 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (26 responses)
As a user, I actually like the idea of GPLv3. But as a developer I absolutely hate that FSF tried to use GPLv2 as a blunt force instrument to further their ideological agenda. And I'm actually glad to see that it has backfired.
My personal favorite license would be a LGPLv2 license with static link exemption and better technical language from GPLv3.
Posted Oct 15, 2015 2:38 UTC (Thu)
by jra (subscriber, #55261)
[Link] (11 responses)
"There you go again".
This item isn't about GPLv3. No one mentioned GPLv3 in the comments until *you* brought it up.
What's that old saying ?
“A fanatic,” says Winston Churchill, “is one who can't change his mind and won't change the subject.”
PLEASE STOP TALKING ABOUT GPLv3 ! EVERYONE KNOWS YOUR OPINION AND NO ONE HERE CARES.
Posted Oct 15, 2015 2:41 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
This implies GPLv3 - you can't convert Apache 2 into GPLv2.
> “A fanatic,” says Winston Churchill, “is one who can't change his mind and won't change the subject.”
Posted Oct 15, 2015 5:25 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (5 responses)
I know, right? Sheesh. It's like Greenpeace - they always keep going on about the environment. Why can't they ever mention the benefits of eco-destruction, or just talk about something else entirely for a change? And if only the ACLU would mention something other than "civil rights" every once in a while?
Why /are/ these _organisations_ that are specifically dedicated to a single cause, so dedicated to a single cause?
Posted Oct 15, 2015 6:43 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Oct 22, 2015 8:14 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Which is why I won't touch Greenpeace with a barge-pole. They seem to prefer sound-bites and PR coups to actual solid science and, you know, actually achieving something.
Unlike, for instance, the RSPB (Royal Society for the Protection of Birds). While ideologically opposed to hunting, they recognise that hunters have money, and more to the point, hunters DON'T WANT to drive their prey to extinction. So while they wouldn't do it from choice, they do work with hunting organisations in order to achieve habitat protection. A classic example is they bought a reserve (can't remember which one). On various occasions, a great fuss was made that shooting regularly took place on the reserve. But when they bought the land, the shooting rights were unavailable (or too expensive, or whatever). Faced with the choice of losing the land or permitting shooting, they bought the land with the intention of dealing with the shooting later. And they have.
And I get the impression a lot of people (Linus included) seem to have the same impression of the FSF, as I have of Greenpeace. It's a shame, RMS is a great prophet. But more and more he seems unable to grasp the bigger picture.
Cheers,
Posted Oct 18, 2015 17:19 UTC (Sun)
by flussence (guest, #85566)
[Link]
I'm not sure if you chose that example out of naivety or irony.
Posted Nov 5, 2015 17:21 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Greenpeace have the blood of *millions* of innocents on their hands due to their fundamentalist opposition to life-saving technology, making them arguably the most villainous group of people in the world today, so I think they're a fairly weak example.
Posted Nov 5, 2015 18:16 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
(if the citation is some weird rant pro or contra GMOs, feel free to spare us)
Posted Oct 15, 2015 13:40 UTC (Thu)
by airman (subscriber, #7341)
[Link]
Posted Oct 15, 2015 17:46 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (2 responses)
Posted Oct 21, 2015 4:45 UTC (Wed)
by ayers (guest, #53541)
[Link] (1 responses)
Posted Oct 21, 2015 7:28 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 15, 2015 13:58 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (13 responses)
This doesn't seem very GPL-like to me (I'm picturing Toothless from "How to Train a Dragon" for some reason :) ). The static link exception basically means folks get to say "sure, here's the code; good luck replacing it in the binary".
Posted Oct 15, 2015 20:45 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
In my opinion, the greatest strength of LGPL is that it forces developers to give back changes to the library itself without propagating to its dependencies. I see this as very fair - kinda like Linus' "tit-for-tat" model.
Posted Oct 16, 2015 1:52 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (11 responses)
Posted Oct 16, 2015 4:11 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Oct 18, 2015 15:51 UTC (Sun)
by krake (guest, #55996)
[Link] (3 responses)
Relinking an application is just more complex if the library is not loaded by the runtime linker.
Posted Oct 19, 2015 0:06 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Please, educate yourself before posting.
Posted Oct 20, 2015 5:37 UTC (Tue)
by krake (guest, #55996)
[Link] (1 responses)
Interesting proposal from someone who obviously has not seen the license text of the LGPL.
Spoiler: it does not even contain the string "static".
> That's why QT still has a costly proprietary license, for example.
Some recipients do not like the clauses of the LGPL, e.g. their legal department doesn't want to look into copyleft licenses or they want to incorporate the Qt code into their own directly and not link it.
And there are those who, like yourself, fell for the rumor that statically linking requires the proprietary license.
However, people falling for a rumor, no matter how many, does make the license actually say that.
So, in practise, people think there is a restriction which, in practise and theory, does not exist.
Posted Oct 29, 2015 17:36 UTC (Thu)
by pboddie (guest, #50784)
[Link]
And, once again, the "commercial" aspect need not have anything to do with proprietary licensing. There are companies making money selling support for Free Software. Maybe even HP manages to do so.
Posted Oct 16, 2015 6:00 UTC (Fri)
by raof (subscriber, #57409)
[Link] (5 responses)
That's useful, yes, but is the license the best place to enforce this? Are there any other best-practises that should be mandated by the license?
I, too, would like a “LGPL, but usable on Android, iOS, with Rust, etc” license. It is not unreasonable prioritise the “contribute back” aspect of the LGPL over the “user freedom to replace components” aspect. (Nor is it unreasonable to prioritise the latter over the former, although I don't do so).
Posted Oct 16, 2015 14:58 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link] (4 responses)
Posted Oct 16, 2015 17:54 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Oct 18, 2015 0:23 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link] (2 responses)
In virtually all countries, copyright rules are largely in favor of the author. The only thing an author can't do is say "license A + license B are compatible" without modification if the rules of the licenses are written to not be so. So essentially, you can't be delusional.
Posted Oct 18, 2015 2:48 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Oct 22, 2015 8:20 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
X has effectively said "you can licence my code under Z", but if the people who own other code Z don't want it licenced under Y, then it isn't available under Y.
Cheers,
Posted Oct 15, 2015 15:01 UTC (Thu)
by krake (guest, #55996)
[Link] (42 responses)
Isn't a proprietary fork not also a split in the community? Or are people working on the proprietary fork always counted as part of the community even when they do not contribute anything?
As far as I can tell a fork is always a split, a GPL fork is at least available to everyone once it is distributed.
Posted Oct 15, 2015 17:58 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (23 responses)
The GPL fork is obviously not available to anyone working on the proprietary fork. If the GPL fork loses steam, and the proprietary fork keeps rolling, the work that went into the former is effectively lost forever. The reverse is no big deal.
Posted Oct 15, 2015 19:00 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (19 responses)
You're assuming that "proprietary" means "single copyright holder". Under those conditions even a GPL fork could be relicensed and merged back in the future. If the proprietary fork includes code from multiple parties, some of whom do not want their contributions made public, then merging back from the proprietary fork to the original project may prove equally difficult. At least the GPL fork is already open source, even if it isn't as open as you would like.
The conditions for merging back are the same in both cases: obtain permission from all of the contributors to the fork.
Posted Oct 16, 2015 7:03 UTC (Fri)
by krake (guest, #55996)
[Link] (17 responses)
People easily mix up orthogonal concepts when they mistakingly assume causation when seeing correlation
Posted Oct 16, 2015 16:39 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (16 responses)
I'm not saying that's the way it *should* be, just that that's the way it is. The typical large GPLv3 project is effectively unrelicensable. The typical large proprietary project is very much relicensable, requiring the consent of only one or a few parties.
It's just simple statistics, nothing to do with causation.
Posted Oct 17, 2015 8:39 UTC (Sat)
by krake (guest, #55996)
[Link] (15 responses)
Other posters here treat it like causation.
There is evidence against all of these points, rendering the whole causation treatment void.
Posted Oct 17, 2015 23:26 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
If a project has many copyright holders, then getting them all to agree is difficult. Sometimes outright impossible, if some copyright holders become unresponsive, unreachable or dead.
It applies equally to GPS and proprietary projects. The distinction is that typical proprietary projects have only ONE copyright holder.
Posted Oct 18, 2015 9:24 UTC (Sun)
by krake (guest, #55996)
[Link] (13 responses)
Well, yes, but since the GPL does not forbid copyright holders to relicense, it does not restrict that possibility any more than a proprietary license without such restrictions.
> If a project has many copyright holders, then getting them all to agree is difficult.
Exactly!
These people lack fundamental understanding of how software development works.
Posted Oct 18, 2015 9:29 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
> Exactly!
Posted Oct 18, 2015 10:01 UTC (Sun)
by krake (guest, #55996)
[Link] (11 responses)
Exactly.
> Which doesn't make any of it possible.
No restricting something does not make an impossible thing possible.
Given a bucket of water, using glass does not make drinking impossible.
Posted Oct 18, 2015 10:18 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
A) It's complicated to relicense projects with many copyright holders.
D) Proprietary projects usually do not have many copyright holders.
Posted Oct 18, 2015 10:36 UTC (Sun)
by debacle (subscriber, #7114)
[Link] (3 responses)
If it were GPLed or something from the start, that would not have been a problem. Therefore I prefer copyleft licenses. A competitor, who valued software freedom more than my ex-employer (they did not at all at that time) would have had a competitive advantage, if they would be able to use copyleft code.
Yes, for either very trivial software or very huge/rich companies, you might have only one copyright holder in the proprietary world, but very often third-party proprietary code or libraries are incorporated. Or the company changes ownership ten times during the development of the software and finding out who can do what with the software becomes very messy. A change of license can be much harder than in any free software project.
Posted Oct 18, 2015 10:52 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Most proprietary developers don't like to use 3rd-party proprietary tools, unless 3rd-party tools provide essential functionality.
And in your case if you think that it was possible to develop this project without 3rd-party code, it should be possible to rewrite the 3rd-party components and release everything as OpenSource.
Posted Oct 18, 2015 11:21 UTC (Sun)
by debacle (subscriber, #7114)
[Link] (1 responses)
Then, the discussion about what is technically "possible" is very often not relevant, but more how easy or cheap I can reach a certain goal. Legally "impossible" is much harder IMHO. If it were easy/cheap to rewrite some huge libraries, than there were no harm done by a GPL fork of a permissively licensed project. Just rewrite the GPL-only stuff. Yes, it is possible, but sometimes just very time-consuming and we all have better things to do :~)
Posted Oct 19, 2015 2:16 UTC (Mon)
by dlang (guest, #313)
[Link]
When one side says it's trivial, and the other side says it's hard, looking at the evidence from past cases seems appropriate.
it sure doesn’t look easy based on the evidence
Posted Oct 18, 2015 10:45 UTC (Sun)
by krake (guest, #55996)
[Link] (5 responses)
As I've written in another comment, number of copyright holders affects relicensing, not the license before relicensing.
Someone earlier claimed that using GPL as a license would make it impossible to relicense, but, as we agree , it does not.
While the commentor was obviously wrong, it is somewhat understandable.
Correlation vs Causation can be tricky business for people who are new to something.
That's why I find it important to clarify when such misinterpretations happen, allowing people to get a better understanding
Posted Oct 18, 2015 10:49 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
It's NOT possible to relicense GPL projects with large amount of copyright holders in practice. Just like the laws of thermodynamics don't forbid your head from spontaneously exploding right now, it hasn't happened yet because it's extremely unlikely.
Posted Oct 18, 2015 11:02 UTC (Sun)
by krake (guest, #55996)
[Link]
It is a question of number of copyright holders not one of license.
Posted Oct 20, 2015 11:03 UTC (Tue)
by Sesse (subscriber, #53779)
[Link] (2 responses)
/* Steinar */
Posted Oct 20, 2015 18:39 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
See:
https://github.com/mpv-player/mpv/issues/2033
and the current checklist of contributors:
https://github.com/mpv-player/mpv/issues/2033#issuecommen...
Posted Oct 21, 2015 7:31 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
It's not enough just to rewrite their code - it must be done using a 'clean room' approach. I.e. one team reads the code and produces a detailed specification and another team writes code to this spec, without communicating with the first team.
Posted Oct 17, 2015 9:32 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link]
For example, Solaris contained a lot of BSD-derived code, but it was not possible for Sun to release all of Solaris as open source in 2005, because of third party copyright ownership. Hence OpenSolaris required various "binary blobs" to build.
http://web.archive.org/web/20070212194134/http://www.open...
Posted Oct 16, 2015 6:41 UTC (Fri)
by krake (guest, #55996)
[Link] (2 responses)
You mean because nobody ever had access to it anyway?
Posted Oct 16, 2015 16:24 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (1 responses)
Posted Oct 16, 2015 16:40 UTC (Fri)
by krake (guest, #55996)
[Link]
Posted Oct 16, 2015 14:41 UTC (Fri)
by drag (guest, #31333)
[Link] (17 responses)
Probably not in most cases. A person or company that is willing to do a proprietary fork and not contribute changes back is also a person that will not contribute to a open source project in a meaningful way. As in the case of the Linux kernel many companies will use it without any intention of giving anything back.
In they end you can't rely on copyright restrictions to involuntarily make a person or company a 'good citizen' of a community.
The best you can hope for is to use the GPL to help people realize that contributing back to open source/free software is a advantage for them, since it forces them to make a conscious decision, rather then taking comfort in some limbo 'middle ground'. But that is only going to work when that GPL software project is forgiving to some level of _potential_ infringement AND is competitive with the rest of the industry.
As mentioned above the GCC project is a prime example of losing a competitive advantage by trying to use anti-features combined with copyright restrictions to force people to be 'good citizens'. This backfired by ruining the compiler suite for a number of businesses, who then went and created their own open source compiler suite that is now in the process of forcing GCC into irrelevance when it comes to new projects and new languages.
These companies obviously had no issue in contributing their 'IP' back to 'the community' when it came to low-level software development.. because that is exactly what they did. Even though it probably cost them a huge amount of money to develop the software in the first place. Their business models actually aligned with open source/free software in GCC's case. So it seems very likely that the primary reason they did write a competitive suite in the first place is due directly to GCC governing project's behavior and policies that limited their involvement.
This is really too bad for a lot of reasons. One of the reasons, in my mind at least, is that historically it seems that the GNU folks are actually much more flexible then, say, Apache is when dealing with licensing issues and conflicts and are generally willing to work with people. Unfortunately with the GCC the idea of people writing potentially proprietary plugins and wrappers for it was too much for them to handle.
Posted Oct 18, 2015 1:35 UTC (Sun)
by dvdeug (guest, #10998)
[Link] (16 responses)
If "those companies" are not worth naming, they're probably not worth discussing.
Now in the process of forcing GCC into irrelevance is pretty questionable. LLVM certainly drew off many users of GCC's C/C++/Objective-C frontends, especially the last. But a quick glance leads me to believe that GCC makes at least slightly faster code, and it is the supported compiler for the kernel, so Linux distributions have no reason to change. LLVM claims a lot of languages, but what's really interesting is what's known to work. People aren't generally going to use DragonEgg with GCC 4.6 (or 4.8, but the DragonEgg website says best with 4.6) when they can use the very well supported Ada or Go frontends in GCC 5. (Maybe Fortran.) Nobody is going to use Scala with LLVM so long as all the development work goes into the JVM Scala. Few of the LLVM ports are going to go any further then a lot of the unused JVM or .NET ports that languages were sporting a few years back.
Sure, LLVM is now the compiler for iOS development work. If you use Objective-C or Swift, you use LLVM. But if you use Go or Ada, you use GCC, and quite likely if you use an open source C or C++ or Fortran. Irrelevance is still many years coming, if it truly comes at all.
Posted Oct 18, 2015 2:57 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (15 responses)
Meanwhile GCC is still failing to move out of its niche as a static compiler. It's right now marginally better than LLVM, but this is already changing.
It's also interesting that you mentioned Ada and Go. The first one is pretty much irrelevant and the second one is falling behind the mainline Go. Turns out that GCC's performance advantages are not worth additional complexity of using GCC for most users. Meanwhile self-hosting LLGO ( http://llvm.org/klaus/llgo/ ) is progressing nicely.
Posted Oct 18, 2015 17:50 UTC (Sun)
by lsl (subscriber, #86508)
[Link] (1 responses)
That link shows 9 commits in the last six months, a third of which just update the local copy of gccgo's libgo (so much for self-hosting). From what's left, the only non-trivial one is a bulk import of some line editing library. All the nice progress must have happened more than six months ago, surely.
Posted Oct 19, 2015 2:49 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 21, 2015 4:00 UTC (Wed)
by dvdeug (guest, #10998)
[Link] (2 responses)
Ada is pretty much irrelevant but look at this shiny Rust frontend? Despite the fact that Ada is 27th on the TIOBE Index for October 2015 and Rust is 49th? The 2012 standard for Ada helped firm up Ada's niche, and while it's probably on the way out, well, we said that about C, too (#2 on the list). Whereas Rust is interesting, but it may be used, or it may fall into a pile of interesting languages that never hit critical mass.
In any case, besides counting races that have barely begun as being over, what does this have to do with licenses? Every time you say that LLVM is better at something, it makes it less likely that LLVM is being used by people for its license. The only way one example could even start to talk about licenses is if one product really sucked and yet was being used by a significant number of people because of its license; something that happens between open-source and proprietary code sometimes, but not really among open-source licenses.
Posted Oct 21, 2015 7:23 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> In any case, besides counting races that have barely begun as being over, what does this have to do with licenses? Every time you say that LLVM is better at something, it makes it less likely that LLVM is being used by people for its license.
Posted Nov 1, 2015 1:33 UTC (Sun)
by dvdeug (guest, #10998)
[Link]
Claiming that the license lets LLVM be used in spaces that GCC can't is a special-purpose claim; it's basically <i>why</i> LLVM and GCC can't be used as the end-all and be-all of how GPL is doing against less-restrictive licenses.
Posted Nov 10, 2015 21:06 UTC (Tue)
by jwakely (subscriber, #60262)
[Link] (9 responses)
Where does libgccjit fit into your worldview?
> It's right now marginally better than LLVM, but this is already changing.
By what metric?
Did you consider that GCC has implementations of the C++ Concepts TS, Filesystem TS, Transactional Memory TS, and pretty soon the draft Networking TS ... none of which are available in Clang?
Does OpenMP 4 support matter?
> It's also interesting that you mentioned Ada and Go. The first one is pretty much irrelevant and the second one is falling behind the mainline Go. Turns out that GCC's performance advantages are not worth additional complexity of using GCC for most users.
What about the fact that mainline Go only support x86 and arm? If you're not "most users" are you out of luck?
> Meanwhile self-hosting LLGO ( http://llvm.org/klaus/llgo/ ) is progressing nicely.
Someone else already debunked this claim.
Posted Nov 10, 2015 21:57 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
> By what metric?
> Did you consider that GCC has implementations of the C++ Concepts TS, Filesystem TS, Transactional Memory TS, and pretty soon the draft Networking TS ... none of which are available in Clang?
> Does OpenMP 4 support matter?
> What about the fact that mainline Go only support x86 and arm? If you're not "most users" are you out of luck?
Posted Nov 13, 2015 10:05 UTC (Fri)
by jwakely (subscriber, #60262)
[Link] (5 responses)
Posted Nov 13, 2015 17:58 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Nov 16, 2015 20:59 UTC (Mon)
by jwakely (subscriber, #60262)
[Link] (3 responses)
GCC has concepts and TM (and Filesystem, "just library code" or not) and Clang doesn't (yet).
GCC has OpenMP4 and Clang doesn't (yet).
GCC supports more architectures (albeit ones that you don't care about).
Why am I deluded about that? Are you just spouting off or do you have something useful to say?
Posted Nov 16, 2015 21:32 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
For example, let's compare with LLVM announcements for the last couple of weeks:
So pretty much the only objection is that GCC has OpenMP4 which LLVM will only get in the next release (they're still failing a couple of tests). Yeah, I'm pretty sure that it's a mortal blow to LLVM.
I'm pretty sure that the development focus has shifted from GCC, permanently.
Posted Nov 16, 2015 21:51 UTC (Mon)
by jwakely (subscriber, #60262)
[Link] (1 responses)
Oh, so when LLVM has something announced, but at least a year from existing, that's a plus point for LLVM, but when LLVM has something existing and GCC is only talking about it, that's also a plus point for LLVM. You should try to make it a bit less obvious when twisting facts to suit your agenda.
Newsflash: GCC already has a high quality Fortran front-end, with vectorization.
> I'm pretty sure that the development focus has shifted from GCC, permanently.
What does "the development focus" mean?! If you mean loudmouths on the internet who contribute nothing to either project are spending their time hyping LLVM, I must agree. As far as actual development goes, both projects seem active and healthy to me.
Posted Nov 17, 2015 5:25 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> What does "the development focus" mean?! If you mean loudmouths on the internet who contribute nothing to either project are spending their time hyping LLVM, I must agree.
Do you know anything exciting happening lately with gcc? It still has some momentum and a lot of developers are more familiar with it (so it gets new C++ features faster), but it's clearly fading.
Posted Nov 11, 2015 3:38 UTC (Wed)
by lsl (subscriber, #86508)
[Link] (1 responses)
That's no longer true. The gc compiler for Go now additionally supports aarch64/arm64, mips64 and power. There's also someone working on SPARC support, I think, but no idea how far it is. Probably not going to be part of the coming 1.6 release.
Posted Nov 13, 2015 10:06 UTC (Fri)
by jwakely (subscriber, #60262)
[Link]
Posted Oct 17, 2015 0:45 UTC (Sat)
by cas (guest, #52554)
[Link] (8 responses)
It's not just ideology. There are very strong practical reasons why many people prefer to contribute to a copyleft project rather than an Apache or BSD licensed project. The main one is that their contribution can never be made proprietary by some scumbag parasite. GPL == "Once free, always free." Some people feel strongly enough about that they will not contribute to "permissively licensed" projects under any circumstances.
Posted Oct 17, 2015 1:24 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Oct 19, 2015 20:45 UTC (Mon)
by vomlehn (guest, #45588)
[Link] (6 responses)
The original poster said (with my emphasis): So, you don't have an argument with that person. I'm one of those that strongly prefers to contribute to copyleft projects because I like knowing that the time and effort I put into that contribution won't be taken and used by someone who doesn't pay for it with their contribution. And--this is key--I see that such projects get more stuff done. That is not ideology, it's economics--I get a bigger bang for the expenditure of my time and energy If your experience is different, that's judgement. Which is still not ideology. I'm presently working on a project that is substantial in size and which I own completely. There are only two choices I'm considering for licensing: make it it proprietary or use GPLv2. I'm pretty sure it will be the later because it just won't be able to gain a user base in any other way and allowing proprietary forks will starve it of creative input. Which is entirely practical and not ideology.
Posted Oct 19, 2015 20:58 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
Is there a particular reason you've excluded GPLv3? (Genuinely curious here; I personally prefer v3 over v2)
Posted Oct 19, 2015 21:30 UTC (Mon)
by vomlehn (guest, #45588)
[Link] (1 responses)
My personal viewpoint is that legally requiring giveback is simply allowing better enforcemnt of the human norm. There have been quite a few interesting studies over the past decades about just how deeply we human are built for cooperation and getting along. I simply want to encourage that. A legal requirement to give back allows the use of lawyers (useful tools, on occasion) to dig deep within an organization to discover whether violations are occurring. Otherwise, you'd never know. (Well, not strictly true, ask the Busybox folks how they discover violations).
I really like GPL3's clearer language (wish I could get a GPLv2 that was so clear) but I disagree that licensing is the way to enforce people's right to run whatever they want on hardware they own. Knowing whether you are allowed to load your own software on a device that you bought and nominally own is immediately visible to anyone. This allows market forces to come into play and, in this case, I think I can trust the free market, eventually, with enough education.
And what if market forces aren't enough to ensure all devices are open? Well, then The People have spoken and we will get what we deserve.
Posted Oct 19, 2015 22:41 UTC (Mon)
by pizza (subscriber, #46)
[Link]
A way to achieve this is to use "GPLv3 plus an exception" -- that way you get the clearer language, but you can explicitly waive the hardware-related clauses.
But thanks for your explanation!
Posted Oct 20, 2015 4:56 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
However I also want the possibility of building commercial products and extensions. It's my firm belief that only in this way can software development survive and thrive.
Posted Oct 20, 2015 7:06 UTC (Tue)
by debacle (subscriber, #7114)
[Link]
In my view, "free vs proprietary" and "commercial vs non-commercial" are orthogonal.
Posted Oct 22, 2015 17:39 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
PLEASE add some bugfix extensions!
That, unfortunately imho is the elephant in the room with GPL. It has some important bugfixes, but adds a host of non-copyright requirements too.
One bugfix in particular - under the GPL v2, if you provide binaries and source as two separate downloads, it triggers the "source for three years" requirement :-( If the user doesn't download the source, the wording of v2 means you have to keep the source publically available.
Not sure quite how you'd word it, but I would have thought a simple "If you make the source available with the binaries, the failure of a user to download source will not trigger clause X.X" (whichever it is).
That's the main problem I'm aware of, others may point out more.
Cheers,
Posted Oct 15, 2015 1:27 UTC (Thu)
by wolftune (guest, #100179)
[Link] (41 responses)
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.
Posted Oct 15, 2015 14:58 UTC (Thu)
by krake (guest, #55996)
[Link] (2 responses)
I don't think that can be true.
You can always go more permissive since that does not restrict any of the freedoms that the GPL protects.
Posted Oct 15, 2015 20:35 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Of course, this assumes that there's no copyright assignment.
Posted Oct 16, 2015 6:56 UTC (Fri)
by krake (guest, #55996)
[Link]
Posted Oct 15, 2015 19:57 UTC (Thu)
by xtifr (guest, #143)
[Link] (1 responses)
A very few companies may end up seeing the benefits of releasing their source. But it's just as likely that they'd be more willing to release their source if the code were licensed under the GPL, which prevents their competitors from taking advantage of their changes without reciprocating.
The GPL is far more business-friendly than any of the permissive licenses. There's a reason Trolltech agreed to release Qt under the GPL rather than a more permissive license. They're not idiots.
As for "contributes [...] in other ways", I've never heard anything so irrelevant in my life! Contributing a patch to git does not absolve you of violating the license of any other project.
Posted Oct 15, 2015 21:47 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
For long-running forks, though, the cost of maintenance is proportional to the size of the patch. So eventually the company might decide to merge it back to reduce their workload. And even if a company doesn't merge the whole fork back, they're likely to contribute changes they made to the core of the project.
Sony is a great example - they're actually merging the patch for PS4 support to LLVM and clang, even though it's useless without a Sony PS4 devkit which very few users have.
Posted Oct 16, 2015 2:11 UTC (Fri)
by dvdeug (guest, #10998)
[Link] (6 responses)
And why would that be a problem for a GPL fork? Why would a JIT compiler for a new open-source language be a problem, but a JIT compiler for a proprietary one not be?
> They are. See: LLVM vs. gcc.
A sample of one? Seriously?
Posted Oct 16, 2015 19:23 UTC (Fri)
by drag (guest, #31333)
[Link] (5 responses)
Posted Oct 18, 2015 0:38 UTC (Sun)
by dvdeug (guest, #10998)
[Link]
Posted Oct 18, 2015 7:22 UTC (Sun)
by xtifr (guest, #143)
[Link] (3 responses)
It's a very poor example. One project, entirely supported by a company that has a long-running hate on for the GPL in general, and the FSF in particular. A company that was forced to release the source to their Objective-C compiler years ago because they based it on GCC. The only company that has ever been the subject of an actual boycott by the FSF. There's no love lost between these two.
Apple loves permissive licenses, because the code can be incorporated in their proprietary software and third-party proprietary software. They want their customers locked down, tied in, in their little walled garden, with as little freedom as possible. Programmer freedom, they're fine with, as long as the users don't have any!
Even Microsoft and Oracle aren't as anti-user-freedom as Apple. Apple spins themselves as freedom-loving to developers, because they want to use third-party software to lure in more users they can lock down. Copyleft is a total threat to their goals, because it preserves the freedoms for users. So yeah, after their experience with ObjC, and given their hatred of user freedom, it's no surprise that they're willing to invest huge sums to try to knock GCC off its throne.
But it's a completely atypical example, for exactly that reason Suggesting that it shows anything about any general trends is utterly ridiculous.
Posted Oct 18, 2015 8:53 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Oct 19, 2015 1:07 UTC (Mon)
by xtifr (guest, #143)
[Link] (1 responses)
A company that specializes in creating what is essentially Tivo-ized hardware, and is thus particularly opposed to the GPLv3. To the point of near-phobia. Ridiculously extreme near-phobia.
And even so, what does their feelings about the GPLv2 have to do with the fact that LLVM is heavily funded by a company that is firmly opposed to what the FSF is doing? Which makes it an extremely atypical example?
I mean geeze, way to completely miss my point!
(And, of course, if you've mainly been working with LLVM, you probably haven't noticed how much gcc development has accelerated recently. So even if it were a good example, it wouldn't be a very good one.)
Posted Oct 19, 2015 2:54 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> And even so, what does their feelings about the GPLv2 have to do with the fact that LLVM is heavily funded by a company that is firmly opposed to what the FSF is doing?
> Which makes it an extremely atypical example?
> (And, of course, if you've mainly been working with LLVM, you probably haven't noticed how much gcc development has accelerated recently. So even if it were a good example, it wouldn't be a very good one.)
Posted Oct 15, 2015 5:58 UTC (Thu)
by fredrik (subscriber, #232)
[Link] (1 responses)
HP, please let me know when you have licensed Integrated Lights Out under the GPL. Oh, and the firmware for all those fine printers too. I've always wanted to fix the bug that stops my printer from using all of the ink in the cartridge. Go go GPL!
Mr Flink also manage to conflates the Apache 2.0 license with the organizations that prefer to use said license. The Apache software foundation, the creator of the ASL, may appear to have a emphasis on bureaucracy. But that is a good thing for user of software produced by Apache projects. It means that we can be confident of the authenticity of source code and that it is intentionally and rightfully submitted to the project. It would of course not have mattered if the Apache projects instead were copyleft. It is the organization that guarantees proper copyright control, and that's valuable in itself, regardless of license.
Communities are build by people. The license, whether permissive or copyleft doesn't matter. Corporations are, probably out of necessity, more explicitly requiring copyright control of software they use when compared to individuals. Obviously that makes it easier for corporations to engage with open source projects that are backed by a clear organizational structure, such as the ASF.
There are many wonderful communities under the umbrella of the ASF. People who are there because of their day job engage with people who are there because of the fun of it. And some of the day job folks may even be there because of the project's permissive license, not despite of it.
Posted Oct 15, 2015 7:49 UTC (Thu)
by hugoroy (guest, #60577)
[Link]
Reference needed, as they say on Wikipedia.
For instance, Black Duck claims the MIT license is more widely used. https://www.blackducksoftware.com/resources/data/top-20-o...
Posted Oct 15, 2015 19:09 UTC (Thu)
by SimonO (guest, #56318)
[Link] (4 responses)
Forking one way or another is a developer's choice, right? That developer can choose to use any license, or a combination! It would be respectful in a way to dual licence the code under the original and GPL*, so that the original community can pick up and use that code as well. However, the developer of the code may not want to contribute to closed source software derived from the original community. That is a valid choice that deserves as much respect (IMO) as the choice of the permissive community to share permissively.
Complaining about a GPL fork of an apache2 licensed project is just as much lacking respect as dissing developers who create and/or contribute to such a gpl fork.
time will tell which type of licence is the most successful in keeping code alive and available, the developers contribute where and how they want to, it's their prerogative.
Posted Oct 15, 2015 19:21 UTC (Thu)
by emunson (subscriber, #44357)
[Link] (3 responses)
The developer that does the work, makes the decisions. As long as the original license isn't violated, what is the problem?
Posted Oct 16, 2015 2:15 UTC (Fri)
by Abrahams (guest, #103692)
[Link]
Posted Oct 17, 2015 1:10 UTC (Sat)
by rahvin (guest, #16953)
[Link] (1 responses)
But all forks break communities apart, that's exactly what a fork is, irreconcilable difference between developers and a decision to go their own way. I personally don't see any problem with forking in general because the only other option is the part that's upset simply stops contributing which also breaks the community.
Posted Oct 29, 2015 23:18 UTC (Thu)
by bignose (subscriber, #40)
[Link]
I disagree. The license explicitly chosen allows that action directly, so it is in direct accord with the explicit grant of license from the copyright holders.
If the copyright holders don't want that to happen, they have a well-known path that is completely in accord with software freedom: grant a strong copyleft license that *disallows* imposing further restrictions on the redistributed work.
By the logic of “applying license restrictions on a free-software work is rude”, those who find it rude should be embracing strong copyleft for their work. That they do not, speaks to a great confusion in their minds, I think.
Posted Oct 19, 2015 5:37 UTC (Mon)
by Beolach (guest, #77384)
[Link] (3 responses)
I really don't like the absurdly long copyright terms currently common throughout the world (life + 50 years or longer from the Berne Convention). That's not the main focus of most open-souce licenses, but something I see as a significant side-benefit. But even the Creative Commons licenses, which were more directly inspired as copyright reform, don't really directly address shortening copyright term (or loosening copyleft requirements after X years).
Posted Oct 19, 2015 21:43 UTC (Mon)
by rfontana (subscriber, #52677)
[Link] (2 responses)
The conditions in sections 2 through 5 [i.e., the copyleft conditions] no longer apply once fifteen
Posted Oct 20, 2015 16:52 UTC (Tue)
by jra (subscriber, #55261)
[Link] (1 responses)
"License proliferation was so rampant ten years ago that Fink made a public plea at Linux World 2005 for the Open Source Initiative (OSI) to stop adding new licenses to its approved list. The problem, of course, is that each additional license increases the complexity of the ecosystem and, thus, creates a legal maze that makes it hard to participate. "If I had been Steve Ballmer, trying to kill Linux, I would have just encouraged people to make more licenses."
or are you just trying to resurrect the license proliferation problem 'cos you're a fan of zombie shows ?
Writing a new license is *not* helpful at this point in time.
Posted Mar 15, 2016 3:02 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Posted Oct 23, 2015 15:45 UTC (Fri)
by BrucePerens (guest, #2510)
[Link] (1 responses)
Posted Jan 11, 2016 19:32 UTC (Mon)
by mfink (guest, #106262)
[Link]
The rate of creation of NEW licenses slowed dramatically. We created almost 60 licenses in 10 years, and then 10 in the 10 years that followed (approximate numbers). As you well know, it's also NOT possible to REDUCE the number of licenses, the best you can do is deprecate and discourage future use. Once someone has been licensed to something (unless there's an explicit termination of that license) you don't take it away.
One could counter argue that of the 70'ish OSS licenses in play, less than 10 are actively used. That's a good thing and awareness of the dangers of proliferation I'd like to think plays a role in people keeping their choices to just a few.
Martin
Posted Mar 15, 2016 2:53 UTC (Tue)
by pabs (subscriber, #43278)
[Link]
Permissive licenses, community, and copyleft
Nice move. Not.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> Nice move. Not.
> And people are asking why GPL projects are on the wane. Here you have an answer.
Permissive licenses, community, and copyleft
> Nice move. Not.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Wol
Permissive licenses, community, and copyleft
> Nice move. Not.
Permissive licenses, community, and copyleft
Yes.
No, it's not. If it's used for internal projects (for example, a JIT compiler for an internal language) then there's no problem at all. It's also likely to be merged sooner or later (see: Apple Swift, Sony PS4 clang, ...) and company likely contributes to open development in other ways.
They are. See: LLVM vs. gcc.
Yes, as dual-licensed software. Because AGPL is so horrible that nobody wants to touch it.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
The speaker actually advocates against it.
Have I ever said that it's _illegal_? I said that it's not a nice move. It's a completely dickish and selfish move.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> All of you are enabled to change things. You can take an Apache-licensed project and go make a GPL version of it.
Like, you know, FSF?
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
They both sometimes throw a baby with bathwater and harm their cause as a result. So yes, they are good examples.
Permissive licenses, community, and copyleft
Wol
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Ah, and I could also do without the shouting if it's not too inconvenient for you.
Have a nice day.
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
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> holes in libraries is pretty useful.
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
Wol
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
They imply that a GPL licensed project must have so many contributors while a proprietary does not.
They imply that contributors to a GPL licensed project are always unwilling to relicense their contributions while contributors to proprietary projects always are.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> [...]
> It applies equally to GPS and proprietary projects.
That's why some of these earlier comments were so ridiculous, trying to imply causation where there is none.
The the ability publish modifications is no ability to force anyone to include that modification.
Permissive licenses, community, and copyleft
Yes, and GPL does not prohibit communication with the dead or time travel. Which doesn't make any of it possible.
> That's why some of these earlier comments were so ridiculous, trying to imply causation where there is none.
You're trying as hard as possible to not understand the point. It's hard not to remember the Upton Sinclair's quote.
Permissive licenses, community, and copyleft
Not having a restriction just lets something that is possible continue to be possible.
But having a empty bucket and not having a glass does not make it possible.
Permissive licenses, community, and copyleft
B) Open Source projects usually have many copyright holders.
C) GPL is an Open Source license.
Ergo: it's usually complicated to relicense a GPL project.
Ergo: it's not usually complicated to relicense a proprietary project.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Presumably because the project wouldn't have existed at all.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
People hear about "open source", get an example like the Linux kernel, and then mistakingly conflate orthogonal concepts.
Permissive licenses, community, and copyleft
Do you understand a word of what other people are writing?
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
I.e. it is not "lost" because nobody ever "had" it?
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 only that. LLVM is also used in 3D drivers (Mesa) as a JIT engine for JavaScript in a major browser ( https://trac.webkit.org/wiki/FTLJIT ), as a backend for Rust, and in many other situations.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Yup. Pretty much nobody uses Ada outside of tight circle of defense contractors. And TIOBE, seriously?
Yes, license is extremely important. For example, Mesa3D wouldn't have been able to use GCC even if they wanted to. Ditto for FTL JIT that Apple uses now.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
In the usual place - nobody really uses it.
The speed of the resulting code.
Only concepts and transactional memory are related to GCC. Everything else is just library code.
OpenMP 3.1 is complete ( http://blog.llvm.org/2015/05/openmp-support_22.html ), OpenMP4 is in progress.
Yep. Also Clang doesn't support some crazy architectures which is perfectly fine by me.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
That several pretty much inconsequential differences actually mean anything.
- Google announced GPUCC support for LLVM, bringing in CUDA support ( http://llvm.org/devmtg/2015-10/slides/Wu-OptimizingLLVMfo... ).
- AMD announced LLVM-based CUDA translator ( http://www.amd.com/en-us/press-releases/Pages/boltzmann-i... )
- NVidia announced Fortran support with vectorization for LLVM.
- There's already a production-grade SPIR-V backend for LLVM, while a gcc backend is still being talked about.
- There's support for symbolic execution in LLVM, useful for static analyzers ( https://feliam.wordpress.com/2010/10/07/the-symbolic-maze/ ).
- There's a production-grade tracing JIT for LLVM, used on hundreds of millions of devices, while gccjit is pretty much dead.
- ...
Permissive licenses, community, and copyleft
> There's already a production-grade SPIR-V backend for LLVM, while a gcc backend is still being talked about.
Permissive licenses, community, and copyleft
Yup. It means that companies are actively investing in LLVM to the point where it's going to dominate everything else. And it will happen within a year or so.
It means that when you're starting a new project, you first go to LLVM and not gcc. E.g.: Rust, BEAMJIT ( https://lup.lub.lu.se/student-papers/search/publication/5... ), Pyston, beignet, ...
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> A GPL fork of Apache2 project creates a permanent split in the community, driven only by ideology.
Permissive licenses, community, and copyleft
> The main one is that their contribution can never be made proprietary by some scumbag parasite.
> GPL == "Once free, always free."
It IS ideology.
Permissive licenses, community, and copyleft
It's not just ideology.
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
>
> However I also want the possibility of building commercial products and extensions.
Permissive licenses, community, and copyleft
Wol
Permissive licenses, community, and copyleft
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.
Permissive licenses, community, and copyleft
The GPL does not, in any version as far as I know, require the code to be only licensed under the GPL terms.
The author, or depending on juristiction the copyright holder, can always relicense or add licenses, the GPL only ensures that the last version licensed under the terms of the GPL always remain at least available under these terms.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
> But what about somebody (say, a company) creating a closed-source fork of a permissive license project? Isnt' this worse?
Given the number of companies who refuse to cough up source for their GPL-derived projects, I find your "likely to be merged" claim extremely improbable. If companies are willing to break the law to keep their proprietary software proprietary, how much more likely is it that they will keep their changes to themselves if the can do so legally? But of course we don't really have hard data, because no one's looking for evidence of companies using permissively-licensed code, since it is legal.
[...]It's also likely to be merged sooner or later (see: Apple Swift, Sony PS4 clang, ...) and company likely contributes to open development in other ways.
> I don't share the impression, that GPL projects are on the wane.
So your sole piece of evidence that the GPL is on the wane is one project designed, supported, and funded by one of the most GPL-hostile companies out there, and one of the most evil companies to ever contribute to any open source projects ever, as part of a deliberate attack on the GPL? Sorry, that's not very convincing. I can just as easily point out LibreOffice vs AOO, which points the opposite direction. But the plural of anecdote is not data.
They are. See: LLVM vs. gcc.Permissive licenses, community, and copyleft
I don't speak about "release-and-forget" types of forks. Nothing will help with that (not even GPL). And really, they are of little interest to community in the long run.
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
...a company that had absolutely no problem with GPLv2 and was contributing to GNU projects up until GCC switched to GPLv3.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
You might note, that iPhone was barely out when Apple started switching to LLVM.
And what does it have to do with the dynamics of non-copyleft projects? Of course, many contributors to BSD and Apache 2 projects are allergic to GPLv3. That's the whole point!
I have provided several more examples.
Wake me up when someone starts to use GCC JIT in anger.
Permissive licenses, community, and copyleft
Claim that Apache-2 is the most used permissive license
Permissive licenses, community, and copyleft and freedom...
Permissive licenses, community, and copyleft and freedom...
Permissive licenses, community, and copyleft and freedom...
Permissive licenses, community, and copyleft and freedom...
Permissive licenses, community, and copyleft and freedom...
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
years have elapsed from the date of My first Distribution of My Work
under this License.
Permissive licenses, community, and copyleft
Permissive licenses, community, and copyleft
Martin has been complaining about this for 10 years and nothing has happened. Neither anything bad, nor any serious effort to reduce the number of licenses.
Yes, it's a pain that there are a lot of licenses, but in practice the combinatorial problem doesn't seriously hinder projects.
We are much more at risk from legal threats. For example, FCC's recent effort to prohibit Open Source drivers for WiFi devices, which might extend to operating systems for wireless devices.
The Sky Is Not Falling
The Sky Is Not Falling
Permissive licenses, community, and copyleft