UseModCopyright

MeatballWiki | RecentChanges | Random Page | Indices | Categories

: 1. Preamble
: 2. Uncontested constraints
: 3. Proposed constraints
: 4. WikiAsSourceControlRepository constraints
: 5. Discussion

1. Preamble

In particular, the UseMod developer community is having a problem coming to an agreement over what the future copyright of the script will be. Right now, many people have stepped forward with a new version and new ideas for the future release of 2.0. Currently, SunirShah is writing a basic bench to incorporate all such ideas. This involves in part developing on a WikiAsSourceControlRepository.

For a general list of constraints, see UseMod:UseModWiki/FuturePlanning. This page is to discuss the list of constraints particular to choosing a new license. Since all the bench code is new, we can choose a new copyright license. The page is here, on MeatballWiki, because the problem of choosing copyright licenses is a very common one. Hopefully, after the discussion, we can generalize the salient points made to other cases. For instance, web servers have their own copyright licensing issues that are distinct from a normal user application. In the context of MeatBall, it seems that most of the software we will create will be server-oriented, so this will be relevant. Also, the WikiAsSourceControlRepository creates new copyright issues that haven't been considered before, and it seems particularly appropriate to discuss them here.

CategoryCopyright CategoryCase

2. Uncontested constraints

If you contest these constraints, do the wiki thing and move them down.

Above all, the license must be fair. Fair to the past, present, and future developers; fair to the site proprietors using the software; and fair to the end users of the software.

The license must encourage others to develop the software and contribute their changes to the commons.

The license must encourage (or not discourage) use of the software.

The license must enable and encourage others from using parts of the software in order to promulgate the ideas we've developed here.

The standard disclaimer: No patents, lawsuits, warranties, etc.

Most licenses, including the GeneralPublicLicense and the BSD license, do not require a web server to publish its source to its users, a la PublicScript.

Without a PublicScript, web users cannot directly acquire the source code to the web application they are using, making the application effectively closed source to them.

All the existing source code is already under the GeneralPublicLicense.

The license can only be changed if all developers agree.

While one can include BSD code in a GPLed application, it's not possible to include GPLed code in a BSD application.

Licenses are not exclusive; code may be licensed as many ways as the authors feel like.

The concept of FairUse of source code is unresolved and probably not worth applying.

Justification

I moved encouraging development above encouraging its use. The development is more important than the use because if the products are not well developed, they are not used widely too. Unix is an good instance. It is hard to use but easy to write a new program for it. -- TakuyaMurata Jan 3, 02

3. Proposed constraints

One thing I'd like to do is encourage the use of SoftSecurity throughout the web, and that means that I have to provide the technology to do this. Amongst open source projects, that's not too difficult if the license is GPLed, however the more troubling projects are commercial projects. Left to themselves, inexperienced and apathetic commercial developers will just recreate the same mistakes as the past. It would help the cause to provide code they can just incorporate without thinking about it, so I'd like the license to be less restrictive than the GPL, say on the order of the BSD. I personally would not even mind so much that what I write myself be under a BSD license and the rest be GPLed, as I could always just rewrite whatever I wanted to push. It would be a pain, but that would be fair. -- SunirShah

4. WikiAsSourceControlRepository constraints

I've separated thesed constraints away because no one is entirely sure of the constraints here as it's never been done before. The other constraints may be considered "conventional" in that they apply to a monolithic project, like the MozillaProject? or the JabberProject, but not necessarily to something as nimble as a WikiAsSourceControlRepository. -- SunirShah

It's unclear what the source code on the WikiAsSourceCodeRepository? is. It could be one of, more than one of, or something other than:
- Each resultant source file generated by the script generator.
- All resultant and interlocking source files generated by the script generator.
- Each page on the wiki.
- All the pages on the wiki taken as a whole.
- Each code snippet (noting there could be many on each page).

Multiple applications can use the same repository, each including wiki pages shared with others; in fact, this is the intent.

