![]() ![]() Section 4(c)(ii) is what we call the "relicensing" clause. Under Section 4(c)(i), you can make any changes you want if you release your changes under the Artistic License. This requirement goes back to the idea of artistic control. Don't call it Perl, and don't make it so your users can't use the real Perl on the same machine. Under Section 4(b), you can release a proprietary version of the Perl source code, but if you do, don't pretend your code is the real Perl. Under Section 4(a), you can make any changes you want if you contribute them back under the Artistic License. For instance, you might include a comment in each changed file, or beside each change in the code. However, there are other ways to meet the requirements. In general, we expect that you would do this using a file in the top-level of the distribution noting what's changed and that you will update the documentation anywhere your code works differently from what the documentation says (you would probably want to do this anyway, so the documentation isn't misleading). Whatever option you choose, you must let people know that you've changed the code. Section 4:You have a few different options if you want to change the code and redistribute it. ![]() Section 3:Fixing a few bugs, tweaking the code to run on your operating system, or applying a security patch from the development mailing list doesn't mean you've created a "Modified Version". You can't charge a licensing fee for it, but you can charge for distributing it or for providing support. Section 2:You can redistribute unchanged versions of the Perl source code. ![]() ![]() The rest of the license does not come into play unless you want to make Perl available to others, in a standard or modified version. This section applies to using Perl yourself "as is", or changing it but only using the changed version yourself or inside your organization. If you distribute a package under the Artistic License 2.0, and want to take advantage of "bug fixes" in version 2.1, you have to include the new version of the license in the package. It also lets the users know that TPF might update the license in the future, and that developers who have distributed under one version of the license can always upgrade to another. The "original license" identifies the license that the developer used to distribute their code. We found ourselves repeating "the version of the Artistic License that ships with the Standard Version" far too many times through the license, so we decided to define it in one place. To make the comments easier to follow, we use Perl as an example in these notes. We hope they will help you understand how to use the new license. These notes are based on comments and questions that came up as we worked on this revision. But, because legal documents are code, our drafting choices are based on a need to capture a particular legal meaning. Readability and maintainability are just as important in legal code as they are in software. You'll see a lot of spaghetti legal code out there, lengthy and obtuse, but it doesn't have to be like that. Legal documents can be considered as just another form of code. In some cases we made the language more general so the license may fit better with past and future changes in technology. In some cases we expanded it to make it more legally specific. The goal of the Artistic 2.0 revision is to make the terms of the original Artistic License clearer and more readable. (The heart of the Artistic license is the idea that artists, people who create things, should be able to have ongoing artistic involvement in their work. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |