We are talking about two sets of issues here. One is the clarity and implications of the Squeak license. The other is the specific licensing terms of various specific contributions, and further, whether those contributions were legally made.
Right, as to the first, I suppose we are in agreement there is no issue. As to the second, I'm alive to this. This is a difficulty of all open source software to some extent. Oddly enough, it hasn't stopped the GNU/Linux movement, or the wide and pervasive deployment of its software, even in major corporations.
As to your questions about the licensing status of components, I respectfully reiterate my prior disagreement. A careful reading of the license and its viral nature does not limit it, notwithstanding the express naming of Apple.
Another license issue is when using Squeak specifically for embedded work. In this case it is not completely clear where the VM boundaries begins and ends -- so if you link code into the VM to call MP3 audio compression/decompression routines, does this mean you need to also release a huge body of work that does MP3 functions? I don't know for sure. The safe answer is "yes".
If you say so. This has to be answered on a case by case basis. The addition of stand-alone pluggable primitive modules resolves almost all potential issues in this regard.
The least risky course of action seems to me to be to go back to the original Apple Squeak, modularize it, and then have each and every contribution accompanied by a statement of orginality similar in spirit to that Python uses.
With all due respect to the interesting issues raised by Paul, I think they raise no barrier to use that I can see for most circumstances, but his mileage may vary.
IMHO, going back to the "original Apple Squeak" for "recertification" would be an extraordinary waste of time. I, for one, am not fond of the notion of a centralized Pythonesque repository, which is most clearly the exception rather than the rule.
If you wish to resolve these issues, gather up the sources of all the changesets. Despite thousands of them, there are probably under a hundred contributers, and see if you can get e-mail ratification of whatever legal documents you may require.
While I don't think it is necessary at all, I don't think it would be a bad idea to have an express statement along the lines of "distributed under Squeak-L" expressly or impliedly as a matter of course, or for Disney to insist that all contributions it includes embrace an express
I don't think Squeak can grow beyond a research toy without grappling and resolving these issues as a community at some point.
It already has for others. Perhaps not for Paul.
The problems raised by Paul do not impede broad deployment and commercial exploitation of Berkeley or GPL, and related software in proprietary form, though the same issues (except for his license interpretation points and concern about the definition of "over the line" and "under the line" of the VM) occur everywhere else.
Despite contributions from folks all over the world in a zillion different places, few would try to argue that the present versions of gcc, BIND, sendmail or dhclient (or the products built around or incorporating them) are "research toys."
As I noted, specific requirements may differ from company to company and application to application -- if you have questions, rely on a lawyer you have retained to apply the particular facts to the applicable law. In the meanwhile, while I'm not seriously troubled by the issues Paul raises, and don't share his conclusions at all, I think there are some hygiene issues far short of the proposed Pythonesque cetification process that will do quite well.
Andrew-
Thanks for the great reply.
"Andrew C. Greenberg" wrote:
We are talking about two sets of issues here. One is the clarity and implications of the Squeak license. The other is the specific licensing terms of various specific contributions, and further, whether those contributions were legally made.
Right, as to the first, I suppose we are in agreement there is no issue. As to the second, I'm alive to this. This is a difficulty of all open source software to some extent. Oddly enough, it hasn't stopped the GNU/Linux movement, or the wide and pervasive deployment of its software, even in major corporations.
There are several reasons for this.
The legal exposure of a company using something like Perl of Linux or send-mail in-house is not nearly as great as if they redistribute it. When I consider personally hosting or using a Squeak for business, redistribution needs would seem to require a higher legal standard.
If I am just shipping out Perl scripts and tell people to download Perl, I am at worst "inducing" people to infringe, and then I am only one among tens of thousands.
A license like the GPL for much of the core of Linux makes the intent for distribution of modified versions of that core much clearer. That is, the company an employee works for will have a tougher time later saying in court, "well we meant our changes to the GPL code to be always proprietary" while at the same time saying "we also intended also to distribute the code not under the GPL". Note it is quite OK to make proprietary changes to GPL code as long as you don't intend on distributing the code or binaries, as an ISP might do (and is now an issue in discussions of revising GPL loopholes).
With Squeak, it is quite conceivable a company might say that they did not ever intend for a package built on Squeak to be given away without a proprietary license, thus increasing the need for clarity in licensing statements when employees "donate" code.
Also, the GNU project for example is trying to uphold the highest level of legality regarding contributions to their own code base, especially regarding GCC.
Look for example at:
http://www.gnu.org/prep/standards_4.html#SEC4 : Accepting Contributions : : If the program you are working on is copyrighted by the Free Software : Foundation, then when someone else sends you a piece of code to add : to the program, we need legal papers to use it -- just as we asked : you to sign papers initially. Each person who makes a nontrivial : contribution to a program must sign some sort of legal papers : in order for us to have clear title to the program; : the main author alone is not enough.
Or:
http://www.gnu.org/prep/standards_3.html#SEC3 : Referring to Proprietary Programs : : Don't in any circumstances refer to Unix source code for : or during your work on GNU! (Or to any other : proprietary programs.) : : If you have a vague recollection of the internals of a Unix program, : this does not absolutely mean you : can't write an imitation of it, but do try to organize the imitation : internally along different lines, because : this is likely to make the details of the Unix version : irrelevant and dissimilar to your results.
You also wrote:
As to your questions about the licensing status of components, I respectfully reiterate my prior disagreement. A careful reading of the license and its viral nature does not limit it, notwithstanding the express naming of Apple.
If that is the case, the issue specifically is the creation of additional classes which the license explicitly says it does not cover. In these classes, a clear statement of IP ownership and license would be required (even if just saying it is under a Squeak-like license).
Note however, that the Apple license says: http://www.squeak.org/license.html : You may distribute and sublicense such Modified : Software only under the terms of a valid, binding license : that makes no representations or warranties on : behalf of Apple, and is no less protective of Apple and : Apple's rights than this License.
So, you still need a license. Further if you do say it is under a "Squeak License" does this really effectively disclaim your own warranties? I guess it would hinge on whether the author of a Squeak enhancement was considered one of "Apple's licensor(s)" which I don't know of as the case. Somehow, I don't think so. Maybe someone could clarify "Licensor" as opposed to "Licensee". I read Licensor as other people who owned IP who Apple has the right to use -- like Xerox. Maybe I am wrong.
In the GPL, the warranty is broader to simply say all the software comes with no warranty, not that a specific company does not warranty anything. http://www.gnu.org/copyleft/gpl.html : BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, : THERE IS NO WARRANTY FOR THE PROGRAM,
Another license issue is when using Squeak specifically for embedded work. In this case it is not completely clear where the VM boundaries begins and ends -- so if you link code into the VM to call MP3 audio compression/decompression routines, does this mean you need to also release a huge body of work that does MP3 functions? I don't know for sure. The safe answer is "yes".
If you say so. This has to be answered on a case by case basis. The addition of stand-alone pluggable primitive modules resolves almost all potential issues in this regard.
Good point. Pluggable primitives do improve things a great deal. However, in an embedded system where everything might be put in the same ROM, or loaded from the same compiled binary file, pluggability is not quite as clean a distinction as it might otherwise be on a desktop application.
The least risky course of action seems to me to be to go back to the original Apple Squeak, modularize it, and then have each and every contribution accompanied by a statement of orginality similar in spirit to that Python uses.
With all due respect to the interesting issues raised by Paul, I think they raise no barrier to use that I can see for most circumstances, but his mileage may vary.
IMHO, going back to the "original Apple Squeak" for "recertification" would be an extraordinary waste of time. I, for one, am not fond of the notion of a centralized Pythonesque repository, which is most clearly the exception rather than the rule.
I certainly am not eager to do it. Squeak 2.7 is quite stable and nice.
If you wish to resolve these issues, gather up the sources of all the changesets. Despite thousands of them, there are probably under a hundred contributers, and see if you can get e-mail ratification of whatever legal documents you may require.
Good suggestion as a way to proceed.
While I don't think it is necessary at all, I don't think it would be a bad idea to have an express statement along the lines of "distributed under Squeak-L" expressly or impliedly as a matter of course, or for Disney to insist that all contributions it includes embrace an express
I'm almost surprised Disney lawyers haven't already requested it. It was the CNRI lawyers who got Guido doing it for Python.
I don't think Squeak can grow beyond a research toy without grappling and resolving these issues as a community at some point.
It already has for others. Perhaps not for Paul.
Actually I've used Squeak in a capacity for which I was paid a few times. Mostly it was as a utility to accomplish a specific task. In one case it was for a prototype that was never "distributed".
The problems raised by Paul do not impede broad deployment and commercial exploitation of Berkeley or GPL, and related software in proprietary form, though the same issues (except for his license interpretation points and concern about the definition of "over the line" and "under the line" of the VM) occur everywhere else.
Despite contributions from folks all over the world in a zillion different places, few would try to argue that the present versions of gcc, BIND, sendmail or dhclient (or the products built around or incorporating them) are "research toys."
Again, see the above. There may be a lot of behinds the scenes work making these projects legally coherent that may not obvious to the end user.
As I noted, specific requirements may differ from company to company and application to application -- if you have questions, rely on a lawyer you have retained to apply the particular facts to the applicable law. In the meanwhile, while I'm not seriously troubled by the issues Paul raises, and don't share his conclusions at all, I think there are some hygiene issues far short of the proposed Pythonesque cetification process that will do quite well.
Good compromise.
Andrew C. Greenberg acg@netwolves.com V.P. Eng., R&D, 813.885.2779 (office) NetWolves Corporation 813.885.2380 (facsimile) www.netwolves.com
Please use werdna@mucow.com instead of werdna@gate.net
Thanks again for the reply. I appreciate your "pro bono" comments as coming from one of the best legal authorities on the Squeak license. It's all new ground and we're all learning as we go -- I guess I learn by trying to write up what I think I know.
Disclaimer: I am not a lawyer, so see a lawyer who understands your circumstances and how the law applies to them.
Someday, I hope software developers will be like lawyers, and paid as well. That is, all the code will be "free" in code libraries, and people will pay you to apply it to their specific situation. :-)
Although then, maybe programmers will have to go to the equivalent of "law school" and pay as much to enter the profession. :-(
-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com
squeak-dev@lists.squeakfoundation.org
-
Andrew C. Greenberg -
Paul Fernhout