The script generator is not necessarily linear either; it will probably evolve to execute, while generating the source file, arbitrary code fragments that will serve to alter the final output. Think "server-side includes" a la PHP or ASP.

Because executing arbitrary code fragments is a gigantic security risk, and because development and testing of the script over the Internet is painful, it's probably important to allow developers to download the entire repository locally to play with.

At the very least, it's very likely that a configuration script will reconfigure the source line-by-line. This will go beyond the traditional idea of "configuration".

The public repository, especially with good configuration scripts, will hopefully encourage even very protective users to keep the version of the script they are using on the repository, thereby encouraging PublicScripts without demanding them.

Since the idea of what is "the source code" is unclear, it's difficult to determine if, say, BSD code is being included in an GPL application or GPL code is being included in a BSD application, as there is no one monolithic "application". There is only code.

A viral license like the GPL might imply that all the code in the repository conform to its licensing restrictions.

While it might be nice to allow different modules to have different copyright licenses, depending on the authors' wishes, that might also imply that an author may choose a very restrictive license. It seems reasonable then to require that all code conform to some license(s) before being posted.

A bad license choice will encourage forking instead of encouraging the use of the common repository.

One can always publish code in two places with different licenses for the difference places.

No matter what, all licenses must be compatible with the basic requirements of a wiki. cf. MeatballWikiCopyrightDiscussion.

5. Discussion

As you can tell, for me there are two major reasons for proposing to change the license. One is my personal NetWar on the cryptonauts, which you may or may not share. The second reason is that the GPL doesn't make much sense for a WikiAsSourceControlRepository because it didn't have such a creation in mind. -- SunirShah

I still fail to understand what protection the GPL gives you over a BSD-style license in the context of Perl and in the context of a web application. What about an LGPL-style license? -- SunirShah

As people and I say, GPL guarantee the GPL'd works last free of hack in the future. I don't think BSD can do that, can't it?. Some may think it is not a big deal, some care about it. -- TakuyaMurata

Since the script generator is a program, we might be able to solve the problem programmatically. Suppose we tagged each code snippet with licensing terms, like LicenseGPL and LicenseBSD. The script generator can then ensure that if the user wants to generate a GPLed script, she can include both license types, but she wants to generate only a BSD script, then the script generator will only permit BSD fragments. Then it becomes the code authors' discretion to place their code under a license they choose. While the BSD tree will be a smaller pool to pull from, it will still be there for GPL-allergic commercial interests to draw upon. If they want more functionality, this will also nudge them towards assimilating their codebase with the GPL, which I'm sure some of you might like. The drawbacks are extra complication, of course, but we could make the default GPL and BSD the exception. -- SunirShah

I relly like the idea that the script generator mixes GPL'd code and BSD code. -- TakuyaMurata

Moved from Uncontested Contrains:

Perl source is open by definition.

And also an answer to the related comment: "I still fail to understand what protection the GPL gives you over a BSD-style license in the context of Perl and in the context of a web application."

It depends on what you mean by "open". If you mean Perl source can always be viewed, then I agree. However, this isn't "open" as in "open source". Imagine that UseModWiki is covered solely a BSD-style license. A company can incorporate the code into their own product and releases it under a restrictive license. Let's also imagine that they make insanely cool modifications to the UseMod script. Sunir examines the modified Perl code and loves it. Too bad. Those modifications cannot be incorporated into the base UseMod script. Not only that, but because the Perl code is viewable but not reusable, if Sunir wants similiar features in UseMod, he will have to completely rewrite them without using any of the code he has examined. Furthermore, even if he is successful, the company may take exception to the fact that their powerful features have been made available for free. They many go so far as to sue Sunir for copyright infrigment, even if they don't have a particularly strong case:

: This for loop in UseMod is almost identical in structure to the one in our Ultra Wiki Solution Series. Clearly, your Honour, Mr. Shah has used our code to implement our features in his own script.

A copyleft license ensures that any and all modification and improvements made to the script are available for reincorporation into the original. Thus, I would recommend the LGPL over a BSD-style license. -- StephenGilbert