Re^13: Why non-core CPAN modules can't be used in large corporate environments.

The entirety of my 3 part question was in earnest.

Okay, sorry for doubting that. I've updated my post and tried to answer your questions to the best of my abilities.

I read the PAL similarly to you, albeit with the small difference that the author does not wish his code to be changed and redistributed without the changes being clearly marked (and the change made available, which is pretty much a noop for Perl anyway). I've always thought the PAL essentially asks the same things as the GPL, only it asks that the user complies, whereas the GPL demands it.

What you have done with your post is to provide ample reasons why I, as a former consultant architect, could never recommend that a client that they use any CPAN module, or maybe even perl itself on any commercial project.

WTF? I never said the things you apparently understood. Specifically I never said you need to contact every module author before using or integrating their code, nor need you respect their wishes further than what the license of the module clearly says (which permit integration into commercial codebases under clearly defined conditions).

If a module does not contain a license you are on somewhat shaky ground and you can either

take the pragmatic approach and assume you can use the module under the same terms as other CPAN modules, which is reasonable enough for many purposes
take the paranoid approach and try to contact the author and ask him to clarify the license under which the module is available. That clarification doesn't need to be a triplicate document signed in blood however, the simple sentence "available under the same conditions as Perl itself" is enough.

This is why it's important that modules contain license files or statements, it actually makes things easier for the user.

And what makes you think this problem is unique to the Perl world? If you take a piece of code out of the Microsoft knowledgebase, that code is copyrighted and you need to know under what conditions you can use it. If you take something from a book, the same. If you take a usenet posting from a random programmer, that is copyrighted and you need to theoretically clarify whether you can use it. Hell, if your colleague across the corridor sends you an email that email is copyrighted to him(unless his employment contract has a clause which transfers copyright ownership to his employer) and you need his permission to use it in any way. At least with CPAN modules you have the license which clarifies how you can use the code.

Tell you what though, there does seem to be some confusion on this topic (and it is highly likely I am misunderstanding or misinterpreting licensing issues in some way as well), which is not entirely unimportant. Ovid posted a question on what the Perl Foundation could do for us, and maybe it would be a good idea if it could obtain some clarification on these issues. ~~I'll go post~~ I've posted a request for that.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

Comment on Re^13: Why non-core CPAN modules can't be used in large corporate environments.

