- Licensing Details
This summary is just to give a quick idea of the implications of this license. For the full details, please read this entire page.
When a converted application is compiled or executed, it comprises a combined work with the FWD project itself. This means that any distribution of or network access to the converted code (in binary or source code forms) outside of the organization triggers the copyleft provisions of the AGPL. This means that in this case, the converted application must be released as open source under the same AGPL license, since it is a combined work.
Golden Code provides an alternate license which allows your converted application to be distributed externally or shared over the network with external users, on a closed source basis. This is the so called dual-license.
Internal-only usage (over the network or otherwise) does not trigger the copyleft provisions, so the converted code does not have to be released under the AGPL when exclusively used for internal users only.
If you are an organization (e.g. a software vendor) that wants to ship your converted application to an external organization (e.g. a customer or supplier), you must release your converted application code under the AGPL OR obtain a dual-license from Golden Code.
If you are an organization that wants to provide hosted access to a converted application for users outside of your organization, you must release your converted application code under the AGPL OR obtain a dual-license from Golden Code.
Who Owns the Converted Code?¶
The short answer: whomever owned the copyrights before the conversion will own the copyrights to the converted version.
What Legal Rights Must My Organization Have to Convert an Application?¶
Running the FWD conversion process on a Progress ABL application's source code entails making a derivative work of that Progress ABL application. If the application in question is owned by a 3rd party, the organization running conversion must be an agent or contractor of that 3rd party OR it must have a source license which provides unrestricted rights to create derivative works. If the organization is the originator of the source or otherwise owns the source of the application, then no further rights are required.
What is a Covered Work?¶
The Java converted code requires the FWD classes to be present for compilation and for all execution. This means that the converted Java code is statically linking to the AGPL FWD code. Static linking combines the two pieces of code into a larger covered work which is collectively subject to the AGPL.
The author of the GPL and AGPL licenses is the Free Software Foundation (FSF). The following details are excerpts of their guidance about the GPL and AGPL. The two are equivalent for all purposes except that the AGPL triggers the distribution reciprocity requirement when the combined work is accessed over the network by people outside of the organization. Any references to GPL below can be read as AGPL.
Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
If I add a module to a GPL-covered program, do I have to use the GPL as the license for my module?
The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the GPL.
If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the software as it is actually run includes the library.
Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions.
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
The following clarifications in regard to the Lesser GPL (LGPL) and Java are instructive:
It has always been the FSF's position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed as a whole under the terms of the GPL, an effect which can be described as “hereditary.” So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL.
The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library.
Inheritance creates derivative works in the same way as traditional linking
You cannot incorporate GPL-covered software in a proprietary system. The goal of the GPL is to grant everyone the freedom to copy, redistribute, understand, and modify a program. If you could incorporate GPL-covered software into a non-free system, it would have the effect of making the GPL-covered software non-free too.
A system incorporating a GPL-covered program is an extended version of that program. The GPL says that any extended version of the program must be released under the GPL if it is released at all. This is for two reasons: to make sure that users who get the software get the freedom they should have, and to encourage people to give back improvements that they make.
I'd like to incorporate GPL-covered software in my proprietary system. Can I do this by putting a 'wrapper' module, under a GPL-compatible lax permissive license (such as the X11 license) in between the GPL-covered part and the proprietary part?
No. The X11 license is compatible with the GPL, so you can add a module to the GPL-covered program and put it under the X11 license. But if you were to incorporate them both in a larger program, that whole would include the GPL-covered part, so it would have to be licensed as a whole under the GNU GPL.
The fact that proprietary module A communicates with GPL-covered module C only through X11-licensed module B is legally irrelevant; what matters is the fact that module C is included in the whole.
Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPL'ed class.
Users of the FWD open source project who wish to distribute their converted application or host it for network access by those outside their organization will not be able to use FWD's default, reciprocal (copyleft) AGPL license, without also releasing their application source code under the same license.
For those who wish keep their converted applications closed source, Golden Code Development offers a dual licensing model for the FWD technology. A source and distribution license is available for purchase at a reasonable cost, allowing you to keep your application code proprietary, while having full rights to modify and distribute the FWD source code and binaries.
FWD License Notice¶
Each source file in the FWD project must contain the following license notice:
/* ** This program is free software: you can redistribute it and/or modify ** it under the terms of the GNU Affero General Public License as ** published by the Free Software Foundation, either version 3 of the ** License, or (at your option) any later version. ** ** This program is distributed in the hope that it will be useful, ** but WITHOUT ANY WARRANTY; without even the implied warranty of ** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ** GNU Affero General Public License for more details. ** ** You may find a copy of the GNU Affero GPL version 3 at the following ** location: https://www.gnu.org/licenses/agpl-3.0.en.html ** ** Additional terms under GNU Affero GPL version 3 section 7: ** ** Under Section 7 of the GNU Affero GPL version 3, the following additional ** terms apply to the works covered under the License. These additional terms ** are non-permissive additional terms allowed under Section 7 of the GNU ** Affero GPL version 3 and may not be removed by you. ** ** 0. Attribution Requirement. ** ** You must preserve all legal notices or author attributions in the covered ** work or Appropriate Legal Notices displayed by works containing the covered ** work. You may not remove from the covered work any author or developer ** credit already included within the covered work. ** ** 1. No License To Use Trademarks. ** ** This license does not grant any license or rights to use the trademarks ** Golden Code, FWD, any Golden Code or FWD logo, or any other trademarks ** of Golden Code Development Corporation. You are not authorized to use the ** name Golden Code, FWD, or the names of any author or contributor, for ** publicity purposes without written authorization. ** ** 2. No Misrepresentation of Affiliation. ** ** You may not represent yourself as Golden Code Development Corporation or FWD. ** ** You may not represent yourself for publicity purposes as associated with ** Golden Code Development Corporation, FWD, or any author or contributor to ** the covered work, without written authorization. ** ** 3. No Misrepresentation of Source or Origin. ** ** You may not represent the covered work as solely your work. All modified ** versions of the covered work must be marked in a reasonable way to make it ** clear that the modified work is not originating from Golden Code Development ** Corporation or FWD. All modified versions must contain the notices of ** attribution required in this license. */
AGPL 3.0 Full License Text¶
3rd Party Dependencies¶
The FWD project depends on many 3rd party technologies. Please see the Software Dependencies for details.
© 2004-2017 Golden Code Development Corporation. ALL RIGHTS RESERVED.