Thanks for everyone's feedback. Based on discussion, I and Laca decided to name the subdirectory "encumbered". I believe all spec-files that build code with encumbrance issues are now in this subdirectory. Laca plans to do some additional work to support a --with-encumbered pkgtool option so that we can fix spec files which have optional encumbered dependencies so you can specify whether to build with these dependencies or not. This work will be done later.
If anybody notices any errors (such as spec files that should be in this subdirectory but are not, or spec files that are incorrectly placed in this subdirectory), then please let us know. Thanks again, Brian > spec-files-extra currently contains a number of media modules that are > "ugly" in the sense of the GStreamer "ugly" plugins. These are modules > that contain code that contains IP, reverse-engineered code, requires > license in order to use and/or distribute, etc. > > I recommend that we do the following: > > 1) Move all modules that contain IP into a subdirectory, I propose > "spec-files-ugly" or perhaps just "ugly" > > 2) Add a README to this directory that explains that these modules > may contain IP and that people need to make sure that they are not > violating any laws when they build, use, or distribute code > built with these spec files. Probably should say that people who > build these spec files take responsibility for ensuring that laws are > properly followed. This way users are better informed about possible > issues. The README should also explain the need to use the > --with-spec-files-ugly argument to build these modules. > > 3) Update pkgtool so that you need to pass in an argument called > --with-spec-files-ugly in order to build ugly modules. If the > user tries to build one without this argument, I'd say pkgtool > should tell people to read the README. > > This way people have to make a conscious decision to build > such modules, without making things too difficult. > > 4) Some non-ugly spec files may optionally require modules in the > ugly directory. These should use %if / %endif logic so that > these ugly dependencies are only included when the > --with-spec-files-ugly option is used when calling pkgtool > > Based on my review, modules that inlcude IP or reverse engineered code > include. I think these should be moved into the ugly directory: > > SFEfaad2.spec > SFEffmpeg.spec > SFElame.spec > SFEliba52.spec > SFElibavc1394.spec > SFElibdts.spec > SFElibdv.spec > SFElibdvbpsi.spec > SFElibdvdcss.spec > SFElibdvdnav.spec > SFElibdvdplay.spec > SFElibdvdread.spec > SFElibfame.spec > SFElibiec61883.spec > SFEtwolame.spec > SFElibid3tag.spec > SFElibmad.spec > SFElibmpcdec > SFElibmpeg2.spec > SFElibnjb.spec > SFElibquicktime.spec > SFElibraw1394.spec > SFEmjpegtools.spec > SFEmpg321.spec > SFEmpgtx.spec > SFEmplayer-codecs.spec > SFEswfdec.spec > SFExvid.spec > > The following applications are applications which depend on the above > modules. I recommend that these also be moved into the spec-files-ugly > subdirectory until these spec files are fixed to use %if / %endif > techniques that allow building without modules that contain IP as > described in step #4 above. For some of these modules, it may not > be possible to make them not depend on a module that contains IP. > These should remain in the spec-files-ugly directory. > > SFEaudacity.spec > SFEdvgrab.spec > SFEdvdauthor.spec > SFEdvdstyler.spec > SFEgnomad2.spec > SFEgpac.spec > SFEgraveman.spec > SFEgtkpod.spec > SFEkino.spec > SFEmpd.spec > SFEmplayer.spec > SFEvice.spec > SFEvlc.spec > SFExine-lib.spec > SFExmms.spec > SFEy4mscaler.spec > > From my initial review, I think that is a complete list of code that > involves IP media, reverse engineering, or other possibly questionable > code. If I listed any that really don't have IP by accident, please let > us know. > > I also probably missed a few, so I think we will need to continue to > make an effort to make sure that any code that contains IP is clearly > highlighted. If people are aware of any other modules that should be > included in this list, please let us know. > > Brian > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org
