Why GNU License?

Dev
24

Speaking as someone who has been following the GPL/WP issues for some time… this last part is not entirely accurate.

The issues with GPL code and WP stuff is not entirely about derivative works. The problem is that the GPL has a clause in it about enforcing all code that runs in the same memory space and links to it as being GPL as well.

In other words, if a product depends on a GPL library that runs through direct linkage, the product code has to be GPL as well.

There are two exceptions for this: system software and common interfaces.

System software is the operating system; this exception is what allows GPL software to exist on Windows.

Common interfaces are a bit more tricky. MySQL is GPL (at least in theory). Non GPL code can contact it because it is through a common interface and doesn’t run in the same memory space. If it’s interacting on a code level and has any ability to share variables directly, it’s not through a common interface and therefore should come under the GPL rules on it.

This was the basis of the Thesis theme issues - the core code had to be GPL (because it was interacting with WP’s code at the code level), but the assets (JS, CSS, images) were accessed through a common interface (the browser) and were not subject to the GPL.

3 Likes
25

The problem is that the GPL has a clause in it about enforcing all code that runs in the same memory space and links to it as being GPL as well.

As with everything about the GPL, that only comes into play when the work is distributed. As long as you don’t distribute the code, that clause has no effect.

So then the question is if it’s possible to develop a piece of code that doesn’t legally derive from discourse but interoperable with it upon final installation upon the end user’s machine.

Obviously testing has to be done on the combined work, but if you don’t distribute the combination, and only send bug reports back up the chain, then you could still maintain that the developed code is not derivative. There’s a lot to be learned from the various reverse engineering cases in the last century as well. There a ways to document a thing, send the documentation to the engineering department that can then create similar things but not fall afoul of copyright issues. Since the GPL is entirely based on copyright, this principle comes into play:

This means it may be possible to create an interoperable work using clean room techniques that would allow the copyright issues to be void, and the GPL would only come into play when the code was actually integrated by the end user into the discourse code base. Again, the GPL only comes into play upon distribution of the work, therefore they can run the combined work on their server without violating the GPL.

That doesn’t mean that a sufficiently motivated team of lawyers couldn’t bankrupt the supposed violators anyway, but it still seems quite possible to fulfill the terms of the GPL and still create a plugin or other code modification that doesn’t need to be GPL in this very narrow set of circumstances.

3 Likes
26

AGPL did not work out well for several projects that chose it:

Yes exactly. Also it’s an odd license, to require that private changes only deployed to your web server must be shared.

There is no legal right to share private Discourse changes you make only on your Discourse instance running on your servers. There is a moral right to share, provided you think those changes are of interest to others, but I am sure plenty of per-server changes legitimately might not be that interesting, and I’m comfortable with others making that call as they see fit on their customized Discourse instances.

Most sharing is of the form “hey lookit this awesome thing I did, I bet you’ll think it’s awesome too” and I am fine with that. If it’s not awesome enough to share, then so be it.

2 Likes
27

I much prefer ethos of Stack Exchange, so Discourse putting WordPress on as beacon is… vaguely concerning. :slight_smile: It is fine to be inspired by good parts of it, but licensing is so not one of them.

Then why have it under GPL in first place?

Also while it’s great to see drift of components out of Discourse (which btw not something that ever happens in WP) you are blocking drift of incompatible code into it.

28

Only incompatibility that is common would be dtrace and its somewhat odd CDDL, most stuff is compatible going in.

Much of the components that are not extracted yet are simply a function of time. Its early days. Putting a more concrete question in place, are there any bits you would like to see us re-license?

1 Like
29

…doesn’t ring a bell, moving on. :slight_smile:

I am only figuring out where (if anywhere) Discourse fits for me. As WP developer my first reactions to it were:

  1. wat stack?
  2. pillage ember.js front end for nifties
  3. inquire if backend is swappable

So I am entirely not sure yet if there are any bits here for me to want.

30

Yeah, exactly this thing makes AGPL horrible. If you integrate e.g. a corporate SSO system that will not be of any use to someone outside the company having to release it - while usually not being a huge problem - is just annoying.

1 Like
31

Well, if Share-Alike is not something you care about, a non-copyleft licence could be better suited. The AGPL exists to ensure that client users of the software have access to the source code of the platform they are using. It is also one of the main motivations for share-alike clauses. That said, the fact that even private instances of the software have to redistribute their code is indeed annoying

By the way, mediagoblin is AGPL licenced and I have not seen strong concerns about that in the team.

2 Likes
32

They actually should clarify licencing with plugins and themes so that the Wordpress theme/plugin fiasco doesn’t happen here.

2 Likes
33

It is nothing to do with clean room design. The fact is, a plugin pretty much has to interact with the code at the code level. This means in order to distribute it, it must also be GPL. If it were the case that you could ship a non GPL plugin for WordPress by virtue of it being ‘clean room’ and not interacting, you would have a lot more paid plugin sites than you currently do - and the Thesis case would never have emerged because there wouldn’t have been a problem.

