Permissive licenses, community, and copyleft

Posted Oct 15, 2015 19:00 UTC (Thu) by nybble41 (subscriber, #55106)
In reply to: Permissive licenses, community, and copyleft by bronson
Parent article: Permissive licenses, community, and copyleft

> The point (IIUC) is that proprietary fork can still be merged back in the future (even gave a few examples of where that happened). A GPL fork can't.

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.

Permissive licenses, community, and copyleft

Posted Oct 16, 2015 7:03 UTC (Fri) by krake (guest, #55996) [Link] (17 responses)

Exactly!

People easily mix up orthogonal concepts when they mistakingly assume causation when seeing correlation

Permissive licenses, community, and copyleft

Posted Oct 16, 2015 16:39 UTC (Fri) by bronson (subscriber, #4806) [Link] (16 responses)

Except CLAs are frowned upon among open source projects, but they're the norm for commercial ones.

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.

Permissive licenses, community, and copyleft

Posted Oct 17, 2015 8:39 UTC (Sat) by krake (guest, #55996) [Link] (15 responses)

> It's just simple statistics, nothing to do with causation.

Other posters here treat it like causation.
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.

There is evidence against all of these points, rendering the whole causation treatment void.

Permissive licenses, community, and copyleft

Posted Oct 17, 2015 23:26 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

You seem to miss the issue. The problem is not willingness, but possibility.

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.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 9:24 UTC (Sun) by krake (guest, #55996) [Link] (13 responses)

> The problem is not willingness, but possibility.

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.
> [...]
> It applies equally to GPS and proprietary projects.

Exactly!
That's why some of these earlier comments were so ridiculous, trying to imply causation where there is none.

These people lack fundamental understanding of how software development works.
The the ability publish modifications is no ability to force anyone to include that modification.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 9:29 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (12 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.
Yes, and GPL does not prohibit communication with the dead or time travel. Which doesn't make any of it possible.

> Exactly!
> 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

Posted Oct 18, 2015 10:01 UTC (Sun) by krake (guest, #55996) [Link] (11 responses)

> Yes, and GPL does not prohibit communication with the dead or time travel.

Exactly.

> Which doesn't make any of it possible.

No restricting something does not make an impossible thing possible.
Not having a restriction just lets something that is possible continue to be possible.

Given a bucket of water, using glass does not make drinking impossible.
But having a empty bucket and not having a glass does not make it possible.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 10:18 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

Let me put it this way:

A) It's complicated to relicense projects with many copyright holders.
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.

D) Proprietary projects usually do not have many copyright holders.
Ergo: it's not usually complicated to relicense a proprietary project.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 10:36 UTC (Sun) by debacle (subscriber, #7114) [Link] (3 responses)

My own (limited, of course) experience with proprietary software development is different. Proprietary software very often makes much more use of proprietary libraries, tools, and source code than free software. E.g. one of my ex-employers developed communication protocols and they purchased the license to use proprietary source code, that were incorporated in their own software, as well as permissively licensed free software. The complete product was, of course, not free software and changing the license to anything free was legally more or less impossible.

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.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 10:52 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> If it were GPLed or something from the start, that would not have been a problem.
Presumably because the project wouldn't have existed at all.

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.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 11:21 UTC (Sun) by debacle (subscriber, #7114) [Link] (1 responses)

In my (limited) experience, developers are very often not free to decide what to use or not. Instead, there are company policies, company politics, project leaders preferences etc. Also, in my experience, developers of proprietary developers (I don't recall any exceptions) were more than happy to use whatever proprietary tool or library if it gave them at least a slight advantage. Most of my Windows programming ex-colleagues even used voluntarily "Visual Studio", something I would not even touch if MS released in under B-GPL-4.

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 :~)

Permissive licenses, community, and copyleft

Posted Oct 19, 2015 2:16 UTC (Mon) by dlang (guest, #313) [Link]

I would suggest that people go look at the reports of how much effort it takes for a company to open-source any of their software, specifically looking at how much effort it is to untangle what they want to release from libraries/patches/blobs provided by their suppliers.

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

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 10:45 UTC (Sun) by krake (guest, #55996) [Link] (5 responses)

Exactly.

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.
People hear about "open source", get an example like the Linux kernel, and then mistakingly conflate orthogonal concepts.

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

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 10:49 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> Someone earlier claimed that using GPL as a license would make it impossible to relicense, but, as we agree , it does not.
Do you understand a word of what other people are writing?

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.

Permissive licenses, community, and copyleft

Posted Oct 18, 2015 11:02 UTC (Sun) by krake (guest, #55996) [Link]

Yes, exactly.

It is a question of number of copyright holders not one of license.

Permissive licenses, community, and copyleft

Posted Oct 20, 2015 11:03 UTC (Tue) by Sesse (subscriber, #53779) [Link] (2 responses)

Well, I guess all depends on what you mean by “large”. VLC relicensed parts (notably all of the core) from GPL to LGPL a few years ago, and from a quick look, there's 830 committers in the git repository. I'm pretty sure it's not the only example.

/* Steinar */

Permissive licenses, community, and copyleft

Posted Oct 20, 2015 18:39 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

The mpv project also has an open relicensing issue. It references Mozilla for what constitutes "sufficient" permission to relicense from the contributor base (95%). VLC used 99.9% of code and 99% of developers as a metric instead.

See:

https://github.com/mpv-player/mpv/issues/2033

and the current checklist of contributors:

https://github.com/mpv-player/mpv/issues/2033#issuecommen...

Permissive licenses, community, and copyleft

Posted Oct 21, 2015 7:31 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

And if any developer who disagreed to relicense their code wants to sue - they have a high chance of succeeding.

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.

Permissive licenses, community, and copyleft

Posted Oct 17, 2015 9:32 UTC (Sat) by ms_43 (subscriber, #99293) [Link]

Indeed, and it's not a hypothetical problem.

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...