Suppose there's a free software project. Suppose it's useful and popular. People use it. People like it.
Suppose there's a vendor of competing proprietary software. Suppose that vendor wants more customers, or at least fewer non-customers.
Now the license of the project is important. Can the vendor take and modify and redistribute a modified version of the project? Probably -- but the license of the project is important.
Suppose the license is really free and really generous and the vendor can do pretty much anything it likes with the project. It can distribute it unmodified. It can modify it. It can redistribute the modifications. It can redistribute a modified version under a more restrictive license, including a license that prevents modification, reverse engineering, and further redistribution. It can even rename the software so that no one will ever know it came from the original project or forbid the use of the original project in conjunction with the modified vendor version.
Suppose instead the license is a copyleft license. The vendor then, if it redistributes the project or a modified version, must pass distribute the project or the modified version under copyleft terms. That is, the project is just as free for people who get it from the vendor as it is for people who get it from the originators. Any modifications the vendor makes have the potential to be public knowledge.
Finally, suppose that the project itself is a copylefted version of an upstream project with a very generous license as in the first case. If the vendor wants to avoid its obligations for redistribution in the copyleft case, which version do you think the vendor will use?
Pugs took many such libraries, make modification to them, and write new code to work with them.
They are all in the directory of src/, which contains nothing but Haskell code, C code, and some Perl 6 that binds to them in Pugs::Internals::* package.
We took all those Haskell libraries from Haskell people and work with them, but we could never give them back. Because none of the authors is willing to accept patches that require them to adopt copyleft.
I am very uncomfortable with this takes-and-never-gives-back situation. I wish that the research contributions we made can be used by the programming language research community. A copyleft license prevents that.
I agree with your industrial concerns for TPF-Perl6, but the research concerns is valid as well. The current solution, the one Allison and I both support, is to make the "lambda" part MIT licensed, and the "camel" part copylefted.
That is, all the Perl 6 code reusable across implementations that exists outside Pugs's src/, such as lib.pm and Test.pm, will stay copylefted.
So, yes, P# may be based on a non-self-hosting, Haskell-based implementation of a Perl 6 prototype, shipped with another set of standard libraries.
I don't see why Microsoft will want do that, really, and I think it's not sufficient reason to deter us from sharing with the programming-language research community.
Re:Addressing your concerns...
chromatic on 2006-04-25T18:27:04
I don't see why Microsoft will want do that, really, and I think it's not sufficient reason to deter us from sharing with the programming-language research community.Even laying outside the question of risk (which is TPF's question to answer), I'm not sure it's even a good driver for the decision.
We took all those Haskell libraries from Haskell people and work with them, but we could never give them back. Because none of the authors is willing to accept patches that require them to adopt copyleft.If you write a piece of code, you hold the copyright and you can distribute it under any license you choose. What prevents you from patching a public domain Haskell library, distributing the modified version under a copylefted license with Pugs, and sending that patch upstream under the code's original license?
I can understand that this may not be immediately obvious to contributors, but if you make it clear that you prefer to the project to work this way, I think they will understand the principle of share-and-share-alike, if not the point that working with upstream is much easier than maintaining an effective fork in practice, if not in principle.
Perhaps a better question is "Is the research the entire project as a whole, or is it individually identifiable pieces of the project?"
Re:Addressing your concerns...
audreyt on 2006-04-26T00:13:30
Yes, theoretically we can use a file-by-file way to maintain separate BSD2- or MIT-licensed files, and collect commits and license those commits one way and send them back in another way.Logistically, I don't think that's going to fly. Also note that this not only covers patches, but new extension modules that build on and enhances with upstream ones. For the upstream to consider adopting or reusing these, it also needs to be non-copyleft.
So, yes, I do think it's practically much easier to consider all of src/ as research, rather than considering each new commit or new file in a case-by-case basis.
Re:Addressing your concerns...
chromatic on 2006-04-26T07:08:41
I'm sympathetic to the logistics argument; I certainly am not volunteering to manage such a system.
(I do remain somewhat dubious about any given academic community explicitly seeking out new research from a community known mostly, however unfairly, for inacademic practicality. I find too many research groups largely insular. Yet bringing these groups closer together is a noble goal. I just want to make sure that the people involved have considered the implications.)
As I said before, knowing your goals (certainly much better now) and having brought up the possible alternatives, I can live with a BSD or MIT license on Pugs src/.
