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?
Addressing your concerns... (Score:1)
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 requi
Re:Addressing your concerns... (Score:1)
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.
Re:Addressing your concerns... (Score:1)
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 al
Re:Addressing your concerns... (Score:1)
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 goal