No, the moral is keep your tools up to date, fix your code where necessary and talk to the maintainers when you run into difficulty. Sniping from the sidelines and actively encouraging people to modify the toolchain installation is childish & unhelpful. Please stop.
I really shouldn't bother but can you please explain how this isn't user hostile behavior? It's very very common for homebrew developers to leave the scene and not be willing (or even able) to update older tools of theirs, and it's incredibly infeasible to suggest that other people need to pick up this slack simply because you are unwilling to provide archived versions of older tools.
The following page does not go into great detail about devkitPro's products and their relationship with the GPL. Probably the most notable line is this:
https://devkitpro.org/wiki/Trademarks#Trademarks_and_the_GPL
Please note that we do not supply old binaries or source for old binaries and you may not distribute GPL binaries without corresponding source code.
The official binaries for devkitPPC and other tools appear to be distributed currently is through the
official pacman repo.
I can receive a binaries of these tools, distributed by devkitPro, using pacman with that repo. Licensing information for devkitPPC can be displayed by running "dkp-pacman -Q --info devkitPPC", which returns the following:
Code:
Name : devkitPPC
Version : r33-1
Description : Toolchain for Nintendo Gamecube & Wii homebrew development
Architecture : any
URL : https://devkitpro.org
Licenses : GPL
Here it just states broadly that "GPL" license applies to these tools. Inspecting the files that this package installs, it provides the following file at
"/opt/devkitpro/devkitPPC/share/info/gcc.info", which contains the entire GPLv3 license, as well as a reference to the
https://github.com/devkitPro/buildscripts/ repo for a place to report bugs and issues with the software.
Within GPLv3 is the following clause for distributing non-source forms (such as the binaries I installed via pacman from the devkitPPC package):
Code:
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this
License, in one of these ways:
a. Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b. Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that
product model, to give anyone who possesses the object code
either (1) a copy of the Corresponding Source for all the
software in the product that is covered by this License, on a
durable physical medium customarily used for software
interchange, for a price no more than your reasonable cost of
physically performing this conveying of source, or (2) access
to copy the Corresponding Source from a network server at no
charge.
c. Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially,
and only if you received the object code with such an offer,
in accord with subsection 6b.
d. Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to
the Corresponding Source in the same way through the same
place at no further charge. You need not require recipients
to copy the Corresponding Source along with the object code.
If the place to copy the object code is a network server, the
Corresponding Source may be on a different server (operated by
you or a third party) that supports equivalent copying
facilities, provided you maintain clear directions next to the
object code saying where to find the Corresponding Source.
Regardless of what server hosts the Corresponding Source, you
remain obligated to ensure that it is available for as long as
needed to satisfy these requirements.
e. Convey the object code using peer-to-peer transmission,
provided you inform other peers where the object code and
Corresponding Source of the work are being offered to the
general public at no charge under subsection 6d.
(a) has not been satisfied, as I have just installed the object code and no corresponding source code accompanied it.
(b) to my knowledge has not been satisfied, as I have not received nor seen such a written offer.
(c) only applies to someone else passing on the object code in the case where a written offer was provided by someone in (b).
(d) to my knowledge has not been satisfied. I am not aware of a location or server where I can receive this source code.
(e) does not apply, I received the object code as a download via the public repository not peer to peer.
Only one of these 5 subclauses needs to be satisfied, since I have received a non-source distribution of code, which I believe leaves only (b) and (d), as (a) and (e) were not satisfied, and (c) does not apply.
In order to satisfy (b), the ability to receive source code from up to 3 years of the non-source distribution needs to be present.
This is true even if you are no longer provided support for that version. Will you publish and release the source code to those of use who received and currently possess the GPLv3-licensed product from devkitPro for within the past 3 years and including the present? It sounds like you're asking that these redistributions be removed, despite the fact that if they were provided the source, they could provide the binaries verbatim under (c).
In order to satisfy (d), there would need to be a location or server to retrieve the source code of the GPLv3-licensed devkitPro products. Users would be completely free to cache this source code of course and continue to build and distribute binaries+source of older versions without using or violating your trademark. In addition to this "you maintain clear directions next to the object code saying where to find the Corresponding Source", which I have not been able to find.
Please, feel free to correct me if I'm wrong on anything I've said above.
It appears that the object code / product provided by devkitPro in the devkitPPC package is a fork of
https://gcc.gnu.org under the GPLv3 license. The GCC site is very clear and upfront about the licensing and in addition to that has a large history of changelogs and previous versions. I assume that your organization has benefited from their approach in making this very user-friendly and accessible. This is how I would expect a GPLv3 licensed project to behave, in order to maximize utility for users and developers.
Instead, the devkitPro organization does not seem to like to talk about the GPL or issues like this... The buildscripts repo on github (which is linked to in the same place where the contents of the GPLv3 are distributed) is copyrighted code that is provided with no license (except the explicit
permission to fork it that Github provides).
Upon being inquired about licensing of the build scripts:
https://github.com/devkitPro/buildscripts/issues/20
Okay, this is despite the fact that the buildscripts patch gcc (one such patch even
including a
snippet of the GPLv3 license), and despite the fact that patching a GPLv3 source creates a derivative work.
When this is pointed out on your forums:
https://devkitpro.org/viewtopic.php?f=15&t=8690
The response was "We don't supply binaries built with those buildscripts, there is no GPL issue.". The implication being that the buildscripts actually do not bear relation with the released products (such as devkitPPC) that devkitPro org provides. Which raises the question: where's the corresponding source for the binaries that you
do distribute, and that I and other users
have received?
And of course most recently as people in this thread have pointed out was this:
https://github.com/devkitPro/buildscripts/issues/29#issuecomment-406894916
Which is locked with the message "This conversation has been locked as too heated and limited to collaborators." despite there being a single and very polite message inquiring about building an older version of dkP products.
It is bewildering to me that you would even consider asking people to take down mirrors of your old binaries under the guise of GPLv3 because they aren't providing the source, when the source for the current (and soon to be past) GPLv3-derivative devkitPro non-source products is not clearly provided or supported at all. As if releasing a version magically invalidates the distributed (by you) binaries and your obligation to have provided the source code in the past (or present if we're talking bout r31-1).
And it's
particularly offensive given the history behind GCC and its role in the free software movement and the GNU Project.
Somehow I have more to say... this (outdated libs) is an
extremely common problem that the Wii U scene is facing, where older projects were not updated to work with newer devkitPPC releases, as well as newer devkitPPC breaking compatibility. When you were approached about these breaking changes, your official response was that that the Wii U is unsupported by the devkitPro organization. Whether you like it or not, the free compiler that you are modifying and distributing requires that you provide users the ability to maintain, modify, and build off your work
specifically because of situations like this.
In short, I would like to request a copy of the source code for devkitPPC and devkitA64 under the terms of the GPLv3 license which they are distributed under. Also under the GPLv3, there should be either three years worth of source code made available upon request (subclause 6b), or a public and well documented place to retrieve the source (subclause 6d).