Unless the plugin API never exposes anything of any kind (variables etc.) to plugins, and there is no shared memory between the two, then the plugins would have to become GPL.

It’s even explicitly set out under Frequently Asked Questions about the GNU GPL v2.0 - GNU Project - Free Software Foundation

If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.

If the program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

I personally see this as fairly clearly stating where the line in the sand is for Discourse - plugins need to be GPL too…

1 Like
34

If the engineer that wrote the plug in never used, touched, or read the source code of Discourse, then any code he writes that interacts with discourse does NOT need to be released under the GPL.

I don’t see why you believe it needs to be GPL licensed when the copyright of discourse never comes into play, unless someone, at some point later, joins the plugin to discourse.

If the Thesis case is a problem, it’s likely because they did not use clean room design, and thus their code does, in some respect, derive from the GPL code, and therefore is subject to the GPL derivative clause.

If the code doesn’t derive from a GPL project, then the code is not forced to be GPL. The key issue is “derive” and a clean room design can ensure that, legally, the code did not derive from the GPL project.

Again, this is only a theory and not legal advice, but there’s a lot of history regarding copyright, software, and clean room design that suggests this is a possible defense. IT would require a LOT of work, so I don’t know that someone would go to the trouble, but you haven’t convinced me that the GPL somehow can force a copyright backwards through a clean room design process and claim derivative work on something designed using that process.

35

I’m thinking that my previous post still doesn’t explain the theory very well.

The idea is that the GPL depends entirely on copyright, and it only comes into play when someone who has obtained the GPL software (which we’ll refer to as GPL_Project) decides to distribute it in any form, or when they derive code (which we’ll refer to as Derived_Project) from it, and distribute that.

First point: If there is no distribution of either code base, the GPL never comes into play.

Now we hire an engineer to reverse engineer GPL_Project. They create documentation with absolutely NO code that describes how one makes a plugin. This documentation is copyrighted, fully and completely, by the engineer who created it, or the company she assigns it to. It does NOT derive from the GPL_Project, and thus is NOT under the GPL. This is what clean room design cases show - that one can create documentation that does not derive, legally, from the object they are documenting. Companies try to build a stopgap by requiring licensees not reverse engineer their product, but even if this was legally defensible, the GPL does not attempt to do that.

Second point: The documentation is not under the GPL.

Now we hire yet another engineer that takes the documentation, and uses it to create an entirely new piece of code that should, when properly installed, interact with GPL_Project correctly. However, it is developed without actually using GPL_Project, only the documentation. This code can be referred to as Novel_Project.

Third point: This Novel_Project is not subject to the GPL. The engineer, or the company he works for, owns the copyright, and it is not derivative of GPL_Project.

Perhaps this engineer sends the Novel_Project down to the first engineer, that does testing, and she sends additional documentation, again with NO CODE, back up to the Novel_Project engineer. This process repeats until both engineers agree the Novel_Project is inter-operating correctly with GPL_Project when installed correctly.

Fourth Point: Novel_Project still is not derivative. Due to the use of clean room engineering, and a clear boundary where only newly generated documentation crosses the barrier up, the Novel_Project is clearly a new work.

Now since ownership of Novel_Project and its copyright clearly belongs to the second engineer, or the company he works for, they can distribute it without worrying about the GPL status of the GPL_Project. The end user who receives a copy of Novel_Project can install it into their GPL_Project instance, and as long as they don’t distribute either piece of code, they are in compliance with the GPL.

This is the theory. Which point do you disbelieve?

2 Likes
36

How does a plugin to a system NOT reuse anything of the system?

Also, did you not read the post I linked specifically to the GPL’s own FAQ on the subject, which covers this specific issue?

Writing the plugin is fine. But the moment it’s released in any fashion, it must be released in a GPL compliant fashion or under a GPL compliant licence.

I’m not sure whether you’re just trolling at this point, but I’ll humour you anyway.

First point: no disagreement. GPL doesn’t force plugins to be GPL unless distributed. (Yay for GPL’s one advantage over AGPL.)

Second point: irrelevant.

Third point: doesn’t really matter whether it’s derivative or not. It’s going to interact on a code level. The definition in GPL terms is whether you spawn another process or not - I can’t imagine for one moment that that would occur. So, at this point the plugin must be GPL if it is to be released.

Fourth point: so what? Whether it is a new work or not actually doesn’t matter two hoots. The fact is it is communicating on some level with the parent, sharing variables etc. Unless a plugin has precisely zero contact with anything of the core, which would make it a fairly useless thing.

