[Fedora-legal-list] Openstreetmap moving to Open Database License (ODbL)
Hi, Openstreetmap project is about to change their license from CC-BY-SA to ODbL: http://lists.openstreetmap.org/pipermail/legal-talk/2009-February/001958.html http://wiki.openstreetmap.org/index.php/Open_Database_License The Openstreetmap foundation has opened a discussion about the license. It will end on March, 20th. It intends to publish the definitive license on March, 28th. Therefore I'd like to know if this license would permit to include Openstreetmap contents (e.g. maps) in the Fedora Project or if it has some problems. I think that it would be very useful if problems could arise now that the license is not yet released or used. Bye, Andrea. ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: [Fedora-legal-list] Openstreetmap moving to Open Database License (ODbL)
On 03/05/2009 06:19 AM, Andrea Musuruane wrote: Hi, Openstreetmap project is about to change their license from CC-BY-SA to ODbL: http://lists.openstreetmap.org/pipermail/legal-talk/2009-February/001958.html http://wiki.openstreetmap.org/index.php/Open_Database_License The Openstreetmap foundation has opened a discussion about the license. It will end on March, 20th. It intends to publish the definitive license on March, 28th. Therefore I'd like to know if this license would permit to include Openstreetmap contents (e.g. maps) in the Fedora Project or if it has some problems. I think that it would be very useful if problems could arise now that the license is not yet released or used. I really don't want to subscribe to another mailing list... would you be willing to relay comments to the Open Data Commons people? Looking at the Factual Information License, I've got some concerns. I asked Red Hat Legal to take a look at it, and this was their reply: I think the problem with this one is that the definition of Use introduces some fundamental uncertainty. If it really means any act that is restricted by copyright, and this license does seem to be trying to be a copyright license, then there ought to be no problem, since Use should encompass any act of modification that is restricted by applicable copyright -- e.g. rights to create derivative works under U.S. copyright law. However, then they bother to say modifying the Work as may be technically necessary to use it in a different mode or format. That sounds like they might be implying that broader acts of modification are not within the scope of Use, despite the apparent reach of the first part of the definition. And if Use does indeed encompass only a proper subset of copyright-law modification acts, then it would be non-free. While in general that wouldn't necessarily be true, but here the narrow interpretation suggests it is non-free because the apparently-granted modification rights are too limited. In addition, I'm concerned that there does not appear to be any explicit grant of permission to redistribute content under the Factual Information License without restriction. (RH Legal is still looking at the ODBL, they should have comments on that later, which I will pass along). Thanks in advance, ~spot ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: [Fedora-legal-list] Openstreetmap moving to Open Database License (ODbL)
Therefore I'd like to know if this license would permit to include Openstreetmap contents (e.g. maps) in the Fedora Project or if it has some problems. Looking at the Factual Information License, I've got some concerns. I asked Red Hat Legal to take a look at it, and this was their reply: [snip] (RH Legal is still looking at the ODBL, they should have comments on that later, which I will pass along). Thank you Andrea for bringing this issue here, and thank you Tom for looking at it. I'm currently developing shomyu (which might eventually get its way into Fedora one day) and it uses OSM data, so I'm really concerned about this licensing change. /me blesses the day he decided to join this list Regards, -- Mathieu Bridon (bochecha) They who can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety. ~Benjamin Franklin ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
[Fedora-legal-list] Do we need to remove proprietary code from previous releases?
Recently I took over the orphaned package libzzub in F-10 and devel. I found that the upstream renamed the package to armstrong, so I opened a review request for armstrong and it just got approved. But whenever I was packaging armstrong, I found that the source tarball contains some MS propriatary code. This code does not get compiled into the final binary RPM but I removed it from the tarball when I created the SRPM. libzzub is now going through the PackageEndOfLife process and will be removed from F-10 and devel soon. The thing is, the old package libzzub that is in F-7, F-8 and F-9 still has this code in the SRPM. How shall we proceed in this case? Orcan PS: Specifically, the directory src/rtaudio/include needs to be removed from the libzzub tarball. ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: [Fedora-legal-list] Do we need to remove proprietary code from previous releases?
On 03/05/2009 02:36 PM, Orcan Ogetbil wrote: Recently I took over the orphaned package libzzub in F-10 and devel. I found that the upstream renamed the package to armstrong, so I opened a review request for armstrong and it just got approved. But whenever I was packaging armstrong, I found that the source tarball contains some MS propriatary code. This code does not get compiled into the final binary RPM but I removed it from the tarball when I created the SRPM. libzzub is now going through the PackageEndOfLife process and will be removed from F-10 and devel soon. The thing is, the old package libzzub that is in F-7, F-8 and F-9 still has this code in the SRPM. How shall we proceed in this case? Push updates for any non EOL branches without the proprietary gunk. In this case, F-9, since F-10 and devel are being taken care of by armstrong. ~spot ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
[Fedora-legal-list] Legality of staple / unstaple
staple / unstaple is an all-or-nothing data binder / unbinder, licensed under the BSD license. http://sysnet.ucsd.edu/projects/staple/ The author raises a concern that unstaple might be considered illegal due to its ability to brute-force the stapled file, and the FAQ listed some use cases involving misappropriation of intellectual property (the pirated file is combined with the author's own files, stapled together, and attempts to unstaple this collection arguably violates the DMCA). In view of this, staple is shipped separately from unstaple. Would either, or both, be acceptable in Fedora? Could we get staple in Fedora and unstaple in some non-US repositories? This software has been discussed on Bruce Schneier's blog: http://www.schneier.com/blog/archives/2009/03/all-or-nothing.html#comments Thanks, -- miʃel salim • http://hircus.jaiku.com/ IUCS • msa...@cs.indiana.edu Fedora • sali...@fedoraproject.org MacPorts • hir...@macports.org ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
[Fedora-legal-list] enabling CUDA support
Hi all, I've following bugreport from a BOINC user: https://bugzilla.redhat.com/show_bug.cgi?id=487981 Basically, CUDA is a Nvidia technology which enables the GPU to be used for various complex scientific computations (which are then even faster than on CPU). I was about to close the bug as WONTFIX as the whole CUDA is not open source, but then I found out that BOINC (which recently added support for CUDA applications) needs only the single libcudart.so library and that this prebuilt library coming from Nvidia has been already included in the source tarball (but not packaged as far). Now I have a question: as it principally enables the hardware to be controlled by some end-user applications, would it be possible to ship the libcudart.so library in a subpackage as Redistributable, no modification permitted like a firmware? Actually this is what the Nvidia's EULA is saying about the Linux part of CUDA: http://developer.download.nvidia.com/compute/cuda/2_1/toolkit/CUDA_Toolkit_EULA_081215.pdf (see section 2.1.3) Although I guess we can't do it in this way (I'm afraid that same arguments could then be used for e.g. all closed-source modules), I rather ask before definitely closing the bugreport. Regards, Milos ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
Re: [Fedora-legal-list] Do we need to remove proprietary code from previous releases?
On Thu, Mar 5, 2009 at 3:40 PM, Tom spot Callaway wrote: On 03/05/2009 02:36 PM, Orcan Ogetbil wrote: Recently I took over the orphaned package libzzub in F-10 and devel. I found that the upstream renamed the package to armstrong, so I opened a review request for armstrong and it just got approved. But whenever I was packaging armstrong, I found that the source tarball contains some MS propriatary code. This code does not get compiled into the final binary RPM but I removed it from the tarball when I created the SRPM. libzzub is now going through the PackageEndOfLife process and will be removed from F-10 and devel soon. The thing is, the old package libzzub that is in F-7, F-8 and F-9 still has this code in the SRPM. How shall we proceed in this case? Push updates for any non EOL branches without the proprietary gunk. In this case, F-9, since F-10 and devel are being taken care of by armstrong. ~spot Done. Orcan ___ Fedora-legal-list mailing list Fedora-legal-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-legal-list
