
GPLv4 – Starting the Conversation (2014) - amingilani
https://www.christopherprice.net/gplv4-starting-the-conversation-2580.html
======
tspiteri
I don't really understand the point of this article. For one thing, it
conflates open source and free software, a difference which can be unimportant
to many people, but is definitely important to the FSF, the GPL owners. And
although they both result in freely available source code, they do have very
different aims. The article is pushing open source aims, while the FSF pushes
free software aims.

The article also shows a poor understanding of the GPL itself. For example,
when talking about dynamically linked software, it is stated that since SMB
was under the GPL, Apple was "afraid that someone might ... force Apple to
share the entire source code of OS X." No! The GPL can never force you to
share your source code. What it can do is stop you distributing software that
isn't yours and that you were using under the GPL. In this example, the worse
that could happen to Apple is that they would lose their rights to distribute
SMB if they were found to have broken the GPL terms.

~~~
ZenoArrow
The dynamic linking issue is not as clear as you make out. To give an example,
let's say a company decides to make a proprietary fork of a GPL software
application. They keep all of their proprietary code in a separate library to
the GPL code and dynamically link to it. Does the GPLv3 licence permit this?

~~~
belorn
The moment someone mention dynamic linking and GPL is the point where one need
to think about the law rather than computer technology. Dynamic linking does
not exist in the definition of derivative work, and the legal concept is only
used by the FSF as a public guideline on where to draw the line (and thus when
they will enforce the license).

What you will have to ask is, what will a non-technical judge think is one
work with different labeled parts, or two separated works that are
interacting. Questions like "If I remove one, do I still have a something that
make sense to call a work?", "how was it created and what was the intention of
the creator", "how would a end-user perceive the result", and in many
jurisdictions, "what is the industry standard" (judges has shown a tendency to
avoid decision which would cause disruption in the market).

> let's say a company decides to make a proprietary fork of a GPL software
> application

If they intentionally trying to go against the wishes of the author, its
likely infringing the license regardless if you use technology X or technology
Y.

~~~
ZenoArrow
The 'wishes of the author' are not spelled out in clear terms in the GPL,
that's the issue. For example, if I create a music production application, and
use SoX to create audio spectrograms, what level of integration with SoX is
permitted for a proprietary application? Stealing the code and putting it in
your own codebase would obviously be a big no-no, but what if you used Sox in
the form of a .dll/.so? The GPL code wouldn't be compiled alongside
proprietary code, but it would be required for a non-core feature of the
application to function.

This is the type of vagueness that a future GPL revision should seek to
address, by refining what is meant by 'dynamic linking'.

~~~
belorn
Going through the questions above, the first answer seems clearly on the side
of being a separate work, but the second one brings us to a big question: Is
the SoX integration the only method for creating audio spectrograms, and is it
a feature being presented as a part of the application? Is there maybe emails
by the developers that talk about the feature as part of the application, or
is there emails showing that the application is only being made compatible
with SoX? What is included in advertisements, and are customers of the
proprietary application perceiving the application as one work being
compatible with SoX?

Law is never certain, but I suspect the answer to the thought experiment is
that the application is creating a derivative work. It could however be that
the application is only providing compatibility with SoX, among many other
similar programs installed on customers machine, in which case it might be
fair use or maybe not a derivative work at all. It depends on the details.

A similar thought experiment is to ask why no large company has tried to
challenge the guideline of dynamic linking as line in the sand regarding
derivative work. How rare would it be that a company want to include non-core
optional features in their proprietary products that need to be dynamically
linked rather than using inter-process communication, and they want to go to
court about it?

------
yarrel
At heart this is a call for several reductions in user freedom. The GPL exists
to protect the freedom of users. So these reductions will not be introduced
into the GPL, unless there is an extremely good tactical reason for doing so.

"Because my company really, really, really wants to restrict our users freedom
and we want to exploit free software to do so" isn't a good tactical reason.

That said, many of the things the author asks for are already included in the
GPLv3. You can place DRM software under the GPL. You get a compliance window
if you break the GPL's terms. It refers to "shared libraries and dynamically
linked subprograms".

So this isn't a conversation that needs to happen. Or if it is, it's one that
needs to start with a bit more listening.

------
mordae
> This would allow for protected content (DRM video, for example) to display
> securely, while allowing it to interact with other secure apps and services
> – and still allow for unsigned code.

Fuck you.

~~~
bryanbuckley
I find it interesting the DRM hate of the crowd given the Libertarian
leanings. I'm personally somewhat excited about the prospect of a
democratized/p2p and open/ubiquitous DRM.

