Slashdot Mirror


"New Copyleft License" released

Stephen Williams writes "LinuxToday reports that Bowerbird Computing have released a new open source license called the New Copyleft License. Seems to be aimed at people who want to sell their free software, rather than charge for support." At the rate these licenses are proliferating, soon there will be one license for every app. Does anyone besides me think this is getting crazy?

6 of 222 comments (clear)

  1. About time for a modular license? by Gid1 · · Score: 4

    How about a web site which gives you a tick-box based license generator:

    * You'd select what you want to limit/allow

    * It'd read it back to you in
    a) Formal license form (text file)
    b) English, with warnings (eg. "You're forcing people to release their own source code here")
    c) A Geek-code style shorthand

    Then, any savvy user could take one glance at the Geek code and understand the restrictions.

    "This software is licensed according to the Open Source Modular License (URL here) with the following stipulations to be interpreted as described by the license:

    FREE++ SRC- DIST+ COPY+++ ..."

    Comments?

  2. commercial GPL? by earlytime · · Score: 3

    Maybe what us free software advocates need to do is draft a shell licence for commercial software companies. If you look at their "open source" licences, they're all basically the same. We seem to have problems with the portions of thier licences that we feel funnels the benefits of the open source model to "the company" exclusively. They seem to believe that they've created an open source license that protects their IP from becoming public domain, and from the threat of cloners. Maybe we can create a license model that satisfies both requirements.
    Essentially, they want to maintain the ownership of their "open" code, and we want to maintain the freedom of the improvements that result from the opening of that code. I think that's the issue that ESR, and BP and the other "champions of open source" ;) should be working on, not trying to get a bunch of commercial software companies to dilute the free software with a bunch of "not-so-free" software. The GPL is great for new software that has no real original owner and no need for IP protection. For commercial SW companies, it not just gives away the code (a good thing), but it gives others the right to burn it to CD and sell it as is (a bad thing). -earl

    --

  3. License Proliferation by Raindog · · Score: 3

    This simply goes back to one of the fundemental problems the Linux/open source/free software movement faces...in involvement of comercial organizations or not. Most commercial entities will not go for the GPL, yet have valuable contributions to make. On the other hand, this license proliferation is just mucking the whole thing up, and licenses like the BSD license allow the code to be exploited too easily without return to the community. IMHO, we need to have just three licenses, the GPL, LGPL, and a third one which will make commercial entities more cofortable yet still enable it to work with GPL software and its devotes...something like a NQFPL (not quite free public license). make no pretense to be compelety free, but yet still works with the movement. In the NCL license defense, I think the two year expiration period is a decent idea...but, simply put, we have too freeking many licenses running around, their going to become meaningless soon. Perhaps dialogue on a third license of non-commercial origin, but with commercial entites in mind, could be developed. I would love to see FSF and OSI involved in this...an attempt to build consensus.

  4. The Problem with Direct Revenue-Capture Licensing by Bruce+Perens · · Score: 3
    (Here's a better-formatted version of my previous post)

    This license and others like it can be classsified as "Mandiatory Direct Revenue-Capture for the Initial Developer."

    It disregards the role of the unpaid collaborator who would add features to your program, because the initial developer has an advantage that the unpaid collaborator can neither obtain nor circumvent. This is a disincentive to the unpaid collaborator because instead of contributing work to the community they are now contributing work that someone else will be paid for no matter what they do. Contrast this to indirect revenue methods. If I don't like Red Hat, I can circumvent them and make my own Linux distribution, obtaining what would have been their profit for myself for some (possibly small) number of customers. Consider this in the case of a product like Linux, where the initial developer contributed a small amount of the total work and his services as an architect and coordinator, while the lion's share of the work was done by others.

    It makes collaborative development unwieldy. If every developer insists on their own revenue capture, you would soon have a too-expensive product or a paperwork and procedural mess. Who decides how much each developer gets? Who decides who is worthy as a developer? Do they all make that decision for themselves and then compete with each other in some way?

    It gives the initial developer a lock that causes a disincentive to "fork" a product. If Linus had direct revenue-capture from Linux and I decided to make a fork of it because I felt I could engineer it better, I might be able to do an excellent job, but Linus would still be compensated for my effort.

    So, to sum it up, I think that direct revenue capture works to the detriment of collaboration.

    Thanks

    Bruce Perens

  5. Licensing FAQ by Bruce+Perens · · Score: 3
    The end of my O'Reilly chapter includes a licensing FAQ. Read it here.

    Thanks

    Bruce

  6. The Problem with Direct Revenue-Capture Licensing by mettw · · Score: 3


    > This license and others like it can >be classsified as "Mandiatory Direct >Revenue-Capture for the
    > Initial Developer."

    > It disregards the role of the unpaid >collaborator who would add features to your >program, because the
    > initial developer has an advantage >that the unpaid collaborator can neither obtain >nor circumvent.
    > This is a disincentive to the unpaid >collaborator because instead of contributing work >to the
    > community they are now contributing >work that someone else will be paid for no matter >what they
    > do.

    Bruce, you should have read my license before opening your mouth. It makes it quite clear in the definitions section that an "Author" is anyone who contributes code to the project. Under the stewardship section it then specifies that each author has just a single vote, regardless of contribution. So even if Linux were licensed under the NCL, Linus would have no special rights under it.

    > It makes collaborative development >unwieldy. If every developer insists on their own >revenue
    > capture, you would soon have a >too-expensive product or a paperwork and >procedural mess. Who
    > decides how much each developer >gets?

    Again, as a leader in the free software community you have the responsibility to actually *read the entire license*, rather than just rely on the quickly written preamble. All of these decissions rest in the hands of the steward of the work who is elected by the the authors, each with one vote.

    >So, to sum it up, I think that direct revenue >capture works to the detriment of collaboration.

    I understand your fears about collaboration and free reuse of code, that is the sole reason I included the stewardship system in the license. Without a guarantee of these freedoms the license couldn't be called free. I believe that this license will protect these freedoms, although only experience will tell.

    I didn't write the license out of some kind of selfish grab for money at the expense of the freedoms of others. I wrote it because:

    1) The free software community is bigger than the FSF, yet they are the only beneficiaries of any donations from people like Cheapbytes. The distribution of reward should be more even throughout the community.

    2) There are a great many programmes that just do not lend themselves to offering consultancy services. How do you offer consulting for a game, or a genealogical programme? Home users will never purchase consulting services, so the only way to make money in this environment is to sell the software. My intention in this respect is to provide some motivation for programmers to write these sort of programmes professionally.

    As I said, only experience will show if the license works properly, but I believe that it is atleast worth a try. The GNU GPL itself was a radical idea at the time, so I don't see how a supporter of it can then turn around and refuse to even support a trial of a license that contains a new idea.

    Matthew Parry
    Bowerbird Computing.