Let’s take a practical example: how would one pass authentication details to a plugin for the currently logged in user? Presumably, then, the plugin would have to read the cookies (common interface), query the database itself (common interface) and reperform authentication checks (debatably deriving code, but we’ll let it slide for the sake of argument)

You seem to have a very strange definition of what ‘clean room’ means when it comes to applying it to actual code in a real environment, and I refuse to waste any more time on this. The GPL FAQ actually answers this question, for this specific use case, go take it up with the FSF if you disagree.

1 Like
37

That’s where we disagree then.

When the Novel_Project is distributed, it isn’t interacting with the GPL code.

But until someone attempts it, and it’s tried in court it’s nothing more than legal navel gazing.

38

Isn’t this what BSD editline did w.r.t. GNU readline?

39

Yes, and in fact FreeBSD had to do this with a ton of OS code to free it from other licenses (not GPL or BSD) before it could be released:

The first CD-ROM (and general net-wide) distribution was FreeBSD 1.0, released in December of 1993. This was based on the 4.3BSD-Lite (“Net/2”) tape from U.C. Berkeley, with many components also provided by 386BSD and the Free Software Foundation. It was a fairly reasonable success for a first offering, and we followed it with the highly successful FreeBSD 1.1 release in May of 1994.

Around this time, some rather unexpected storm clouds formed on the horizon as Novell and U.C. Berkeley settled their long-running lawsuit over the legal status of the Berkeley Net/2 tape. A condition of that settlement was U.C. Berkeley’s concession that large parts of Net/2 were “encumbered” code and the property of Novell, who had in turn acquired it from AT&T some time previously. What Berkeley got in return was Novell’s “blessing” that the 4.4BSD-Lite release, when it was finally released, would be declared unencumbered and all existing Net/2 users would be strongly encouraged to switch. This included FreeBSD, and the project was given until the end of July 1994 to stop shipping its own Net/2 based product. Under the terms of that agreement, the project was allowed one last release before the deadline, that release being FreeBSD 1.1.5.1.

FreeBSD then set about the arduous task of literally re-inventing itself from a completely new and rather incomplete set of 4.4BSD-Lite bits. The “Lite” releases were light in part because Berkeley’s CSRG had removed large chunks of code required for actually constructing a bootable running system (due to various legal requirements) and the fact that the Intel port of 4.4 was highly incomplete. It took the project until November of 1994 to make this transition, at which point it released FreeBSD 2.0 to the net and on CD-ROM (in late December). Despite being still more than a little rough around the edges, the release was a significant success and was followed by the more robust and easier to install FreeBSD 2.0.5 release in June of 1995.

(source)

Duplication isn’t great, but there are times when one needs a different license, and re-inventing the wheel is unfortunately necessary.

Using these legal techniques to get around the intent of a license can be annoying, but it’s worth thinking about what is possible when choosing a license, knowing that you may have unintended consequences, and you might not be able to control all the variables you’d like to control.

40

Note that it gets pretty weird around this place:

This means the plug-ins must be released under the GPL or a GPL-compatible free software license

Basically GPL FAQ tries to postulate that GPL rules affect extensions despite their circumstances (even if they were developed clean room style) and conceded to downgrade requirements to compatibility, since code derivative concept leaks like crazy.

This is where current situation with WordPress extensions currently is, quietly conceded from earlier views of all extensions being hard direct derivative of WP core.

However this is where it gets murky as well - why precisely does GPL get to dictate requirements for extensions code that is possibly neither derivative or under GPL itself?

And there is no “right” answer here, only madness and endless holy war. :slight_smile:

I am really curious how Discourse will treat extension licensing, given “non-zealot” intentions and more API-centric design.

3 Likes
41

I believe GPL is a good choice, but one has to be aware that GPL v2 is incompatible with with some open source licenses, particularly Apache Public License (APL) v2. This means distributing GPL2-licensed code (such as Drupal) with APL2-licensed code (such as Twitter Bootstrap) is a pain. There’s more info on Github about this particular case.

The easy solution? Release under GPL3, which is compatible with APL2. (Wordpress is released under GPL2 or later, so you’re not really leaving WP path by releasing under GPL3)

1 Like
42

The GPL “loophole,” as Stallman calls it, has allowed companies like Google to run modified Linux kernels w/out distributing source. It isn’t clear to me if sending JS, HTML, CSS over the wire to the client constitues “distribution” in GPL2 terms. If not, then modifications of the code can be made when running in a hosted environment w/out providing changes.

I think it is fair to ask how Discourse as a company will interpret this. Is the intention to require source from anyone who runs a modified Discourse on their own servers, because the JS/HTML/CSS/Images, etc. are being redistributed?

1 Like
43

No, it is definitely not our intent to require source from anyone who runs a modified Discourse on their servers without distributing the code in public. That would be AGPL, we don’t use AGPL. I think that’s a crazy thing to ask of people and totally unenforceable even if you did.

2 Likes