Re: License Framework: Develop Best Practices
On Tue June 15 2010 23:22:35 Wesley Shields wrote: On Tue, Jun 15, 2010 at 02:46:27AM +0200, Marco Bröder wrote: Hello, I know the ports license framework is very new and not mature yet. But it is not very useful in its current state, because several popular licenses are missing and some license foo is not right / specific enough to be considered legally correct (for example there is no 'one BSD License', there are at least three of them, all legally different). The legal consequences of even very small differences can be very huge. We actually have to make this legally right or the whole thing is useless. Some maintainers already added some license foo to their ports. At the moment there is more guessing than knowing what actually should be done from a maintainers point of view. This is especially true for dual / multi / combo licensing (for example 'GPLv2 or any later version' is not really the same as 'GPLv2 or GPLv3' combo). Before this even grows, could we please start developing best practices and document them into Porters Handbook, as soon as possible? Thanks! I couldn't agree more. I've been holding off until the Porter's Handbook has clear documentation on what maintainers need to know. I've included alepulver@ on this as he is the one that wrote the initial support for this. I'd hate to see this grow into a mess that has to be cleaned up later because there isn't proper documentation for maintainers. Hopefully Alejandro has a PH update in the wings? If not then I guess it's up to someone(TM) to do it. -- WXS I neither saw a reply from alepulver@ nor anything else on this subject. Are there any further news? There was nothing added to the Porter's Handbook, too. So I guess the situation did not change within the last months, right? Unfortunately, with a recent update to one of my ports (the software is -GPLv2 or any later version- licensed) the committer added the LICENSE / LICENSE_COMB foo at his own without asking. I find this annoying, because I purposely did not add it. Something like that should be the maintainer's choice, because he is also responsible for the port. I think the LICENSE stuff should generally not be added until the whole subject is clarified and properly documented, which does not seem to be the case, especially from the legal point of view. What should the license framework be? Looks like nobody really seems to care (enough). Will it remain a legally incorrect and unreliable stuff? Then, there is no need to actually care about it and the whole license framework is pretty much useless in a legal sense. But that must be stated explicitly. Or should it be as correct as possible? Then it is necessary to have the licenses at least correctly defined and used like they exist (see my original mail quoted above and below, especially the '[L]GPLv2 or any later version' and the three BSD licenses). Will there be an official consensus? Will there be rules or disclaimers for maintainer's and committer's responsibility? Will the whole thing be properly documented in the Porter's Handbook? Will the licenses be correctly defined in 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly simplified? The license framework could be very nice and actually useful - if properly done ... I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. Here is my suggestion what should be there at a minimum (probably more needed): *** ARTLv1.0# Artistic License 1.0 ARTLv2.0# Artistic License 2.0 ASLv1.1# Apache License 1.1 ASLv2.0# Apache License 2.0 BSD-2-clause# Simplified BSD License BSD-3-clause# Modified or New BSD License BSD-4-clause# Original BSD License BSLv1.0# Boost Software License 1.0 CDDLv1.0# Common Development and Distribution License 1.0 EPLv1.0# Eclipse Public License 1.0 GFDLv1.1# GNU Free Documentation License 1.1 GFDLv1.2# GNU Free Documentation License 1.2 GFDLv1.3# GNU Free Documentation License 1.3 GPLv2# GNU General Public
Re: License Framework: Develop Best Practices
On 10/23/2010 2:41 PM, Marco Bröder wrote: On Tue June 15 2010 23:22:35 Wesley Shields wrote: I neither saw a reply from alepulver@ nor anything else on this subject. Are there any further news? There was nothing added to the Porter's Handbook, too. So I guess the situation did not change within the last months, right? Unfortunately, with a recent update to one of my ports (the software is -GPLv2 or any later version- licensed) the committer added the LICENSE / LICENSE_COMB foo at his own without asking. I find this annoying, because I purposely did not add it. Something like that should be the maintainer's choice, because he is also responsible for the port. I think the LICENSE stuff should generally not be added until the whole subject is clarified and properly documented, which does not seem to be the case, especially from the legal point of view. What should the license framework be? Looks like nobody really seems to care (enough). Will it remain a legally incorrect and unreliable stuff? Then, there is no need to actually care about it and the whole license framework is pretty much useless in a legal sense. But that must be stated explicitly. Or should it be as correct as possible? Then it is necessary to have the licenses at least correctly defined and used like they exist (see my original mail quoted above and below, especially the '[L]GPLv2 or any later version' and the three BSD licenses). Will there be an official consensus? Will there be rules or disclaimers for maintainer's and committer's responsibility? Will the whole thing be properly documented in the Porter's Handbook? Will the licenses be correctly defined in 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly simplified? The license framework could be very nice and actually useful - if properly done ... A few weeks ago I was very busy with exams (now I've started to update and clean up some of my ports). But about the PH entry I have previously asked about policies regarding creation of files (the first variables in bsd.licenses.mk) without answer, and I can't write anything. About the rest (what licenses to have, how to define them, etc) the only thing I could do is to look at what other projects did, but really it's not my area (which is writing the code to provide required functionality). I'm willing to make necessary changes to bsd.licenses.mk and/or write documentation if someone else could take care of the bureaucratic part. I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. I have no problem to others taking care of the file. It was initially just an example, and the plan was to automatically classify ports and take the license list from there (which might happen after I update the fossology port to the recent release and fix a few issues). It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. These could be achieved with groups, or as you suggested with individual names. Regards, Ale ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On 10/23/2010 2:41 PM, Marco Bröder wrote: On Tue June 15 2010 23:22:35 Wesley Shields wrote: I neither saw a reply from alepulver@ nor anything else on this subject. Are there any further news? There was nothing added to the Porter's Handbook, too. So I guess the situation did not change within the last months, right? Unfortunately, with a recent update to one of my ports (the software is -GPLv2 or any later version- licensed) the committer added the LICENSE / LICENSE_COMB foo at his own without asking. I find this annoying, because I purposely did not add it. Something like that should be the maintainer's choice, because he is also responsible for the port. I think the LICENSE stuff should generally not be added until the whole subject is clarified and properly documented, which does not seem to be the case, especially from the legal point of view. What should the license framework be? Looks like nobody really seems to care (enough). Will it remain a legally incorrect and unreliable stuff? Then, there is no need to actually care about it and the whole license framework is pretty much useless in a legal sense. But that must be stated explicitly. Or should it be as correct as possible? Then it is necessary to have the licenses at least correctly defined and used like they exist (see my original mail quoted above and below, especially the '[L]GPLv2 or any later version' and the three BSD licenses). Will there be an official consensus? Will there be rules or disclaimers for maintainer's and committer's responsibility? Will the whole thing be properly documented in the Porter's Handbook? Will the licenses be correctly defined in 'ports/Mk/bsd.licenses.db.mk' or will some of them remain incorrectly simplified? The license framework could be very nice and actually useful - if properly done ... A few weeks ago I was very busy with exams (now I've started to update and clean up some of my ports). But about the PH entry I have previously asked about policies regarding creation of files (the first variables in bsd.licenses.mk) without answer, and I can't write anything. About the rest (what licenses to have, how to define them, etc) the only thing I could do is to look at what other projects did, but really it's not my area (which is writing the code to provide required functionality). I'm willing to make necessary changes to bsd.licenses.mk and/or write documentation if someone else could take care of the bureaucratic part. I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. I have no problem to others taking care of the file. It was initially just an example, and the plan was to automatically classify ports and take the license list from there (which might happen after I update the fossology port to the recent release and fix a few issues). It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. These could be achieved with groups, or as you suggested with individual names. Regards, Ale P.S.: the mail was re-sent from the correct address (subscribed to the list) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Wed, Jun 16, 2010 at 10:48:14AM -0700, Micheas Herman wrote: I don't think the FreeBSD project could afford to have this license cataloging scheme regularly inspected by appropriate legal counsel for each of the various different jurisdictions around the world and for them to approve it as accurate and legally watertight. I think that FreeBSD should piggy back on the OSI and just list the following licenses: http://www.opensource.org/licenses/alphabetical plus other. Using the list from OSI or NetBSD or similar would be a good way do an initial population of the file. This could be a filter of sorts for those that want it. IANAL but just listing the license should not be more or less risky for the project than distributing the source code, and it might even reduce the risk of distributing pre compiled binaries as there is at least a good faith effort to comply with the license(s) and make it easy for the end user to be aware of the license(s) of the code. We already have a mechanism to prevent distribution distfiles and packages on our mirrors with the current NO_CDROM, RESTRICTED and NO_PACKAGE flags. The license framework is ment to make these more finegrained and give endusers a better handle to avoid using specific licenses. As you say, this does not change that it will be done on a best effort basis, which may, or may not, be good enough for your specific use case, but it does provide better control. -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpbTtjJfG9Fu.pgp Description: PGP signature
Re: License Framework: Develop Best Practices
On 06/16/2010 16:06, Dominic Fandrey wrote: On 15/06/2010 02:46, Marco Bröder wrote: BSD-2-clause# Simplified BSD License BSD-3-clause# Modified or New BSD License BSD-4-clause# Original BSD License Just a side note, am I the only one using a single clause variant of the BSDL? I really don't give a damn what people do with binaries, so out went the clause. So really your using a MIT Style license just with a clause instead of the staticlly written The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. So why not just use that instead. Regards, -- jhell ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, 2010-06-15 at 08:21 +0100, Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/06/2010 07:46:27, Eric wrote: It would seem from reading the various posting that the two missing features are some sort of clean way of saying this license or higher and possibly something along the lines of like this licence for cases where 99% is the same as an existing OS licence, but I guess that last one comes down to a point of purpose. Is the licence framework supposed to be a solid legal structure or is it much like the pkg-descriptions just something we can filter against and use to help guide us to the ports we want to install? I don't think the FreeBSD project could afford to have this license cataloging scheme regularly inspected by appropriate legal counsel for each of the various different jurisdictions around the world and for them to approve it as accurate and legally watertight. I think that FreeBSD should piggy back on the OSI and just list the following licenses: http://www.opensource.org/licenses/alphabetical plus other. This could be a filter of sorts for those that want it. IANAL but just listing the license should not be more or less risky for the project than distributing the source code, and it might even reduce the risk of distributing pre compiled binaries as there is at least a good faith effort to comply with the license(s) and make it easy for the end user to be aware of the license(s) of the code. Given potential liabilities should the project attempt a binding framework without such checking, it would be horribly exposed should some FreeBSD user suffer and attempt to recoup consequential losses. Therefore, this should only be done on a 'best efforts' basis, and there should be prominent warnings that the license data may or may not be accurate and that end users *must* make their own verification that all software they are using is appropriately licensed. I doubt the warning would shield the project from lawsuits about ports that are currently being illegally distributed by the project (if the do exist, I have not carefully check that none of the GPL projects do not include GPL incompatible code and vice versa.) Much less provide any protection for any packages that are being distributed by the project. The Handbook, the man pages, and the example make.conf file should all carry the warning that the FreeBSD project does not warranty nor indemnify anything in the ports collection, including but not limited to the copyright tagging. Just some late night thoughts. I feel that at this point I should declare that IANAL, so take everything I say here not as advice, but as my personal opinion. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwXKeEACgkQ8Mjk52CukIxs9QCeNF+rjCoyPKiiDT5lUVN2XBzd QyUAni4ARLODukPokjgcrUuRp9OAPu22 =gDf+ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- -- Sometimes I wonder if I'm in my right mind. Then it passes off and I'm as intelligent as ever. -- Samuel Beckett, Endgame ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On 15/06/2010 02:46, Marco Bröder wrote: BSD-2-clause# Simplified BSD License BSD-3-clause# Modified or New BSD License BSD-4-clause# Original BSD License Just a side note, am I the only one using a single clause variant of the BSDL? I really don't give a damn what people do with binaries, so out went the clause. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
From: Philip M. Gollucci pgollu...@p6m7g8.com Date: Tue, 15 Jun 2010 02:03:08 + On 06/15/10 00:46, Marco Bröder wrote: I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: A very good idea, but not neccessarily the best one. Future versions of licenses are not always backwards compatible? Its GPLv2 vs GPLv3 one such example ? Although does it matter in those cases about backwards compatibility? If the software has been released under (for example) GPLv2 or higher then hasn't the author essentially already consented to any future version of the GPL, no matter how incompatible they may be? If however they re-release software under later licences (dual or otherwise) then that's explicit and the licence entry would either be the new licence or a combination of the new and old entries. It would seem from reading the various posting that the two missing features are some sort of clean way of saying this license or higher and possibly something along the lines of like this licence for cases where 99% is the same as an existing OS licence, but I guess that last one comes down to a point of purpose. Is the licence framework supposed to be a solid legal structure or is it much like the pkg-descriptions just something we can filter against and use to help guide us to the ports we want to install? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Mon, 14 Jun 2010, Chuck Swiger wrote: Where I live, someone without a legal degree cannot offer legal advice [..] It might also not be a bad idea to not display anything about licensing until a human enables some Makefile switch which acknowledges the limitations of the system (ie, license description coverage is incomplete, etc, etc). IMHO it might make sense to add some sort of disclaimer that the license information is not to be considered as legal advice. Otherwise people who redistribute the ports in some country with a ridiculous legal system might become liable for something if they are unlucky. I am not sure if this should be in the documentation, or if it should be displayed every time when anything license related appears on the screen. Regarding the Makefile switch I would rather have it the opposite way if it is seen necessary (IMHO not needed if there is a disclaimer somewhere). If you want to disable it, you could define: I_LIVE_IN_A_COUNTRY_WITH_A_RIDICULOUS_LEGAL_SYSTEM_WHICH_REQUIRES_DISCLAIMER_FOR_EVERY_SILLIEST_POSSIBLE_THING_TO_AVOID_LEGAL_LIABILITY_AND_THEREFORE_I_WANT_TO_DISABLE_THE_LICENSE_THING=yes As a previous poster pointed out, I also think that the different BSD licences should be separated. The 4-clause version puts heavy burdens on someone who redistributes and does marketing. In case a redistributor does any marketing, they need to figure out some acknowledgement to be added in marketing materials for every piece of 4-clause licensed software. I also second the previous posters' opinion that in specifying GPL related licenses, it is necessary to distinguish between this version only and or any later version. It makes a big difference in license compatibility. If these distinctions are not made, the whole framework is not very useful. I would rather see it to be useful. DISCLAIMER: I am writing this in a country where I can give legal advice to anyone I want and also freely talk about anything else and therefore the readers of this message may freely make any interpretations they whish about the contents of this post. :) -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/06/2010 07:46:27, Eric wrote: It would seem from reading the various posting that the two missing features are some sort of clean way of saying this license or higher and possibly something along the lines of like this licence for cases where 99% is the same as an existing OS licence, but I guess that last one comes down to a point of purpose. Is the licence framework supposed to be a solid legal structure or is it much like the pkg-descriptions just something we can filter against and use to help guide us to the ports we want to install? I don't think the FreeBSD project could afford to have this license cataloging scheme regularly inspected by appropriate legal counsel for each of the various different jurisdictions around the world and for them to approve it as accurate and legally watertight. Given potential liabilities should the project attempt a binding framework without such checking, it would be horribly exposed should some FreeBSD user suffer and attempt to recoup consequential losses. Therefore, this should only be done on a 'best efforts' basis, and there should be prominent warnings that the license data may or may not be accurate and that end users *must* make their own verification that all software they are using is appropriately licensed. I feel that at this point I should declare that IANAL, so take everything I say here not as advice, but as my personal opinion. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwXKeEACgkQ8Mjk52CukIxs9QCeNF+rjCoyPKiiDT5lUVN2XBzd QyUAni4ARLODukPokjgcrUuRp9OAPu22 =gDf+ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, 2010-06-15 at 08:21 +0100, Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/06/2010 07:46:27, Eric wrote: It would seem from reading the various posting that the two missing features are some sort of clean way of saying this license or higher and possibly something along the lines of like this licence for cases where 99% is the same as an existing OS licence, but I guess that last one comes down to a point of purpose. Is the licence framework supposed to be a solid legal structure or is it much like the pkg-descriptions just something we can filter against and use to help guide us to the ports we want to install? I don't think the FreeBSD project could afford to have this license cataloging scheme regularly inspected by appropriate legal counsel for each of the various different jurisdictions around the world and for them to approve it as accurate and legally watertight. I think that FreeBSD should piggy back on the OSI and just list the following licenses: http://www.opensource.org/licenses/alphabetical plus other. This could be a filter of sorts for those that want it. IANAL but just listing the license should not be more or less risky for the project than distributing the source code, and it might even reduce the risk of distributing pre compiled binaries as there is at least a good faith effort to comply with the license(s) and make it easy for the end user to be aware of the license(s) of the code. Given potential liabilities should the project attempt a binding framework without such checking, it would be horribly exposed should some FreeBSD user suffer and attempt to recoup consequential losses. Therefore, this should only be done on a 'best efforts' basis, and there should be prominent warnings that the license data may or may not be accurate and that end users *must* make their own verification that all software they are using is appropriately licensed. I doubt the warning would shield the project from lawsuits about ports that are currently being illegally distributed by the project (if the do exist, I have not carefully check that none of the GPL projects do not include GPL incompatible code and vice versa.) Much less provide any protection for any packages that are being distributed by the project. The Handbook, the man pages, and the example make.conf file should all carry the warning that the FreeBSD project does not warranty nor indemnify anything in the ports collection, including but not limited to the copyright tagging. Just some late night thoughts. Micheas I feel that at this point I should declare that IANAL, so take everything I say here not as advice, but as my personal opinion. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwXKeEACgkQ8Mjk52CukIxs9QCeNF+rjCoyPKiiDT5lUVN2XBzd QyUAni4ARLODukPokjgcrUuRp9OAPu22 =gDf+ -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- -- Sometimes I wonder if I'm in my right mind. Then it passes off and I'm as intelligent as ever. -- Samuel Beckett, Endgame ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue June 15 2010 04:03:08 Philip M. Gollucci wrote: On 06/15/10 00:46, Marco Bröder wrote: I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: A very good idea, but not neccessarily the best one. Future versions of licenses are not always backwards compatible? Its GPLv2 vs GPLv3 one such example ? No. And no. First, it is not an 'idea' from me, it is actually necessary to distinct between 'GPLv2' and 'GPLv2 or any later version', because that is what the licenses dictate. I think, you misunderstood the meaning of the two terms. Backwards compatibility does not play any role in it. It is irrelevant. 'GPLv2' is just 'GPLv2'- one single license without any choices. 'GPLv2 or any later version' means, the license is 'GPLv2', but the user / developer / contributor / whoever may choose -either- this GPL version 2 -or- one of any later versions (3 or one of any later versions to come in the future). But it is again one single license which applies. It does not mean 'automatically choose the most recent / latest version of the GPL' or something like that! So, there is actually no incompatibility between licenses, because it cannot be the case. There is always just one single license which applies, not multiple of them. -- Regards signature.asc Description: This is a digitally signed message part.
Re: License Framework: Develop Best Practices
On Tue June 15 2010 09:10:49 Janne Snabb wrote: As a previous poster pointed out, I also think that the different BSD licences should be separated. Yes, they really are different licenses. Who else should it know better than the FreeBSD Project (and NetBSD, OpenBSD, DragonflyBSD, ...)? ;-) I also second the previous posters' opinion that in specifying GPL related licenses, it is necessary to distinguish between this version only and or any later version. It makes a big difference in license compatibility. Yeah, thanks! If these distinctions are not made, the whole framework is not very useful. I would rather see it to be useful. As I wrote ... -- Regards signature.asc Description: This is a digitally signed message part.
Re: License Framework: Develop Best Practices
On Tue, Jun 15, 2010 at 1:29 PM, Marco Bröder marco.broe...@gmx.eu wrote: On Tue June 15 2010 09:10:49 Janne Snabb wrote: As a previous poster pointed out, I also think that the different BSD licences should be separated. Yes, they really are different licenses. The BSD license has evolved over time. Compare the 4-clause license to the 3-clause license and the 2-clause license. Who else should it know better than the FreeBSD Project (and NetBSD, OpenBSD, DragonflyBSD, ...)? ;-) -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, Jun 15, 2010 at 1:39 PM, Garrett Cooper yanef...@gmail.com wrote: On Tue, Jun 15, 2010 at 1:29 PM, Marco Bröder marco.broe...@gmx.eu wrote: On Tue June 15 2010 09:10:49 Janne Snabb wrote: As a previous poster pointed out, I also think that the different BSD licences should be separated. Yes, they really are different licenses. The BSD license has evolved over time. Compare the 4-clause license to the 3-clause license and the 2-clause license. Who else should it know better than the FreeBSD Project (and NetBSD, OpenBSD, DragonflyBSD, ...)? ;-) Ugh... my brain went out to lunch. Please ignore my last reply. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, Jun 15, 2010 at 02:46:27AM +0200, Marco Br??der wrote: Hello, I know the ports license framework is very new and not mature yet. But it is not very useful in its current state, because several popular licenses are missing and some license foo is not right / specific enough to be considered legally correct (for example there is no 'one BSD License', there are at least three of them, all legally different). The legal consequences of even very small differences can be very huge. We actually have to make this legally right or the whole thing is useless. Some maintainers already added some license foo to their ports. At the moment there is more guessing than knowing what actually should be done from a maintainers point of view. This is especially true for dual / multi / combo licensing (for example 'GPLv2 or any later version' is not really the same as 'GPLv2 or GPLv3' combo). Before this even grows, could we please start developing best practices and document them into Porters Handbook, as soon as possible? Thanks! I couldn't agree more. I've been holding off until the Porter's Handbook has clear documentation on what maintainers need to know. I've included alepulver@ on this as he is the one that wrote the initial support for this. I'd hate to see this grow into a mess that has to be cleaned up later because there isn't proper documentation for maintainers. Hopefully Alejandro has a PH update in the wings? If not then I guess it's up to someone(TM) to do it. -- WXS I will start with a few points: *** bsd.license.db.mk *** We really need to rework it. It should at least contain the most popular / often used licenses -and- their -correct- versions. The latter is not always the case at the moment. And the versions should have only -one- format, not multiples. I suggest to always use a something like 'LGPLv2.1' and not 'LGPL21'. At least it has to be consistent across all licenses. I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: LICENSE=LGPLv2 LGPLv2.1 LGPLv3 LGPLv3.1 LGPLv3.2 LICENSE_COMB=dual ... and so on for every future versions - it does not scale well and has to be changed with every new future version. Instead it should be just 'LGPLv2+' and stay there unchanged forever. Here is my suggestion what should be there at a minimum (probably more needed): *** ARTLv1.0# Artistic License 1.0 ARTLv2.0# Artistic License 2.0 ASLv1.1# Apache License 1.1 ASLv2.0# Apache License 2.0 BSD-2-clause# Simplified BSD License BSD-3-clause# Modified or New BSD License BSD-4-clause# Original BSD License BSLv1.0# Boost Software License 1.0 CDDLv1.0# Common Development and Distribution License 1.0 EPLv1.0# Eclipse Public License 1.0 GFDLv1.1# GNU Free Documentation License 1.1 GFDLv1.2# GNU Free Documentation License 1.2 GFDLv1.3# GNU Free Documentation License 1.3 GPLv2# GNU General Public License 2 GPLv2+# GNU General Public License 2 or any later version GPLv3# GNU General Public License 3 GPLv3+# GNU General Public License 3 or any later version ISC# ISC License LGPLv2# GNU Lesser General Public License 2 LGPLv2+# GNU Lesser General Public License 2 or any later version LGPLv2.1# GNU Lesser General Public License 2.1 LGPLv2.1+# GNU Lesser General Public License 2.1 or any later version LGPLv3# GNU Lesser General Public License 3 LGPLv3+# GNU Lesser General Public License 3 or any later version MIT# MIT license MPLv1.0# Mozilla Public License 1.0 MPLv1.1# Mozilla Public License 1.1 PD# Public Domain license X11# X11 license *** There are probably more licenses and / or versions to add or to change. And there are most likely more issues to discuss ... ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/15/10 00:46, Marco Bröder wrote: I find it especially important to have a expression for 'version X or any later version' (for example 'LGPLv2+'), since the following dummy example is not adequate: A very good idea, but not neccessarily the best one. Future versions of licenses are not always backwards compatible? Its GPLv2 vs GPLv3 one such example ? - -- - 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iD8DBQFMFt9cdbiP+9ubjBwRAh4lAJ0Q732fnO24FCQJ4SoIcw2821uG8QCfXIMw VLSmTKbKOXfNmjvExpsipYs= =9yoD -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Tue, 15 Jun 2010, Marco Br?der wrote: But it is not very useful in its current state, because several popular licenses are missing and some license foo is not right / specific enough to be considered legally correct (for example there is no 'one BSD License', there are at least three of them, all legally different). The legal consequences of even very small differences can be very huge. We actually have to make this legally right or the whole thing is useless. This points nicely to something I've been wondering about. Could it be a problem for non-lawyers to categorize (give an opinion) on a license that isn't an exact word-for-word duplicate of a known license? -Warren Block * Rapid City, South Dakota USA ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: License Framework: Develop Best Practices
On Jun 14, 2010, at 8:30 PM, Warren Block wrote: On Tue, 15 Jun 2010, Marco Br?der wrote: But it is not very useful in its current state, because several popular licenses are missing and some license foo is not right / specific enough to be considered legally correct (for example there is no 'one BSD License', there are at least three of them, all legally different). The legal consequences of even very small differences can be very huge. We actually have to make this legally right or the whole thing is useless. This points nicely to something I've been wondering about. Could it be a problem for non-lawyers to categorize (give an opinion) on a license that isn't an exact word-for-word duplicate of a known license? Where I live, someone without a legal degree cannot offer legal advice-- giving rise to acronyms like IANAL (I Am Not A Lawyer) and TINLA (This Is Not Legal Advice). You should not rely on automated tools including the ports framework to provide arbitrarily complex guidance appropriate for various combinations of licenses, local peculiarities, and so forth-- if you don't feel comfortable you understand and comply with the licenses of the software you use, hire a local lawyer-- don't ask for legal advice from a world-wide mailing list. :-) However, there are plenty of sites like SourceForge, Apache.org, GNU/FSF, and so forth which provide support/hosting for various projects and provide a classification of licenses. Like almost any human activity, such a categorization process is imperfect-- but good enough for now works just fine, until someone notices/complains about some issue, in which case it will probably be quickly fixed. There are probably some things which the FreeBSD implementation of licensing could be improved. For example, if port maintainers or committers make an effort to confirm with the original author(s)/copyright holder(s) that the license of the software is being correctly categorized and recorded that with the CVS/SVN commit adopting the license categorization in the port Makefile. It might also not be a bad idea to not display anything about licensing until a human enables some Makefile switch which acknowledges the limitations of the system (ie, license description coverage is incomplete, etc, etc). Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
