Licence violations and incompatibilities

[Mac_Fife]

JWPlatt: I know that the GNU GPL is seen as the "open source license" but it tries to enforce freedom upon us in such a way that it's actually restricting our freedom at this point.

I don't really want to speak too much on behalf of Tony or Chogon on this but I know that one of Cyan's big concerns about any open source license was limiting the potential for a third party to exploit the code for commercial gain, and while GPL permits users to sell the product, the copyleft inherited requirement to always make sources available means that any commercial use becomes unattractive. So, a degree of restriction was intentional, although not necessarily intended to be overly restrictive on the fan developers at large. Cyan wanted to gift the code to the fans, not to another company.

I guess if a decent case can be made for another license that achieves the same overall objective then it'd probably get consideration, but I suspect that exceptions to the GPL is likely going to look a lot more appealing to Cyan and quicker to implement.

[JWPlatt]

Right, and exactly what I was thinking to add. Thanks.

[Stucuk]

I never understand why people can't just use simple licenses which only cover the file that they are written into. Something like ZLib but which prevents commercial use unless the software its used in is also open source and has references to "Software" replaced by "File".

I.E

Code: Select all

Copyright (C) 2011 John Smith

  This software is provided 'as-is', without any express or implied
  warranty.  In no event will the authors be held liable for any damages
  arising from the use of this file.

  Permission is granted to anyone to use this file for any purpose,
  including commercial applications, and to alter it and redistribute it
  freely, subject to the following restrictions:

  1. The origin of this file must not be misrepresented; you must not
     claim that you wrote the original file. If you use this file
     in a product, an acknowledgment in the product documentation would be
     appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
     misrepresented as being the original file.
  3. This notice may not be removed or altered from any source distribution.
  4. If used in a commercial application, that applications source code must
     be freely available.

[Skoader]

With the appropriate exception, I don't see a problem with the Max SDK.
Alongside PhysX and 3DS Max, we likely also require an exception for OpenSSL.

[Mac_Fife]

There are actually several licenses used that are incompatible with GPLv3, even beyond those three items. And OpenSSL actually needs two exceptions because both the OpenSSL license and the SSLeay (Eric Young's original license) are applied concurrently.

[Skoader]

Oh right, because they also impose additional restrictions. Is some kind of blanket exception an option?
I'll defer to those with more experience to get this sorted.

[Mac_Fife]

Is some kind of blanket exception an option?

I don't believe so (although getting definitive responses out of FSF is like drawing teeth, only harder ). The way the GPL and the boilerplate text for the exception is written, the copyright owner has to declare expressly which libraries he is happy to have linked to his code in the conveyable build, and the library name and applicable license have to be stated. In this case it could lead to a very "wordy" exception to cover all the bases.

There is a blanket exception already written into GPL but that only addresses "system libraries" and covered libraries that might reasonably be expected to be supplied as part of the host machine's operating system: In GPLv3 this definition was loosened up a bit to include libraries that are supplied with common programming languages.

[Glynn]

Is some kind of blanket exception an option?

I don't believe so (although getting definitive responses out of FSF is like drawing teeth, only harder).

The FSF doesn't have any say in the matter. It's up to the copyright holder as to how they license their work.

Not only do you need an exception from Cyan, you also need it from anyone who contributes code to the project. I would strongly suggest that you get contributors to explicitly permit some degree of re-licensing of their contributions. As it stands, you might be able to rely upon the act of contributing to a GPLv3 project as implying permission to distribute such contributions under the GPLv3 (although a lawyer would probably say "get it in writing"). You can't reasonably rely upon it as permission to distribute under some other licence, however similar.

If you want to contribute to a GNU project, you have to either assign ownership of the copyright to the FSF, or grant the FSF an unrestricted licence. This allows them to change the licence as they see fit, in the event that some aspect of the current licence turns out to be legally problematic.

If you only have a handful of contributors, you might be able to track down each one individually if you need to vary the licence. But eventually there will come a point where this is impractical, and you're either stuck with the original licence forever (as the Linux kernel is stuck with GPLv2), or you do what you can and hope no-one sues you. The latter option can be more problematic than it looks; if you ever need to get a lawyer involved, their first question will be whether you actually have the legal right to distribute the code, not whether you expect to get away with it.

[Mac_Fife]

The FSF doesn't have any say in the matter. It's up to the copyright holder as to how they license their work.

Agreed, but I think you misundertood what I was referring to: The FSF are the principal sponsors of the GPL, so they are supposed to be able to provide advice on the application of the License, clarification on interpretation of the text, etc., but they haven't been very good at doing that, and by way of "advice" tend to point you back to the ambiguous paragraph in the FAQ that you originally queried. I find it a bit unsatisfactory that the authors of a license are unable to explain it.

The only contributions that Cyan need to be concerned about getting contributor approval for relicensing are those that they have adopted into "their" version of the code, and Cyan know the authors concerned. For the unadopted contributions, the authors will have the option to reject the new version with new license and stick with the basic GPLv3 without exceptions, but they'll also be stuck with the inability to redistribute the final product, so that wouldn't be an approach that wouldn't make a lot of sense. Ultimately, although I'd think highly unlikely, Cyan could wind the clock back to day one and say "OK we're starting again with a revised license, with none of the fan contributions included".

[Stucuk]

Ultimately, although I'd think highly unlikely, Cyan could wind the clock back to day one and say "OK we're starting again with a revised license, with none of the fan contributions included".

Wouldn't that be the simplest solution. They don't need to change there internal code that they use to compile URU(They arn't using the version of URU they released to the public), they only need to change the version they release to the public. So modifying a few files of the original release with an updated license/etc would solve the problem as the community can re-integrate community changes.