Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

  (email not shown publicly)

Blog Information [] Profile for chr0matic []

Journal of chromatic (983)

Tuesday April 25, 2006
10:37 AM

Why Copyleft (Why Not P#)

[ #29443 ]

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?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Almost all the Haskell people release their libraries in non-copyleft licenses.

    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

    • 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.

      • 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 al

        • 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