It seems much of the hate is that we don't like being shown we don't really
own something completely with no restrictions (the HW or the DRM good) even
though we bought it or that DRM gets too much in the way. Seems like the GPLv4
could help with the first former (where the trusted computing bits are opt-
out, like in a BIOS or registry).

~~~
belorn
Which libertarian philosophy is against strong property rights? When someone
sell property, the seller should not have a right to exercise powers that are
exclusively to the new owner. DRM is the technical method to remain in control
over property after sale, where contract would be the legal method when
renting out property.

In open DRM, how and whose digital rights are being managed by said
technology? If I lock down my laptops boot loader, is the laptop the digital
right that I am "managing" with said security, or is it simply the terms TPM
and DRM that is being incorrectly used interchangeable? To use "Open" DRM on
property that the digital property owner also own seems as a very rare
situation, for example a music studio whose owner want to prevent employees at
the studio from making unauthorized copies. The benefit of "open" DRM seems
very minor to the world, where the benefit of open security technologies, such
as a TPM, seems as a much grander goal.

~~~
bryanbuckley
> When someone sell property, the seller should not have a right to exercise
> powers that are exclusively to the new owner.

Sorry to say, but it is already the case of many computing devices:
[https://www.youtube.com/watch?v=gbYXBJOFgeI&feature=youtu.be...](https://www.youtube.com/watch?v=gbYXBJOFgeI&feature=youtu.be&t=19m44s)

If you buy an iPhone, what exactly do you own?

I hope this stuff gets cleared up, of course. Would be nice to run some free
software on any computing device you own.

> DRM is the technical method to remain in control over property after sale,
> where contract would be the legal method when renting out property.

I agree at least the "owner" should be allowed to boot alternative SW, but it
means DRM for digital assets will not be functional (you could dual boot..),
as well as some silicon, I imagine.

> In open DRM, how and whose digital rights are being managed by said
> technology? If I lock down my laptops boot loader, is the laptop the digital
> right that I am "managing" with said security

No. I mean SW or digital assets (or digital titles to physical assets). Open
DRM would be one in which anyone that has some SW/digital asset they wish to
use DRM to control the usage of is capable of doing so. Whether or not the
gatekeepers will allow it remains to be seen. The effect of p2p DRM on society
would be hard to predict.

------
Luker88
> Additionally, code contributions prior to the raising of an objection,
> should be exempted from forced source code disclosures.

Sorry, but this is a retarded proposal. Courts take a hell of a lot of time to
rule, and considering the usual software release cycles, it means you are
allowing virtually unrestrained usage of the GPL'd software.

The HP case should be better handled, but you are providing a loophole "ops,
debug build" for everything. You need to be careful there.

The better definition of dynamic/static linking is something needed,
personally I'd like to have a modular concept here similar to the CC license,
where the developer decides which is allowed.

I'm also fine with the tivoization clause, but again, make it modular. With
some projects it is not an issue, while others might want to give control to
the user, as in "the user must be able to alter the installed software under
this license", or similar.

I want only one new feature, though (modular, as well): deterministic builds.
I want to easily check that someone is using my software without non-
approved/released modifications. With this it would become only a matter of
publicizing the build environment.

------
bkuhn
I always find it frustrating when people pontificate about how the GPL should
work who have never done the hard work to enforce it (BTW, I'm always looking
for volunteers who want to help in the really really boring work of enforcing
the GPL, but I rarely get any takers once I start describing what the work
entails).

I've done and/or led more GPL enforcement than anyone on the planet, for more
than a dozen different copylefted projects, and I've done it as a volunteer,
as an employee of both FSF and Conservancy, and for GPLv2-only, GPLv3-or-
later, and LGPLv2.1 works.

While I love, as a purely intellectual exercise over a nice meal, to talk
theory with people who only have a theoretical understanding, real world
experience with the licenses is the center of drafting good copyleft licenses.
The GPL might as well be the ISC license if its clauses are never enforced, so
enforcement is really the litmus test on how the license is working and what
changes are needed. If the author or anyone else would like to get involved
with "field research" and help in Conservancy's enforcement efforts for Linux,
Samba, BusyBox and other projects, I'm easily contactable.

Anyway, I think what Christopher Price and others in this thread are really
looking for is the copyleft-next project. It's Richard Fontana's project
that's attempting to redo copyleft licensing from first principles and from
(initially) a theoretical basis. I'm a fan of the project as I do think a
"redrafting from ground up done in a community fashion" is a good idea to try
in parallel to the existing functioning copylefts like GPL.

But saying "GPL is broken, therefore we need a GPLv4" is not terribly helpful.
GPL is on the verge of collapse not for most of the reasons pundits say it is,
but because (a) it's widely violated, (b) few people are willing to enforce,
(c) some of those who enforce won't follow community Principles when they do,
and (d) there is heavy political opposition from wealthy corporations and
trade-associations against those who do enforce, even when they commit to
follow published community Principles.

IMO, those are the biggest problems GPL has now, and I work every week to seek
to solve those.

Sure, having been involved with copyleft policy since the early 1990s, I keep
a private bug list of GPLv3 (i.e., things I'd like to see in GPLv4). But, it's
far from my top priority, and it shouldn't be the community's top priority,
IMO, either.

~~~
angersock
What do you think can be done about the four points you've raised? Could you
elaborate on point (d)?

~~~
bkuhn
The biggest impact individual developers can make on all the points I raised
is to _keep their own copyrights on copylefted works_ and _do not sign an
employment contract unless it explicitly allows you do to that_.

Developers have more leverage in employment negotiation than they realize.
Right now, most copylefted codebases that have historically had mostly
individuals holding the copyrights are drifting to having companies mostly
hold the copyrights. We have to stop this trend.

If individual developers hold copyrights, they make their own decisions about
enforcing, and companies who oppose enforcement have less leverage.

------
chme
Since when should the GPL protect companies?

I always thought of FSF and GPL as way to protect consumer rights and
interests.

~~~
_ph_
All users of an open source program would benefit, if more companies would
contribute to that open source program. In that sense, encouraging companies
to contribute is helping consumers.

A lot of companies are very open source friendly these days and consequently
are happy to open source parts of their software stack. Using a BSD type
license makes this very easy. GPL however, forces companies to open source the
whole software stack and that is very often not possible for companies, be it
that they need to make money by selling the software, or that some code parts
contain trade secrets or that they do have some code parts licensed
themselves.

~~~
donatj
This is legitimately why we don't touch GPL code with a ten foot stick.
BSD/MIT are awesome however.

~~~
Narann
GPL is about user freedom (you can access the code you execute), BSD/MIT is
about developer freedom (you can copy paste the code).

This explain why developers tent to prefer BSD/MIT licences, they can use code
without restriction and restrict their users to access it. It's just that GPL
focus on protecting users, not developers.

~~~
erlehmann_
Strategic reasons for choosing different licensing models exist. The Free
Software Foundation itself reccommends using different licensing models for
software libraries depending on the situation:

• No copyleft for libraries that implement proprietary standards competing
with open standards, to further adoption of the implemented standard among
proprietary software developers.

• Weak copyleft for libraries that implement the same features as existing
proprietary software, to further adoption of the library among proprietary
software developers.

• Strong copyleft for libraries that “do not face entrenched noncopylefted or
nonfree competition”.

[https://www.gnu.org/licenses/license-
recommendations.en.html](https://www.gnu.org/licenses/license-
recommendations.en.html)

~~~
saosebastiao
> No copyleft for libraries that implement proprietary standards competing
> with open standards,

Shouldn't that be the other way around?

~~~
erlehmann_
Yes.

------
phire
The dynamic linking clause is there for a reason, as it closes a massive
loophole (put gpled components in a DLL, open source just the DLL and load it
into your closed source program). But it does need to be clarified to more
directly target just that loophole.

Currently there are questions about using opengl/vulkan drivers in a GPLed
program on windows. They aren't part of the operating system (supplied by the
GPU venders instead), so dynamically linking to them would create a gpl
violation. But they implement standardised APIs that really should be
considered as part of the OS.

~~~
rleigh
At the same time, it also introduces ambiguity and uncertainty. The GPL-3
doesn't define what "dynamic linking" is. While it might be relatively clear
for the simple case of a "static" or "shared" library, what about:

\- libraries opened with dlopen \- libraries with an equivalent non-GPL
licenced equivalent e.g. readline, which has a BSD-licenced reimplementation
\- libraries accessed via IPC to a coprocess hosting the library

In all these cases, I can be intimately tied to the API/ABI of a library but
unsure of my legal status with respect to GPL-3 compliance obligations. While
I understand the general intent, I'm unhappy that this is open to
interpretation and that the legal standing of this is not at all clear cut.

Likewise with the anti-Tivoisation clauses. While again I understand and agree
with the intent, I feel that inserting the language to combat a single problem
has damaged the generality of the licence and made it much less attractive to
many as a result.

While I do like the GPL-2 and GPL-3 licences, I think it's fairly clear that
while GPL-2 was acceptable to many companies the GPL-3 is not, and while I may
disagree with their reasoning for their stance, the practical fallout from it
has been quite detrimental. I've certainly started using BSD or MIT licences
more frequently for recent projects, where I would previously have used GPL-2
or -3 by default, simply because the licence profusion has made licence
compatibility between a project using a lot of differently licenced shared
libraries a very real problem.

------
josteink
While I think the proposed changes makes sense, I don't think the FSF welcomes
them as much.

The FSF has always thought for getting the _full stack_ GPLed, and creating
clauses which makes it easier to silo out the GPLed bits, while keeping the
rest of the system locked down will probably not ring well with them.

Which is probably why we look at this post 2 years later, with seemingly
nothing done to address the concerns raised.

------
ninkendo
I have an incredibly oversimplified way of thinking about things that I'm
wondering if somebody can poke holes in:

GPL is for applications (ie. complete products), BSD/MIT-alike are for
libraries (ie. standalone components used to build complete products.)

Most of the language in the GPL is incredibly problematic for library use.
What does linking really mean? Is a "derived work" of a library anything that
uses the library? Or is it a derived work only if I change the library itself
and not release the patch? Ok, so there's the LGPL to disambiguate that... so
for the common case of libraries, use the LGPL, got it.

But wait, that doesn't really make sense. What is the LGPL guarding against
that make it any better than MIT/BSD? Are they thinking corporations are going
to do something like patch GTK and not release the patch? That's incredibly
unlikely. It's a huge burden to maintain a downstream patch of a library.
Moreover, any patch you're likely to make to a library like (for instance) GTK
is probably general purpose, and would be an abstraction violation to place
any of your business logic in it, right?

If I'm a library writer, what is the motivation to use LGPL or GPL? LGPL
doesn't seem much more protective than MIT/BSD in this case, except it
prevents the contrived scenario of someone wanting to create proprietary
patches to the library itself. And GPL only makes sense if I want to ensure
nothing other than other GPL software can link against it (maybe useful for
dual licensing like Qt? Or libraries that want to only exist in linux
distros...)

Now on the application side, all the language in the GPL starts to make a
_lot_ more sense. Linking doesn't really make sense for complete applications
like web browsers and photo editors, so it's ok that it's ambiguous (nobody's
likely to link to the GIMP.) The GPL seems to be written with the assumption
that a derived work would look like a re-distribution of some existing open
source product with some proprietary changes, which is certainly evil.
Generally it's a really good idea to use GPL here to prevent that. For
complete products like applications, it's hard to imagine why you wouldn't
want those protections if you're the copyright holder.

You could go even farther with the logic by saying the only real point of
using GPL for libraries would be to help cause more proliferation of GPL'd
_applications_ , which is what the vision of the GPL seems to be aimed
towards: protecting the user by ensuring they can see the code behind the
applications they run.

~~~
wolfgke
>But wait, that doesn't really make sense. What is the LGPL guarding against
that make it any better than MIT/BSD?

With LGPL you can replace the shared library by a version that _you_
built/updated/... (thus gives freedom) which is not possible for MIT/BSD
libraries.

~~~
_ph_
Of course you can do the same with MIT/BSD libraries. Nothing in those
licenses prevents that. To be fair, in contrast to the LGPL, the BSD/MIT
licenses do not explicitly require the ability, this does not remove it. And
whether an user is actually able to rebuild and replace a LGPL library in
practice is another question.

------
Pica_soO
I think, what the next GPL needs is too use of the long breath of the free
software movement. I mean, the ability of a GPL Project to be used in closed-
source and after a given time frame (5 years) the whole resulting code-base
must be re-released into open source.

Many software products contain GPL-Licensend content, and these "quick-and-
dirty" predecessor-software is abandoned once the producer reaches a certain
"Lets-Refactor-it-out" success. The GPL could become a breaker of the infinite
copyright and a driver of inventions, while at the same time providing the
major advantages closed source holds for a limited time.

~~~
nwah1
Sounds like an interesting compromise between BSD/MIT licenses and GPL, but
definitely not something GPL4 will have.

GPL is about ensuring everything is always open, and is incredibly purist
about that. Any deviation would ruin their reputation and go against
everyone's expectations for the GPL brand.

~~~
Pica_soO
That purism prevents it from subverting its shortsighted opponents

------
current_call
_Companies are people_

No, they're not. Even if they were, the GPL is not for protecting companies.
The GPL is not for protecting developers. The GPL is for the users.

~~~
nixos
It's more than that.

Why do I release OS code? Because I want to make the world a better place,
building a "commons" so everyone benefits.

What if you don't want to contribute back to the commons? What if your company
doesn't value the commons? Fine. You can pay me for my time.

I don't need to volunteer my time to make Windows, MacOS, or Proprietary forks
of Android better.

Remember the controversy of CyanogenMod going commercial? I didn't understand
the issue. If Google and Samsung can take your code and use it in proprietary
apps, why can't Cyanogen?