Replies are listed 'Best First'.
Re^14: Why non-core CPAN modules can't be used in large corporate environments. by BrowserUk (Patriarch) on Dec 07, 2005 at 19:25 UTC
The point is, that up till now, I was reasonably confident that it was legally "safe" for anyone to use CPAN modules for their own purposes--whatever those purposes may be. The length, depth and intracacies of all the various forms of GPL licence agreements are such that it is impossible for any indiviudual or company to arrive at a conclusion: "Yes I can use this in my commercial project". Such conclusions will require years of case law. And that case law will need to be repeated in every jurisprudence. The case law is simply not available for any form of GPL yet. And the variations of GPL are myriad and rising, and the problem isn't getting any easier. I was under the impression that the Perl Artistic licence was different. I believed it to say "Here it is, make money with it if you can". It adds a few moral obligations too, but essentially it was the essence of "Free, as in free of risk and burden". It seemed so clear to me that this was the intent of the Artist licence, that anyone adding those words, "under the same licence as Perl itself", was accepting that other people were quite likely to take their work from CPAN and use it, in whole or in part, and make money from it. Sure, most people would frown upon someone taking their module, replacing the author's name with their own, and re-publishing it, it would be a morally objectionable act--but not cause for a law suite. This view is supported by there being a number of packages on CPAN already that basically take an existing module, reduce the code, simplifying it or it's interface and then re-publish it as X::Y::Simple. However, the moment any one author starts throwing the terms "morally wrong" and "illegal" around when someone starts re-using code from CPAN, it calls the validity of my "assured layman's understanding" into question. And when I can no longer trust that layman's understanding, for one author or one package, it raises the spectre of requiring lawyerly intervention for each and every use made of any CPAN module, including all thise distributed with Perl itself. From that point on, all opinions not tested in case law, are off. In a world where Xbox-360 owners have issued class-action law suites on the second day of the products availability, can any company risk CPAN authors deciding that they have cause to do something similar? Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]
Re^15: Why non-core CPAN modules can't be used in large corporate environments. by tirwhan (Abbot) on Dec 07, 2005 at 20:01 UTC
Well, I think I see where you're coming from. I also think you are grossly overreacting to the threat you perceive and that there are almost certainly vastly greater legal risks which you as a software architect (and by extension your customer) expose yourself constantly. And there is certainly no restriction on the purposes of a user who wants to use free software. There are a few very easily fulfilled restrictions on how he can use the software, and these are less than with any other kinds of software. I have no problem if people take free software and make money from it. I am concerned with software staying free, and the point we were discussing is rather central to that issue, given the current legal framework and political tendencies. The fact that there are not huge amounts of past law cases which support the strength of FLOSS licenses is simply due to the fact that our industry is a very young one and acceptable practices are being established as we go along. Some establish practices by fabricating anti-competitive and illegal EULAs and some establish them by trying to find ways of giving people access to their intellectual property in a way that is as painless as possible. You makes your choices and you takes your chances. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]
Re^16: Why non-core CPAN modules can't be used in large corporate environments. by BrowserUk (Patriarch) on Dec 07, 2005 at 21:20 UTC
I also think you are grossly overreacting to the threat you perceive No I am not. I am drawing the logical conclusions from your* statements in this thread. And I strongly suggest that you re-read, this, and this, and especially this, and then see if you are still able to make the claim that "I am concerned with software staying free,"? Because you* started this subthread by bandying the words "copyright", "sneaking", "illegal", "[im]moral" and the phrase "you'd actually be putting your company into a legally extremely vulnerable position". It is the logical conclusion from the things that you had to say in those posts that leads to my conclusions. As long as authors of "free software licenced modules", hold and state the opinions you expressed in those posts, their (your) actions call the whole basis of those licence agreements into question. All I did was draw your attention to them, and draw the logical inferences from them. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^17: Why non-core CPAN modules can't be used in large corporate environments. by tirwhan (Abbot) on Dec 08, 2005 at 00:09 UTC
Re^18: Why non-core CPAN modules can't be used in large corporate environments. by BrowserUk (Patriarch) on Dec 08, 2005 at 00:24 UTC
Some notes below your chosen depth have not been shown here
Re^18: Why non-core CPAN modules can't be used in large corporate environments. by Perl Mouse (Chaplain) on Dec 08, 2005 at 01:09 UTC
Some notes below your chosen depth have not been shown here
Re^15: Why non-core CPAN modules can't be used in large corporate environments. by Anonymous Monk on Dec 07, 2005 at 19:45 UTC
The length, depth and intracacies of all the various forms of GPL licence agreements are such that it is impossible for any indiviudual or company to arrive at a conclusion: "Yes I can use this in my commercial project". All the various forms? You mean two, right? The original GPL and the LGPL. All you have to do to be in compliance with the GPL is to make sure you distribute your source code to those who request it.	[reply]
Re^16: Why non-core CPAN modules can't be used in large corporate environments. by BrowserUk (Patriarch) on Dec 07, 2005 at 20:09 UTC
You see, even with something as simple as trying to indicate "widely available and recognised free software licencing agreements"--Ie. What I was trying to indicate when I used "GPL licences"--you need a lawyer to verify what you are saying. The FSF has found cause to make distinctions regarding the following 28 free software licence agreements (from FSF): GNU GPL. GNU LGPL Licence of Guile License of the run-time units of the GNU Ada compiler X11 licence Expat Licence Standard ML of New Jersey Copyright License Public Domain Cryptix General License Modified BSD license License of ZLib License of the iMatix Standard Function Library W3C Software Notice and License Berkeley Database License (aka the Sleepycat Software Product License) OpenLDAP License, Version 2.7 License of Python 1.6a2 and earlier versions License of Python 2.0.1, 2.1.1, and newer versions License of Perl Clarified Artistic License Zope Public License version 2.0 Intel Open Source License (as published by OSI) License of Netscape Javascript eCos license version 2.0 Eiffel Forum License, version 2 License of Vim, Version 6.1 or later Boost Software License EU DataGrid Software License The license of Ruby And those are just the "GPL compatible" ones! There is another list of 30+ "incompatible" ones, and 20 or so more including the original "Artistic licence", that are not considered "free software licences" at all. Me, I'm just a layman. I ain't about to argue with the FSF. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]